Проектиране с наследяване

Чисто наследяване vs. разширяване

Това може да се означи като чиста “е” зависимост понеже интерфейса на клас я опре­деля. Наследяването гарантира, че извлечените класове ще имат не по-мал­ко от интерфейса на базовия клас. Ако проследите горната диаграма, из­вле­че­ни­те класове също ще имат не повече от интерфейса на базовия клас.

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


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

Ако гледаме по този начин изглежда, че чистата “е” е единствения смислен на­чин да се направят нещата, всеки друг дизайн индицира междинно мислене и по опре­деление е "фалшив". Това също е капан. Щом стъпите на тази плоскост на мис­лене ще се огледате наоколо и ще откриете че разширяването на интерфейса (което, за нещастие, ключовата дума extends изглежда да подпомага) е пер­фект­ното решение на всеки частен проблем. Това може да бъде окачествено ка­то “прилича-на” зависимост защото извлеченият клас е като базовия клас – има същия основен интерфейс – но има други черти които изискват до­пъл­ни­тел­ни методи за реализацията си:

…


Докато това също е полезен и смислен подход (в зависимост от ситуацията) той има и недостатък. Разширената част на интерфейса на извлечения клас не е достъпна от базовия клас, така че като се направи ъпкаст не може да се викат новите методи:

…

Ако не се прави ъпкаст в този случай, това няма да ви безпокои, но често ще по­падате в ситуации където ще трябва да преоткривате точния тип за да може да използвате съответните методи. Следващата секция показва как се прави то­ва.

Даункастинг и идентификация на типа по време на изпълнение

В някои езици (като C++) трябва да се изпълни специална операция, за да се по­лу­чи безопасен кастинг, но в Java всеки каст се проверява! Така че даже и да из­глежда че се прави само единичен каст в скоби, по време на изпълнение се про­верява дали типът е този който се очаква. Ако не е, получава се ClassCastException. Тази дейност за проверка на типовете по време на из­пъл­не­ние е наречена run-time type identification (RTTI). Следващият пример де­мон­стри­ра поведението на RTTI:

//: c07:RTTI.java

// Downcasting & Run-Time Type

// Identification (RTTI)

import java.util.*;

public void f() {}

public void g() {}

}
class MoreUseful extends Useful {

public void f() {}

public void g() {}

public void u() {}

public void v() {}

public void w() {}

}
public class RTTI {

public static void main(String[] args) {

Useful[] x = {

new Useful(),

new MoreUseful()

};

x[0].f();

// Compile-time: method not found in Useful:

//! x[1].u();

((MoreUseful)x[1]).u(); // Downcast/RTTI

((MoreUseful)x[0]).u(); // Exception thrown

}

} ///:~

Ако искате да използвате разширения интерфейс на обект от клас MoreUseful мо­же да опитате с даункаст. Ако типът е коректен, всичко ще стане. Иначе ще по­лучите ClassCastException. Не е необходимо да пишете специален код във връз­ка с това, понеже то индицира програмна грешка която се проявява където и да е в програмата.

Има повече за RTTI отколкото прост каст. Например има начин да се види точ­ния тип преди опита за даункаст. Цялата глава 11 е посветена на изучаването на иден­тификацията на типовете по време на изпълнение в Java.