Конструктори и полиморфизъм

Ред на извикване на конструкторите

В конструктора на извлечения клас винаги се вика конструктор на базов клас, до­като всичките конструктори на базови класове са извикани. Това има смисъл, по­неже конструкторът има специална задача: да гледа дали обектът е построен пра­вилно. Извлеченият клас има достъп само до собствените си членове, той ня­ма достъп до тези на базовия клас (чиито членове типично са private). Само кон­структорът на базовия клас има правата и достатъчно знания за да може да инициализира членовете на базовия клас. Така че е важно да се извикат всички кон­структори, иначе обектът няма да се конструира правилно. Това е при­чи­на­та компилаторът да заставя да има извикване на конструктор за всяка порция на извлечения клас. Той тихичко ще извика конструктор по позразбиране ако не сте задали конструктор в тялото на класа. Ако няма конструктор по под­раз­би­ране, компилаторът ще се оплаква. (В случая когато класът няма кон­струк­то­ри компилаторът автоматично синтезира конструктор по подразбиране.)

Нека да разгледаме пример, който демонстрира ефектите от композицията, на­сле­дяването и полиморфизма върху реда на извикване на конструкторите:

//: c07:Sandwich.java

// Order of constructor calls
class Meal {

Meal() { System.out.println("Meal()"); }

}
class Bread {

Bread() { System.out.println("Bread()"); }

}
class Cheese {

Cheese() { System.out.println("Cheese()"); }

}
class Lettuce {

Lettuce() { System.out.println("Lettuce()"); }

}
class Lunch extends Meal {

Lunch() { System.out.println("Lunch()");}

}
class PortableLunch extends Lunch {

PortableLunch() {

System.out.println("PortableLunch()");

}

}

Bread b = new Bread();

Cheese c = new Cheese();

Lettuce l = new Lettuce();

Sandwich() {

System.out.println("Sandwich()");

}

public static void main(String[] args) {

}

} ///:~

Meal()

PortableLunch()

Bread()

Cheese()

Sandwich()

Това показва че редът на извикване на конструкторите в сложен обект е:

1. 
   Вика се конструкторът на базовия клас. Тази стъпка се повтаря рекурсивно та­ка, че конструкторът на кореновия клас се вика първо, после този на пър­вия извлечен клас и т.н., докато се достигне последния извлечен клас.
   
2. 
   Инициализаторите на членовете се викат по реда на декларирането.
   
3. 
   Тялото на конструктора на извлечения клас се вика.
   

Наследяването и finalize( )

//: c07:Frog.java

// Testing finalize with inheritance
class DoBaseFinalization {

public static boolean flag = false;

}
class Characteristic {

String s;

Characteristic(String c) {

s = c;

"Creating Characteristic " + s);

}

protected void finalize() {

"finalizing Characteristic " + s);

}

}
class LivingCreature {

new Characteristic("is alive");

LivingCreature() {

System.out.println("LivingCreature()");

}

protected void finalize() {

"LivingCreature finalize");

// Call base-class version LAST!

if(DoBaseFinalization.flag)

try {

super.finalize();

}

}

Characteristic p =

new Characteristic("has heart");

Animal() {

System.out.println("Animal()");

}

protected void finalize() {

if(DoBaseFinalization.flag)

try {

super.finalize();

}

}

Characteristic p =

new Characteristic("can live in water");

Amphibian() {

System.out.println("Amphibian()");

}

protected void finalize() {

if(DoBaseFinalization.flag)

try {

super.finalize();

}

}

Frog() {

}

protected void finalize() {

if(DoBaseFinalization.flag)

try {

super.finalize();

}

public static void main(String[] args) {

args[0].equals("finalize"))

DoBaseFinalization.flag = true;

else

new Frog(); // Instantly becomes garbage

System.out.println("bye!");

// Must do this to guarantee that all

// finalizers will be called:

System.runFinalizersOnExit(true);

}

} ///:~

Всеки клас в йерархията също съдържа член-обект от тип Characteristic. Ще ви­дите, че независимо как се викат финализаторите на базовия клас, Characteristic член-обектите винаги се финализират.

Всеки подтиснат finalize( ) трябва да има достъп най-малко до protected чле­но­ве­те понеже finalize( ) методът в класа Object е protected и компилаторът няма да позволи да се намали достъпът при наследяването. (“Приятелски” е с по-ма­лък достъп от protected.)

В Frog.main( ) флагът DoBaseFinalization е конфигуриран и единствен Frog обект се създава. Помнете, че събирането на боклука и в частност фи­на­ли­зацията биха могли и да не се случат, така че за да се направи да станат System.runFinalizersOnExit(true) добавя допълнителна работа във връзка с га­ран­тирането на това. Без финализацията на базовия клас изходът е:

not finalizing bases

Creating Characteristic is alive

LivingCreature()

Creating Characteristic has heart

Animal()

Creating Characteristic can live in water

Amphibian()

Frog()

Frog finalize

finalizing Characteristic is alive

finalizing Characteristic has heart

finalizing Characteristic can live in water

Може да видите че, разбира се, не се викат финализатори на базовите класове на Frog. Но ако добавите “finalize” на командния ред получавате:

Creating Characteristic is alive

LivingCreature()

Creating Characteristic has heart

Animal()

Amphibian()

Frog()

bye!

Amphibian finalize

Animal finalize

LivingCreature finalize

finalizing Characteristic is alive

finalizing Characteristic has heart

finalizing Characteristic can live in water

Макар и редът в който обектите да се финализират да е същия в който се съз­да­ват, технически редът на финализация не се задава. С базовите класове, обаче, има­те пълен контрол върху реда на финализацията. Най-добрият ред е по­ка­за­ният тук, което е обърнатия ред на инициализацията. Следвайки формата из­полз­вана за деструкторите в C++ първо ще финализирате извлечения клас, по­сле базовия. Това е защото във финализацията на извлечения клас би могло да се викат методи от базовия, които трябва да са още живи за това и не бива да се извършва финализация на базовия клас предварително.

Поведение на полиморфни методи в конструкторите

Йерархията на извикване на конструкторите изважда наяве интересна дилема. Ка­кво става, ако сте в конструктора и извикате динамично свързан метод на кон­струирания в момента обект? В обикновен обект може да си въобразим ка­кво­то става – динамично свързаното извикване се решава по време на из­пъл­не­ние, понеже извикващия обек не може да знае дали методът е негов или на из­вле­чен клас. Може за смисленост да се счита, че така става и в случая на кон­струк­тор.

Това обаче не е точно. Ако викате динамично свързан метод вътре в кон­струк­тор, подтиснатата дефиниция на метода се използва. Обаче ефектът може да бъде неочакван и може да докара трудни за улавяне грешки.

Концептуално задачата на конструктора е да докара обекта в живота (което ед­ва ли е тривиално като постижение). През време на работа на конструктора це­лия обект може да е само частично построен – знае се само, че базовият клас е бил инициализиран, но не може да се знае кои класове са наследени. Ди­на­мич­но­то свързване на метод обаче, търси “напред” или “навън” в йерархията на на­сле­дяването. То вика метод в извлечен клас. Ако превите това вътре в кон­структор, викате член който манипулира членове които може още да не са ини­циа­лизиране – сигурна рецепта за катастрофа.

Може да видите проблема в следния пример:

//: c07:PolyConstructors.java

// Constructors and polymorphism

// don't produce what you might expect.
abstract class Glyph {

abstract void draw();

Glyph() {

System.out.println("Glyph() before draw()");

draw();

System.out.println("Glyph() after draw()");

}

}
class RoundGlyph extends Glyph {

int radius = 1;

RoundGlyph(int r) {

radius = r;

System.out.println(

"RoundGlyph.RoundGlyph(), radius = "

+ radius);

}

void draw() {

System.out.println(

"RoundGlyph.draw(), radius = " + radius);

}

}
public class PolyConstructors {

public static void main(String[] args) {

new RoundGlyph(5);

}

} ///:~

В Glyph методът draw( ) е abstract, така че е проектиран да бъде подтиснат. Раз­бира се ние сме принудени да го подтиснем в RoundGlyph. Но кон­струк­то­ра на Glyph вика този метод, извикването свършва в RoundGlyph.draw( ), кое­то изглежда да е желаното. Но погледнете изхода:

Glyph() before draw()

RoundGlyph.draw(), radius = 0

Glyph() after draw()

RoundGlyph.RoundGlyph(), radius = 5

Когато конструктора на Glyph вика draw( ), стойността на radius даже не е на­чал­ната стойност по подразбиране 1. Тя е нула. Това вероятно ще причини точ­ка или нищо да се изобрази на екрана, а вие ще се чуците защо програмата не ра­боти.

Редът на инициализация описан в предната секция не е съвсем пълен, а точ­но липсващата част е ключът към мистерията. Фактическият процес на ини­циа­ли­зация е:

1. 
   Паметта алокирана за обект се инициализира с нула преди да се направи ка­кво­то и да е друго.
   
2. 
   Викат се конструкторите на базови класове както бе описано преди. В тази точ­ка подтиснатия draw( ) метод се вика, (да, преди конструкторът на RoundGlyph да се извика), като стойността на radius е нула, поради т.1.
   
3. 
   Инициализаторите на членове се викат по реда на декларирането.
   
4. 
   Тялото на конструктора на извлечения клас се вика.
   

По-добре е всичко да се инициализира с нула (или каквото нулата значи за кон­крет­ния вид данни) отколкото да е просто боклук. Това включва ма­ни­пу­ла­то­ри­те на обекти които са вградени в обект чрез композиция. Така че ако забравите да инициализирате такъв манипулатор щяхте да полечите изключение по време на изпълнение. Всичко обаче става нула, която обикновено е издайническа стой­ност, видяна в изход от програма.

От друга страна, трябва множко да се уплашите от изхода на тази програма. На­правихте логични предположения и все пак програмата е мистериозно не­вер­на, без оплаквания от компилатора. (C++ има по-рационално поведение в та­ки­ва ситуации.) Бъгове от този род лесно могат да бъдат погребани и да отнемат мно­го време за откриването им.

Като резултат, ето добро правило за конструкторите: “Прави минималното за да стане обекта и ако е възможно, избягвай викането на методи.” Единствените безо­пасни за викане в конструктори методи са тези които са final в базовия клас. (Това също се отнася за private които са автоматично final.) Те не могат да бъдат подтиснати и не могат да донесат такива изненади.

Каталог: Java
Java -> Лекция Изключения. Уравнение на КортевегДеВриз
Java -> Създаване на прозорци и аплети
Java -> Лекция 2 Типове данни. Класове и обекти. Числено интегриране
Java -> Национална академия по разработка на софтуер
Java -> Java за цифрово подписване на документи в уеб
Java -> Запознаване с JavaScript. Запознаване с Java Script
Java -> Програма за изчисляване на средна стойност

Изтегляне 13.53 Mb.

Сподели с приятели: