Ez hogyan lehetséges a programozásban?

Nem egészen értem, hogy mit akarsz csinálni :D

Esetleg úgy tudom értelmezni a kérdést, hogy azt szeretnéd, hogy a főosztályból(Kutya) olyan osztályokat akarsz létrehozni, amelyek bizonyos tulajdonságokat megtart a főosztályból, másokat meg akár módosít, akkor egyszerűen az új osztályt(Kiskutya) a főosztály alosztályaként kell létrehoznod.

Én így képzelem el:

class Kiskutya {

private Kutya apa, anya;

public Kiskutya(Kutya apa, Kutya anya) { this.apa=apa; this.anya=anya; apa.getGyerekek.add(this); anya.getGyerekek.add(this);

}

class Kutya {

private List<Kiskutya> gyerekek; // +getter

}

De igazából felesleges a Kiskutyára külön osztály, hiszen abból egyszer nagy kutya lesz ugyanúgy. A "kiskutyaság" inkább egy állapot legyen a Kutyában. (Mondjuk egy boolean adattag.)

Ebben annyira nem lehetünk biztosan. Maga a kérdés nem egyértelmű. Hogy jön az objektumorientáltság kontextusában értelmezett öröklődéshez a szaporítás? Most akkor mit is szeretne a kedves kérdező? Kutyaszaporítást szimulálni? Vagy a technikai értelemben vett öröklődésről kérdezne? Egy biztos, az OOP öröklődés-koncepciójának az égvilágon semmi köze nincs a biológiai gyermek-szülő viszonyhoz, öröklődéshez. Sajnos ezt nagyon sok helyen rosszul oktatják.

Ha visszatérünk a kutyaszaporítás szimulációjára, a kutya, az kutya (Hehe, Esőember :D). Semmi értelme nincs külön osztály létrehozni az utódoknak és pláne nem szabad összemosni a szaporítást az OO leszármaztatással. Ezesetben (elnagyolva), valahogy így kellene kinéznie a dolognak:

public class Dog {

˙˙˙˙private final String name;

˙˙˙˙private final List<Dog> children = new ArrayList<Dog>();

˙˙˙˙public Dog(String name) {

˙˙˙˙˙˙˙˙this.name = name;

˙˙˙˙}

˙˙˙˙/*

˙˙˙˙˙* Ez akár Puppy-t is visszaadhatna Dog helyett,

˙˙˙˙˙* de annak itt nincs értelme. "A gatya, az gatya"

˙˙˙˙˙*/

˙˙˙˙public Dog breed(Dog otherParent, String name) {

˙˙˙˙˙˙˙˙Dog child = new Dog(name);

˙˙˙˙˙˙˙˙registerChild(child);

˙˙˙˙˙˙˙˙other.registerChild(child);

˙˙˙˙}

˙˙˙˙private void registerChild(Dog child) {

˙˙˙˙˙˙˙˙children.add(child);

˙˙˙˙}

˙˙˙˙public List<Dog> getChildren() {

˙˙˙˙˙˙˙˙return children;

˙˙˙˙}

˙˙˙˙@Override

˙˙˙˙public String toString() {

˙˙˙˙˙˙˙˙return name;

˙˙˙˙}

}

A #3 kolléga megoldását azért nem tartom szerencsésnek, mert egyrészt átpasszolja a this referenciát, másrészt explicit módon is körbereferálást hoz létre azáltal, hogy a szülőkben eltárolja az utódot, az utódban pedig a szülőket.

Ha egy kicsit jobban leírná, kifejtené a kérdező, milyen problémára keres megoldást, szerintem többet tudnánk segíteni...

#3 vagyok

#5/#7 kollégával nagyrészt egyetértek.

Az OOP öröklődésnek nincs köze a "szaporodáshoz", bármit is jelentsen. A többszörös öröklődés idekeverése pedig végképp irreleváns.

És aláírom, hogy az utóbbi kód elegánsabb, mint amit én tákoltam tegnap. Annyit tennék hozzá, hogy én egy percet sem fordítottam tegnap a gondolkodásra, szép kód kreálására, csak leírtam egy alap ötletet, amiből ki lehet indulni. Több volt amúgy a fejemben, pl. az addChild-ra gondoltam én is, de szimplán lusta voltam begépelni. És azt gondoltam/gondolom, ehhez a kérdéshez ez elegendő volt. :)

Amúgy miért rossz, ha kétirányú a navigáció "szülő" és "gyermek" között? :) (Azon kívül, hogy plusz 2 referenciának helyet kell foglalni objektumonként.) Szerintem bizonyos feladatoknál szükség lehet rá, hatékonyabb, hogy a gyerekből is elinduljunk felfelé a családfán.

"de szimplán lusta voltam begépelni"

Na végre, egy igazi kolléga! :D

A körkörös referencia többeközt a GC-nek okozhat problémát, de szemantikai duplikációnak is vehetjük a dolgot. Ráadásul körkörös dependenciát is eredményez a dolog, ha két osztályról beszélünk. Persze, a megoldásban, a kétirányú összerendeléshez szükséges volt, de ezesetben tényleg éredemesebb kiszervezni egy külön osztályba magát az összerendelést.