Nedarvs Eksempel - er dette godt nok??

- du må ikke nedarve fra en klasse der er final
- du må ikke lave cirkulære nedarvning
- du må ikke nedarve fra Enum<--ikke helt sikker på den der
- du må ikke lave en generic klasse der nedarver fra Throwable

Idiot reglerne:
- du kan ikke nedarve en outer class i en inner class
- du kan indlysende nok ikke nedarve fra ting der ikke er klasser.

Tror nok jeg har sagt det her før, men læs specificationen

1000 tak for tipsene.
Men har jeg lavet illustrationen korrekt? Ud fra beskrivelsen? Den er jo meget conceptuel...

Det her er på sin vis et fint eksempel på hvorfor arv som oftest er halv dårlig ide.

Jeg kan huske i software arkitektur, lavede vores forelæser en (ment som oplæg til diskussion) nedslagtning af den skandinaviske oop model og arv, og jeg er sådan set enig med ham, arv er (næsten) ubrugeligt.

Kigger vi så på den amerikanske roller og ansvars model, så er person, student og employee roller, hvilket groftsagt kan oversættes til interfaces. og så virker det lige pludseligt, da du kan implementere alle de interfaces du ønsker.

Arv er naturligvis ikke helt ubrugeligt, men selv bruger jeg det stortset kun til at lave (abstrakte) standard implementationer af interfaces for at undgå noget boilerplate kode.

synes nu nedarvning er særdeles brugeligt så man slipper for at kode det samme 2 gange, men bare kan nedarve, f.eks. i Java hvor man bare kan nedarve fra Applet og så har man en Applet, ville sikkert være seriøst trælst at skulle kode Applets kode hver gang. Selfølgelig giver nedarvning kun mening såfremt man har generel kode som man kan forventes at kunne bruge mere end en arvende klasse. Medmindre der er tale om sprog med fler nedarvning, der kunne man sikkert også bruge nedarvning som en union.

Det er altid let at være enig med en anden persons synspunkter især når man ikke siger hvad disse er, men det er jo storset umugligt for andre at være enig eller uenig med disse usynlige synspunkter.

Hej Alle,

Det var da noget af et interessant frontalt angreb på nedarvning som design...

Nej, jeg syntes ikke at det viste billede viser nedarvning godt. Fordelen ved nedarvning er IKKE at der bliver oprettet et hiraki af klasser, men at metoder videreføres og dermed kan antages at eksistere.

Det er så hver hvor "interface fanatikere" kommer ind og siger at det sikrer et interface også. Og ja, det gør de. Og ja, men kan implementere flere interfaces. Men interfaces kan ikke indeholde en "default implementation" af en metode. Dermed vil interfaces forlange at hver eneste klasse der implementerer interfacet skal have sin egen implementation af en pågældende metode.

Abstract klasser er altså smarte, fordi at man kan gentage kode i mange klasser. Og når koden så skal vedliogeholdes (læs, den nedarvede metode forandres) er det kun "moder klassen" som skal forandres. Ved et interface skal alle underklasser rettes.

Du bør dog skydes i foden hvis du implementerer en abstrakt klasse, kun indeholdende abstrakte metoder - dette er et interface.

Med venlig hilsen
Ieet

Wow... hold da op... det er guld det her, haha.
Det kan jeg bruge til min eksamen.

Ieet,

Hvad er forskellen på en abstrakt klasse og et interface. Er det ikke 2 sider af samme sag?
Et interface indeholde "kravspecifikationer", dvs metoder uden metode-kroppen, som man selv skal udbygge. Abstrake metoder er jo det samme... indgår de i en absrakt klasse??

Wow... hold da op... det er guld det her, haha.
Det kan jeg bruge til min eksamen.

Ieet,

Hvad er forskellen på en abstrakt klasse og et interface. Er det ikke 2 sider af samme sag?
Et interface indeholde "kravspecifikationer", dvs metoder uden metode-kroppen, som man selv skal udbygge. Abstrake metoder er jo det samme... indgår de i en absrakt klasse??

Så vidt jeg husker så har man implamenteringen med i en abstrakt klasse, der fortælle hvilke implamentationer der skal med.

Hej Henning,

Meget kort sagt, i en abstrakt klasse kan du have implementationen med. Som Martin skrev.

Forskellen er:
Interfaces understøtter multipel subtyping.
Abstrakte klasser tillader fuldt implementerede metoder.

Med venlig hilsen
Ieet

@Nørden: hvis du læser min sidste linje, så benytter jeg faktisk arv til det problem du beskriver med applet.

Problemet med arv er at jeg (og mange andre mennesker) ikke kan finde et eneste arkitektonisk eksempel et hvor kompositionelt design IKKE er bedre end arv (tro mig, vi har prøvet), og ud fra en impirisk indgangvinkel, så må vi jo hælde til at arv ikke er nødvendigt.

Anvendelsen begrænser sig således til Template Method Patternet i GoF.

Ved anvendelse af arv skaber du en kraftig kobling mellem klasserne, samt at du er ikke i stand at lave små variationer billigt.

@Henning: En abstakt klasse er en du ikke kan instantiere, men kun arve fra, dette gør at du kan lave en standard implementation af noget kode der ellers ville gentage sig, uden at skulle levere en fuld implementation.

@Ieet: Jeg garanterer for at Kristen Nygaard ruller i graven lige nu.

Hej Troels,

Jeg ved ikke hvem Kristen Nygaard er, eller hvorfor al den rullen omkring...

Af nysgerrighed, hvem er "vi" som har prøvet?

Et eksempel på god nedarvning;
I et spil;
Felter er en "moder" klasse.
Gras, Skov, Vej, Bjerg, Vand er alle under klasser.

Creature er en moder klasse.
NPC, og Player er under klasser.
Animal, Humanoid, Demon, Undead har NPS som moder klasse.
Og hvis NPC klassen ønskes formindsket har man også implementeret enten "AggressiveNPC_IF" eller "FriendlyNPC_IF" interfaces.

Jeg ville gerne komme med eksempler på at arv bliver benyttet hvopr jeg arbejder. Men fortrolighedserklæringen siger at jeg så skal save dit venstre ben af og spise det inden jeg må. Men skal vi ikke skyde på at "Konto" er en moder klasse.

Med venlig hilsen
Ieet