Implementering af abstract classes

Arv er til at modellere "is a" egenskaber ikke til at sikre genbrug af vilkaarlig kode.

Standard loesningen er interfaces og saa implementere.

Den alternative loesning er at klistre de ting paa med AOP, som er en smart maade
at tilfoeje faelles funktionalitet af mere teknisk art som ligger ud over
domain modellen.

JEG har lært netop at arv netop er til genbrug så du undgår redundans.

Fx. klassen abstract human
kan have fælles attributter som hjerte, lunger, hjerne etc.
og fælles metoder som Walk(), Eat() etc.

Man kan så nedarve til specialiseringer så som:
CaveMan : Human

som nu har attributter og metoder fra Human. Det da "genbrug af vilkaarlig kode" og det meningen jo.
CaveMan kan så have en anden hjerne (hvis det objekt fx), og andre metoder som HitWomanAndDragByHair().

Fx. SuperBrain
Generelle metoder og attributter
og så har vi
CaveMannBrain : SuperBrain (måske dårligt ordvalg)
som har nogle dyriske indstinker der gør ham lidt vild til tider.

Og man har en moderne hjerne
SofisticatedBrain
som har attributter til tale og skrive og metoder til samme.

Hvis man så har klassen
ModernMann kan han ligeledes nedarve fra human og være en specilisering, MEN hvad nu hvis man så i ModernMann gerne vil ha BÅDE SofisticatedBrain (fordi det er den moderne mand), MEN man også vil have CaveMannBrain (fordi han stadig har sine dyriske urlyster gemt i sig).. Så laver man en ModernMannBrain men kan bare ikke implementere begge dele..
Og du kan ikke specialisere ModernBrain fordi den samme bruger ModernWoman fx. og så er problemet jo du får samme attributter og metoder i både ModernWomanBrain og ModernMannBrain fordi de begge skal bruge de fælles attributter fra SofisticatedBrain men også deres respektive "gammeldags" hjerner..

Og ja du KAN bruge interfaces MEN det hjælper dig ikke ud af du får redundant kode som er noget skrammel for HVAD nu hvis du ændrer noget i koden et sted men glemmer at rette det det andet sted..

AOP? Der tror jeg desværre ikke helt jeg er med længere..
Er det et design mønster? jeg ku se på wikipedia at der noget der hedder "Aspect-oriented programming".. Er det noget af det?
Og hvis det er tilfældet vil jeg meget gerne høre hvordan det kan laves så jeg kan få implementeret begge dele et fælles sted..

Så vidt jeg kunne læse mig ud af det kan den lave referencer til andre kodesteder. Er det lidt alla goto over klasser og ikke kun sektioner der er defineret?
Derudover synes jeg ærligt talt det er lidt tåget og svært lige at fange konseptet i..

Nej. Arv er ikke decideret til at undgaa redundant kode. Arv er til at modellere
generalisering/specialisering. Det har som positiv side effekt at man nogen gange kan
genbruge noget kode.

Ja - AOP er Aspect Oriented Programming. Og det er et rimeligt avanceret koncept. Men
efter min bedste overbevisning velegnet til det du vil.

Med hensyn til arv, saa blev James Gosling (opfinder af Java) engang spurgt
om hvilken feature han fortroed mest i Java og han svarede extends (som er keyword
for arv fra en anden klasse).

Det skal man nok ikke tage alt for bogstaveligt. Men pointen er at det ikke er
godt at arve fordi man lige skal bruge en klump funktionalitet.

Til AOP i C# vil jeg foreslaa AspectDNG.

Jeg kan kun tilslutte mig arne_vs betragtninger, men hvis jeg skal komme med et bud på, hvordan du kan opnå, det du spørger til, vil jeg sige, at du skal se på "composition". Du kan altså lade din logger holde instanser af de andre klasser og viderestille de nødvendige operationer til dem.

Arne v
I min uddannelse som datamatiker har jeg nu lært andet.. Altid undgå redundant data så vidt muligt. Bedre at lave generelt så du slipper for redundant kode og genbrugsværdien er ligeledes større da afhængigheden derved er mindre..
Anyways..
Men tak jeg vil prøve og læse mere op på det.. Hvis jeg ikke kan finde ud af det får du nok nogle spørgsmål omkring det..

kodehoved
composition er det også c#-baseret? Og vil det sige jeg kan "nedarve" metoder som jeg har behov for, eller blot referere til dem så og sige..?

Med al respekt for din uddannelse, så lyder det som om at din underviser ikke har fulgt med tiden. I midten af 90erne var arv løsningen på alle problemer, men konsensus i dag er, at arv skal bruges i begrænset omfang og mere eller mindre kun i de situationer Arne nævner.

Composition er en generel OO-teknik, hvor du i stedet for at bygge dine relationer via arv, gør det via referencer til andre typer. Så hvis A har brug for funktionalitet fra B og C, har A en reference til disse og sørger derefter for at lade disse delkomponenter varetage deres respektive opgaver. Vil du gå skridtet videre, skal du bruge referencer til interfaces fremfor referencer til specifikke typer. Derved opnås langt større fleksibilitet i forhold til test, vedligeholdelse og udvidelse af koden.