Jag har ett problem med realiseringen av en del av ett klassdiagram. Det är en kombination av komposition och generalisering/specialisering. Hej. Vad jag har förstått så ska aggregat av typen komposition vara klasser i klassen. Ok. Aggregat är när något består av något annat. Ok, jag förstår vad du menar. Det kanske är en smakfråga det där hur man kodar aggregat. Men jag tar till mig av dina åsikter. "Det kanske är en smakfråga det där hur man kodar aggregat" Tack för tipsen. Jag tror mig har hittat en lösning som passar bra.OOA och OOP (aggregat och generalisering/specialisering)
Jag ska försöka förklara det så tydligt som möjligt och hoppas att någon kan hjälpa mig på vägen.
I en e-butik har vi en klass vid namn Varupaket. Varupaketet innehåller en eller flera klasser av typen Vara i form av ett aggregat.
Vara är i sin tur en superklass och kan vara av typen Tjänst eller Produkt.
I UML-digrammet ser allt bra ut, men jag har som sagt problem att överföra detta till kod.
Klassen Varupaket innehåller alltså ett antal objekt av typen Vara. Så här ser det ut:
<code>
Public Class Varupaket
...
Public Class Vara
...
End Class
End Class
</code>
Därefter har vi de två subklasserna till Vara, enligt följande:
<code>
Public Class Produkt
inherits Vara
...
End Class
</code>
<code>
Public Class Tjanst
inherits Vara
...
End Class
</code>
Hur gör man då detta programmeringsmässigt? Om man instansierar ett objekt av typen Varupaket vill man alltså få någon form av array med objekt av typen Vara. Men eftersom detta endast är en superklass till Produkt och Tjänst så blir det problem. Hur får vi tillgång till dessa klassers metoder och egenskaper vid instansieringen av Vara?
Tacksam för alla typer av förslag.
/BrattenSv: OOA och OOP (aggregat och generalisering/specialisering)
Alltså för att det är ett aggregat behöver du inte göra en class i en class.
Din klass Varupaket består av Varor. Om jag fattat allt rätt.
<code>
public class VaruPaket
{
protected Vara[] varor;
...
}
public class Vara <--- Entitets klass
{
Properties.....
}
</code>
Vad jag inte är med på är vaför Tjänst ärver vara?
Sedan så är ju produkten en sak tills man valt att köpa den då blir det en vara.
Så det ärvet är oxå lite knepigt tycker jag.
JNSv: OOA och OOP (aggregat och generalisering/specialisering)
Jag kan förstå att du blev vimsig av upplägget. Bäst att förklara definitionerna lite..
Vara i detta systemet är en klass som innehåller generella egenskaper och metoder för både tjänst och produkt. Tjänst och produkt är alltså bägge av typen Vara. Detta oavsett om den är köpt eller ej.
Hoppas jag klargjorde något.Sv: OOA och OOP (aggregat och generalisering/specialisering)
Ex Bil består av Hjul. När Bil dör så dör hjulen med bilen. Motor är ett aggregat till bil etc... Ett aggregat måste inte vara en nestlad klass. Jag undviker netlade klasser i de flesta fall, de ger bara mindre flecxibilitet. Då der kräver en helt ny build av alla klasse r i hierarkin, vid ändring i en av dem.
I Mitt exempel ovan är Vara ett aggegat. När din basklass dör dödas ävan varorna i den.
JNSv: OOA och OOP (aggregat och generalisering/specialisering)
Däremot så är jag mer intresserad av hur man gör med subklasserna till klassen Vara (dvs Tjänst och Produkt). Som i ditt exempel då du instansierar Vara i Varupaket. Hur får man funktionaliteten med subklasserna att fungera då?
Jag vill ju komma åt de specialicerade klassernas metoder. Om det är en Produkt det rör sig om vill jag få den instansierad. Likaså med Tjänst.
Förstår du vad jag menar?Sv: OOA och OOP (aggregat och generalisering/specialisering)
Det är mer ett förhållande som avgör hur du kodar det hela. Aggregat kan kodas på många olika sätt. Ditt sätt går oxå bra men det blir inte lika felxiblet.
Jag är inte riktigt med i frågan om tjänst. Här kommer lite allmän förklaring som kanske kan ge svar på din fråga?
Du kan skapa en proerty som är av typen Vara eller Varor, då kommer du åt dess funktioner från denna klass.
<code>
public class VaruPaket
{
protected Vara[] varor;
...
public Vara[] Varor
{
get{ return varor; }
set{ vator = value; }
}
public VaruPaket()
{
...
}
}
public class Vara <--- Entitets klass
{
Properties.....
ex:
public string Name
{
get{...;}
set{...;}
}
}
....
VaruPaket varuPaket = new VaruPaket();
... lägg till varor i VaruPaket (om inte konstruktorn gör detta...)...
Vara vara = varuPaket.Varor[0];
string namn = varuPaket.Varor[0].Name;
</code>
Var det detta du undrade om?
När du sedan ärver Vara i tjänst så kommer du ju åt dem som vanligt.
<code>
Tjänst tjänst = new Tjänst();
tjänst.Name <--- Vara klassens publica property Name;
</code>
PS, set att du kodar VB .Net hoppas du förstår C# koden jag skriver. Kör enbart C# så det går fortare att skriva ex i det. Ds.
JNSv: OOA och OOP (aggregat och generalisering/specialisering)
Angående aggregat så är min uppfattning att nestlade klasser ska användas om relationen är i form av en composition. Dvs ett starkare aggregat än shared eller vad det kallas. Ett objekt som inte har något att göra utanför det andra objektet ska vara nestlad.
Ha det bra.