Jeg har lavet et lille hieraki med nogle metoder på nogle abstract klasser. Disse er fx. debug-metoder, skrivTilFil-metoder, exceptionhandling-metoder etc. Meningen er disse skal bruges til en logger MEN men men.. Min Debug-Logger skal have metoderne fra både ImplDebug (debug metoderne) og ImplException (Exception handling) men hvordan kan dette løses når c# ikke tillader nedarvning fra flere klasser men kun flere Interfaces?
jeg ved jeg kunne impl. et interface MEN så forsvinder det smukke ved hierakiet for så hvis noget skal ændres ved exception-metoderne vil jeg skulle rette to steder og det jo ikke ret smuk kode.
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.
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.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
