[UML/OO] Methodes voor het 'ophalen' van alle instanties

[Verwijderd]

Een vraag over ontwerp van klasses met een classdiagram. Als je een klasse ontwerpt geef je die methodes die logisch zijn voor een instantie van die klasse. Maar voeg je ook de methoden toe die logisch zijn voor de gehele verzameling of een subverzameling van de instanties?

Voorbeeld: de posts in dit forum. Zijn instanties van een klasse Post. Klasse Post heeft waarschijnlijk methodes als create(), update() enz. Heeft die klasse in het ontwerp ook een methode getAll() die alle instanties van Post voor een bepaald Topic 'ophaalt'?

Of is dat een detail dat naar voren komt uit de relatie tussen de klasse Topic en Post (een Topic bevat meerdere Posts) en dus niet expliciet als methode gemodelleerd hoeft te worden?

[Woy]

Volgens mij heb jij het over data akties? Dus het ophalen van een Post uit de database. Meestal maak je hier aparte klasses voor dus bijvoorbeeld PostDB. Een class Post hoeft tenslotte niet zelf te weten hoe hij opgeslagen wordt. Die verantwoordelijkheid kan je beter ergens anders leggen. Dus komt het ook niet in je class diagram bij Post maar in je class diagram bij PostDB

[Alarmnummer]

Verwijderd schreef op donderdag 13 oktober 2005 @ 11:36:
Een vraag over ontwerp van klasses met een classdiagram. Als je een klasse ontwerpt geef je die
methodes die logisch zijn voor een instantie van die klasse.

Niet altijd. Soms is het handiger om bepaalde stukken logica te groeperen op basis van functionaliteit en niet op basis van data (dat is een fout die veel beginnende oo-programmeurs maken).

Maar voeg je ook de methoden toe die logisch zijn voor de gehele verzameling of een subverzameling van de instanties?

Nee. Hiervoor introduceer je vaak zo`n ander object. Bv een PersonRepository.

Voorbeeld: de posts in dit forum. Zijn instanties van een klasse Post. Klasse Post heeft waarschijnlijk methodes als create(), update() enz. Heeft die klasse in het ontwerp ook een methode getAll() die alle instanties van Post voor een bepaald Topic 'ophaalt'?

Dit is imho geen goeie aanpak. Je mixt namelijk data access code met domain objecten. Ik introduceer liever een object die het database aspect oplost: een DAO (Data Access Object). Vaak heb je per domain object ook een DAO.

dus:

personDao.delete(jan).

ipv een:

jan.delete();

En in jouw geval heb ik op de dao vaak een:
List personList = persoonDoa.findall();
of
List personList = persoonDao.findByHaarkleur(rood);

Of is dat een detail dat naar voren komt uit de relatie tussen de klasse Topic en Post (een Topic bevat
meerdere Posts) en dus niet expliciet als methode gemodelleerd hoeft te worden?

[/quote]
Dat is afhankelijk van de situatie. Als je bv een order met orderregels hebt, dan wil je bijna altijd de orderregels ook gebruiken als je die order nodig bent. Dus order heeft dan en order.getOrderRegels();

In andere gevallen is dit minder belangrijk en stap ik naar een dao toe, vb:

List orderregels = orderDao.findAllOrderregels(order).

Het is een beetje afhankelijk van de situatie of relaties ook hard gemodeleerd gaan worden binnen je object model of dat je dit via een dao doet.

[ Voor 5% gewijzigd door Alarmnummer op 13-10-2005 11:46 ]

[Verwijderd]

Snap ik het goed dat de consequentie een verdubbeling van het aantal klassen is? Een voor de klasse en een voor het bewerken van de data van een klasse?

[Alarmnummer]

Verwijderd schreef op donderdag 13 oktober 2005 @ 11:50:
Snap ik het goed dat de consequentie een verdubbeling van het aantal klassen is? Een voor de klasse en een voor het bewerken van de data van een klasse?

Yep.. Maar met goeie tools, een goeie or-mapper, en een goed stuk verstand is dit meestal echt minimaal.

vb. ik hoef alleen het volgende te doen als ik een dao wil.

code:

class PersonDao extends HibernateDao{
      public PersonDao(SessionFactory factory){
             super(factory,Person.class);
      }
}

En dan heb ik de meest gebruikte functies wel: save, update, delete, findAll etc etc. Dus in de praktijk heb je daar bitter weinig last van.

[edit]
En het is geen class voor het bewerken van de data. Je brengt het database aspect van een class onder in een andere class. Basis logica + data blijft gewoon in je 'hoofd' class aanwezig.

[edit2]
Ik zal het nog bonter maken. Vaak introduceer je zelfs nog een object: een service object. Hierin staan alle functies die voor de 'buitenkant' van het systeem belangrijk zijn, vb:

code:

class EmployeeService{

       void fire(Employee e){
              e.fire();//stel de fired on datum bv in... en de status stelt die bij bv.
              employeeDao.save(e);
       }
}

Het voordeel van deze service objecten is dat het eenvoudiger is om transacties en security over heen te plaatsen. Je weet verder dat dit voor de buitenwereld de enigste manier is om je objecten aan te passen, dus het is ook veel eenvoudiger om logica erop te zetten.

code:

class EmployeeService{

       void fire(Employee e){
              e.fire();//stel de fired on datum bv in... en de status stelt die bij bv.
              employeeDao.save(e);

              if(e.isAfdelingshoofd())
                     sendMailto(directeur,"afdelingshoofd is ontslagen");
       }
}

[ Voor 51% gewijzigd door Alarmnummer op 13-10-2005 12:10 ]

[Verwijderd]

Mooi, moeilijk voor mij, maar wel mooi. Bedankt voor deze info, ik ga weer verder studeren hierop.