Sparring omkring klassediagram

Tags:    uml klassediagram analyse

<< < 123 > >>
Jeg mangler lidt sparring omkring dette klassediagram som er en del af mit afgangsprojekt på min efteruddannelse. Jeg kan kun modtage vejledning og ikke direkte diskussion om indholdet og jeg laver det alene. Så derfor spørger jeg her :-)

Projektet er fra idé til implementering og er en webapplikation hvor en eksisterende bruger kan oprette købs- og salgsannoncer. En annonce kan indeholde et pre-defineret fabrikat. En bruger kan selv bestemme om der kan oprettes kommentarer til annoncen.

Mit analyse klassediagram kan ses her: http://i39.tinypic.com/34h6upt.jpg

Jeg har overvejet om Annonce skulle være abstrakt og indeholde subklasserne købsannonce og salgsannonce, men da forskellen kun er en egenskab på Annonceklassen har jeg ikke fundet det nødvendigt.

Fabrikater kan kun vedligeholdes af en administrator.

En bruger kan enten være bruger, moderator eller administrator. En moderator kan inaktivere annoncer og slette kommentarer. En administrator kan det samme som en moderator + vedligeholde fabrikater.

Men jeg er i tvivl om man i dette meget tidlige klassediagram også beskriver sammenhænge mellem f.eks. Administrator og Fabrikat som i kan se jeg har lavet. Det skal ligesom vise at kun Administrator kan vedligeholde dem. Men er dette korrekt?

Jeg har ikke oprettet controller-klasser, men i stedet lader jeg klasserne styre hændelserne selv. F.eks. forestiller jeg mig, at en annonce opretter "sig selv" ved at lave en:

Fold kodeboks ind/udCSharp kode 


Og andet input til det er velkommen :-)




Indlæg senest redigeret d. 12.03.2012 18:28 af Bruger #9814
21 svar postet i denne tråd vises herunder
5 indlæg har modtaget i alt 24 karma
Sorter efter stemmer Sorter efter dato
Jeg havde valgt at lave en controller, eller et repository pattern til dit db lag. Problemet med det du har lavet nu er at du beder Annonce om at skulle kunne hente og gemme sig selv, dvs. den skal være bevidst omkring din database eller lign. Det bryder lidt SOC princippet (Seperation of Concerns) - og skaber en lav kobling mellem funktionaliteten i din klasse. Sørg for at din annonce har et klart formål, og det er ikke at gemme sig selv, men at holde properties etc for en annonce. Ved eks. SletAnnonce() skal en annonce slette sig selv - hvordan gør man det? sætter man this = null; ? problemet er at det kan du ikke helt gøre på en pæn måde, det kan du derimod med en controller.

Jeg ville også lave alt som interfaces (kod altid mod et interface aldrig mod en implementering), således vil du kunne tage en IAnnonce med ind i din IAnnonceController og derved lave en lavere binding ved at benytte IoC (Inversion of Control).

Det samme er egentligt gældende for alle de andre også.

Kan ikke helt tænke klart nu, men sikkert mere i morgen... håber du kan bruge det...



Der er også noget omkring den forbindelse mellem administrator og fabrikat der irriterer mig en smule. Jeg kan ikke umiddelbart sætte min finger på det, men den irriterer mig, specielt fordi en nedarvning så er meget mere forskellig end blot properties. Er ikke helt sikker på at jeg ville modellere "rettigheder" ind i mit klassediagram, men styre det i implementeringen.



Jeg har vist misforstået diagrammet
bruger, annonce osv er mere 'roller' end klasser?


Nej, det er skam et klassediagram ;-)


Jeg har tit en opdeling i model, service og repository. Dvs. modellen (klassen) indeholder kun properties, servicen indeholder kun funktioner som søg, beregn osv... mens repository står for at gemme og læse fra db. Noget lignende dette: http://bit.ly/wqR8y8


Dvs. at din serviceklasse er det jeg kalder controllerklasse?


Jepsen, jeg deler det nogle gange mere op, alt afhængig af hvor kompleks en løsning jeg laver. Dvs, opdeling af "beregninger" og "udtræk", således bliver et repository en samling af ud/ind opeartioner, mens service bliver en samling af beregninger fx. search, exists, calculateTax, osv.

Det giver dot altid nogle udfordringer omkring at holde opdelinge, specielt når man introducerer repositories/controllers, for er det det samme objekter man bør eksponere til sin grænseflade som man har i sin database? (se evt.: http://blog.ploeh.dk/2012/02/09/IsLayeringWorthTheMapping.aspx)

Igen, det er lidt off-topic, det er min personlige præference.



De andre har sagt det meste, men jeg vil lige tilføje følgende (som bare er en mening).

Hvad giver mest mening. Den her:
Fold kodeboks ind/udKode 


eller
Fold kodeboks ind/udKode 


Alle metoder på 'Annonce' objekter gør vel noget med et 'Annonce' objekt, så hvorfor indkode det i metode navnet ?

Det er lidt som at have 'bruger_navn' og 'bruger_id' på et 'Bruger' objekt, som mange har for vane.



Indlæg senest redigeret d. 13.03.2012 12:59 af Bruger #2695
Når der snakkes om et konceptuelt klassediagram, så vil jeg helt holde repositories ude af den sammenhæng. Som jeg ser det, så bruger man det conceptuelle til at finde de objekter der findes i ens domæne og beskrive de relationer/associationer/knytninger som de pågældende objekter har.

Når der snakkes om klassediagrammer som en afspejling af den reele kode (ikke konceptuelt) så vil jeg helt sikkert have repositories med for nu er det relevant. Samtidig kan man "måske" bruge den konceptuelle diagram overfor en given kunde, og så er repositories kun støj, hvis de ikke har den store kundskab.



Offtopic, hvilket program har du brugt til at tegne dit diagram med? :)



Offtopic, hvilket program har du brugt til at tegne dit diagram med? :)


Jeg bruger programmet Enterprise Architect som vi også bruger hvor jeg arbejder.



Tak for kommentaren. Jeg er slet ikke omkring design tankerne endnu. Så spørgsmålet er om jeg skal implementere et repository pattern allerede her i mit konceptuelle klassediagram. Måske skulle jeg helt droppe hændelses/klasse sammenkoblingen på dette tidlige tidspunkt.

Men jeg tror jeg vil prøve at lave et nyt klassediagram hvor jeg benytter repository mønstret. Eller også "nøjes" jeg med controller klasserne, da det er mere velkendt for mig.



Der er også noget omkring den forbindelse mellem administrator og fabrikat der irriterer mig en smule. Jeg kan ikke umiddelbart sætte min finger på det, men den irriterer mig, specielt fordi en nedarvning så er meget mere forskellig end blot properties. Er ikke helt sikker på at jeg ville modellere "rettigheder" ind i mit klassediagram, men styre det i implementeringen.


Og der synes jeg, at du har helt ret. Jeg havde også kun taget den ene med som eksempel da jeg var meget usikker. Jeg dropper det, da det ikke er en del af strukturen.

Tak igen!




Den 'Rigtige' Brian,
Hvis du vil have ikke-skolet input må du gi lidt mere ramme .. der er osse en database og det 'lever' i en asp/php sammenhæng. Eller hur?

Man kan forestille sig at bruger og annonce er et 'hurtigt' udtræk fra databasen og som sådan et overflødigt/misvisende klasse-grundlag.




<< < 123 > >>
t