OO domein model

[Verwijderd]

Beste,

Ik ben momenteel bezig met het maken van een programma om berichtjes te verzenden via het net send commando. Nu ik zit een beetje vast met mijn klasse model

Ik heb volgende

klasse ContactPerson, welke de naam bevat van mijn contactpersoon, alsook de Netbios naam van die persoon zijn pc

Klasse NetSend is een klasse die het bericht uiteindelijk gaat verzenden.

Klasse Connection, dit is een klasse die in een thread gaat pingen naar een bepaalde pc om te zien of die pc online is.

Ik heb hetvolgende gedaan in mijn klasse ContactPerson heb ik dus een verwijzing naar mijn klasse Connection -> zodat connection kan doorgeven of de contactperson online is.

In klasse NetSend heb ik een verwijzing naar ContactPerson omdat we moeten weten of de persoon zijn pc opstaat en we moeten ook de netbois naam hebben.

1) Vraag is dit goed opgesteld
2) in contactPerson zou je in feite ook een methode send kunnen hebben die dan de Netsend klasse oproept zei iemand me, maar ik redeneer als volgt een object van een bepaalde persoon gaat toch geen bericht naar zijn eigen sturen, ik vind het logischer dat een netsend object een methode send heeft die een bericht stuurt naar een bepaalde contactpersoon.

Alvast bedankt om jullie inzichten met mij te delen

[whoami]

Tja, het is moeilijk te zeggen of het goed is opgesteld imo , aangezien we niet echt functionele eisen weten.
Over 2: Er zijn altijd meerdere wegen die naar Rome leiden; echter denk ik ook dat het beter is om de Send method geen member methode te maken van ContactPerson.

Wat ik me een beetje afvraag, is het nut van die Connection class. Als ik het zo lees, veronderstel ik dat die Connection class voortdurend naar bepaalde pc pingt om te zien of deze online is of niet ?
Als dit zo is: waarom ? Waarom kan je gewoon niet in je Send method checken of de pc van de ContactPerson naar wie je wilt senden online is ?

En hoe ziet die NetSend class er uit ? Waarom heb je in NetSend een verwijzing naar ContactPerson ?
Kan NetSend bv geen class zijn met een static member 'Send', die als argument één of meedere ContactPerson objecten meekrijgt ?
bv:

code:

ContactPerson p = new ContactPerson(...);
NetSend.Send (p, message);

[Verwijderd]

Wel die Connection class moet constant blijven pingen om dat ik zo een effect wil bereiken zoals in msn messenger, als er een persoon online is zou ik bij die persoon een groen lampje willen krijgen en als die off is een rood, dus kan ik in feite altijd zien of iemand online is

Netsend heeft een verwijzing naar contactperson omdat we op die manier de netbios naam kunnen te weten komen, zodoende weten we naar welke pc het bericht moet worden gestuurd
Ook vind ik het mooier om hier een object door te geven in plaats van gewoon een string met een netbios naam.

Functionele eisen zijn om een soort van msn achtig ding te hebben maar dan voor het lokale netwerk -> zodat ik altijd kan zien of iemand online is, in feite is vooral het doel OO manier van denken te trainen, omdat ik momenteel op mijn werk procedureel moet werken

[whoami]

Als je die ContactPerson doorgeeft aan de SEnd method, dan weet jouw send method toch ook naar waar dit bericht moet verstuurd worden ?

[Verwijderd]

ja das waar dat klopt :-)

Daarjuist die kennis op msn gezien die zei om de send in mijn contactperson klasse te zetten.
Ik had hem gevraagd waarom hij daar zo overdacht, hij was aan het denken aan het msn principe dus dat je moet dubbelklikken op een contactpersoon dan komt er een venster en daar kun je dan op send drukken

Blijf dit toch maar raar vinden :-)

[Verwijderd]

Hoe kun je nu bvb het beste kiezen of je een object in een methode plaatst zoals bvb

in ContactPerson klasse -> in de methode Send()
public void Send(){
NetSend.Send();
}

Of dat je beste volgende doet
in NetSend klasse in de methode Send()
public void Send(ContactPerson cp){
//logica om bericht te verzenden naar de contactpersoon
}

Dat is bij mij altijd een probleem ik zie niet goed welke van die aanpakken ik zou moeten nemen in feite lijken ze beiden te kloppen

[JHS]

Aangezien het verzenden van een bericht me geen eigenschap van een contactpersoon lijkt, hoort het denk ik níet in de Send ContactPerson class, maar eerder in je controller / aanroepende code, die dan inderdaad een ContactPerson object meelevert. Volgens mij is het het handigst om je bij dit soort vragen steeds af te vragen wiens verantwoordelijkheid iets nu is, en van wat iets een eigenschap is .

edit:

.

[ Voor 5% gewijzigd door JHS op 10-04-2006 20:28 ]

[whoami]

Niet in de ContactPerson class bedoel je ?

[Jaap-Jan]

En even volgens de manier van JHS:

Bij communicatie tussen personen en dingen heb je altijd:

verzender --> medium --> ontvanger.

In dit geval zijn verzender en ontvanger een persoon, maar het medium is het netwerk. Als je het dan wilt modelleren krijgt NetSend een send()- commando, omdat dat het medium is in het geval van dit stuk software.

[whoami]

Idd, wat ik ook al zei.

[Verwijderd]

allemaal bedankt voor de antwoorden, ik zit nu echter met nog een klein probleempje, ik heb juist een paar artikels gelezen over Modeling,waarin wordt gezegd dat we alle concepten uit het domein in klassen moeten vertalen.

Probleem! --> Voor sommige belangrijke zaken neem nu netbanking heeft men een username en een pasword nodig, aangezien men op beide zaken gaat testen of ze met elkaar overeenkomen, is dit toch wel een belangrijk concept
Nu wat denk ik voor alle belangrijke zaken moet men een klasse hebben dus dit komt overeen met een klasse Pasword en een klasse Username, nu de inhoud van beide klassen is 1 enkele string.
De logica van het model zegt dat deze belangrijk zijn dus in feite worden dit klassen (objecten), maar aangezien ze maar uit 1 enkele string bestaan, zou je gewoon 2 strings kunnen gebruiken en ze respectievelijk username en pasword noemen.

Ik zou persoonlijk gaan om er 2 aparte klassen van te maken, kwestie van de logica van het model mooi te behouden, maar natuurlijk is er nog iets zoals prestaties, meerdere objecten die moeten gecreeërd worden enzo.

Hoe denken jullie hierover? Zouden jullie mijn idee volgen om er aparte klassen van te maken en de domeinlogica echt mooi duidelijk te houden, of is dit hier van minder belang en kunnen we er gewone strings van maken?

alvast bedankt

[JHS]

Ik het persoonlijk onzin vinden om een aparte username en password class te gaan maken, terwijl je ze ook gewoon als eigenschap van een user kan zien.Het is wel zo dat je alle entiteiten uit het domein in classes moet stoppen, maar ik denk dat een password/username eerder een eigenschap zijn van de entiteit User, dan aparte entiteiten.

Als je op de 'alles is een entiteit' manier zou redeneren zou een class eigenlijk maar één eigenschap mogen hebben, wat dan de waarde zou zijn van de entiteit die die class beschrijft.

[Scare360]

Verwijderd schreef op maandag 17 april 2006 @ 01:23:
artikels gelezen over Modeling,waarin wordt gezegd dat we alle concepten uit het domein in klassen moeten vertalen.

Probleem! --> Voor sommige belangrijke zaken neem nu netbanking heeft men een username en een pasword nodig, aangezien men op beide zaken gaat testen of ze met elkaar overeenkomen, is dit toch wel een belangrijk concept

De vraag is of user/pwd "het concept" is of het identificeren, authentificeren en autoriseren van gebruikers.

[JHS]

paulgielens schreef op maandag 17 april 2006 @ 09:19:
[...] De vraag is of user/pwd "het concept" is of het identificeren, authentificeren en autoriseren van gebruikers.

Eerlijkgezegd denk ik dat die twee redelijk los van elkaar staan. De username / password zijn in mijn ogen eigenschappen van User, terwijl authorisatie veel meer een handeling is van een Login class, waarbij door de gebruiker geleverde gegevens vergeleken worden met die van een persistent User.

[H!GHGuY]

JHS schreef op maandag 17 april 2006 @ 09:32:
[...]
Eerlijkgezegd denk ik dat die twee redelijk los van elkaar staan. De username / password zijn in mijn ogen eigenschappen van User, terwijl authorisatie veel meer een handeling is van een Login class, waarbij door de gebruiker geleverde gegevens vergeleken worden met die van een persistent User.

with stupid ^^

in veel gevallen kan je je objecten opstellen adhv de realiteit. In dit geval kunnen username/pwd bijna nooit een aparte entiteit vormen. Wanneer je (bvb zoals bij Kerberos) je username/pwd inwisselt voor een ticket (token) waarmee je dan weer dingen kan, dan kun je die ticket wel als klasse zien.

Zie het als in een pretpark. Je toont je gezicht (username) en geeft geld (paswoord) en daar krijg je een ingeangsticket (token) voor terug. Dit token is fysisch en verschaft je toegang tot bepaalde attracties.
behoorlijk in het extreme getrokken, maar veelal kom je tot een goed model door vanuit de realiteit te redeneren.

vergeet bovendien niet dat strikt gezien in OO-talen als Java/C# alles reeds objecten zijn (evt mits boxing). int, double, string zijn allemaal klassen...

[EfBe]

HIGHGuY schreef op maandag 17 april 2006 @ 09:43:
vergeet bovendien niet dat strikt gezien in OO-talen als Java/C# alles reeds objecten zijn (evt mits boxing). int, double, string zijn allemaal klassen...

In Java is een value type (int) geen object. In .NET strict genomen wel (ValueType derived van Object), maar in de praktijk ook niet. (boxing).

[CH4OS]

Weet niet of je er aan gedacht hebt...
Maar dat pingen, kan toch alleen maar zien of een PC daadwerkelijk online is? Dus dan hoeft de PC maar aan te staan en je kan een bericht versturen (En dat is natuurlijk ook wel de bedoeling )

Maar... Kunnen er in jouw netwerk niet steeds andere mensen op een andere PC zitten?
Dus stel dat Kees op de PC van Karel zit... Als je dan een message tikt voor Karel... Maar Kees zit er achter, dan zal die wel raar op kijken lijkt me...

Of iedereen moet altijd op zijn / haar eigen plekje gaan zitten, maar je weet maar nooit

[ Voor 11% gewijzigd door CH4OS op 17-04-2006 15:16 ]

[Verwijderd]

JHS schreef op maandag 17 april 2006 @ 08:25:
Ik het persoonlijk onzin vinden om een aparte username en password class te gaan maken, terwijl je ze ook gewoon als eigenschap van een user kan zien.Het is wel zo dat je alle entiteiten uit het domein in classes moet stoppen, maar ik denk dat een password/username eerder een eigenschap zijn van de entiteit User, dan aparte entiteiten.

Als je op de 'alles is een entiteit' manier zou redeneren zou een class eigenlijk maar één eigenschap mogen hebben, wat dan de waarde zou zijn van de entiteit die die class beschrijft.

het probleem is: de eigenschappen kunnen ook klassen zijn, in alle artikels /boeken die ik heb gelezen kan ik maar geen lineaire manier vinden van hoe kan je nl bepalen of een attribuut een klasse moet zijn, dan wel een primitief type / string.
Dus zoals paswoord waarom geen klasse maar wel het paswoord als string, ik besef ook wel dat deze werkwijze een zekere vorm van over kill is maar ik zoek een richtlijn ofzo

[JHS]

Je moet volgens mij niet alles in richtlijnen, documenten en dat soort dingen willen proppen . Het blijft voor een deel ook gewoon fingerspitzengefühl. Het enige wat je er denk ik over kan zeggen is dat het over het algemeen zo is dat als het niet nodig is, je het dan ook niet moet doen.

edit:

En nodig is dan misschien zoiets als: Het heeft meerdere eigenschappen, het heeft methodes nodig, dat soort dingen.

[ Voor 19% gewijzigd door JHS op 17-04-2006 17:08 ]

[Verwijderd]

Mjah het lijkt me wel heel logisch wat je zegt met betrekking tot performatie enzo ook, maar dit gaat haaks in tegen wat een collega me zei nl:

ik had een programmatje geschreven om mijn Dvd's bij te houden, ik had klassen zoals daar zijn Dvd, borrower enzo
Nu in Dvd had ik een eigenschap Genre, waar ik verder niets wou meedoen, geen opzoekingen in de database op genre enzo. Dit moest gewoon bestaan om aan te duiden in welk type dvd's dit viel.
Mijn collega vertelde me dat dit zeker en vast een klasse moest worden om dat dit toch een belangrijk concept in mijn domein was.
Ik kwam dus uit op een klasse Genre met als enig lid van de klasse een eigenschap genre die als een string geimplementeerd was.

Hierdoor kwam ik tot mijn logica nu van Pasword enzo


bedankt

[Verwijderd]

Verwijderd schreef op maandag 17 april 2006 @ 17:30:
Mjah het lijkt me wel heel logisch wat je zegt met betrekking tot performatie enzo ook, maar dit gaat haaks in tegen wat een collega me zei nl:

ik had een programmatje geschreven om mijn Dvd's bij te houden, ik had klassen zoals daar zijn Dvd, borrower enzo
Nu in Dvd had ik een eigenschap Genre, waar ik verder niets wou meedoen, geen opzoekingen in de database op genre enzo. Dit moest gewoon bestaan om aan te duiden in welk type dvd's dit viel.
Mijn collega vertelde me dat dit zeker en vast een klasse moest worden om dat dit toch een belangrijk concept in mijn domein was.
Ik kwam dus uit op een klasse Genre met als enig lid van de klasse een eigenschap genre die als een string geimplementeerd was.

Hierdoor kwam ik tot mijn logica nu van Pasword enzo

ohja wat als je dan naderhand toch van je attribuut een klasse wil maken, dit houdt dan toch veel meer refactoring werk in, ook had ik gelezen in practisch uml dat als je twijfelt het beter is om van het attribuut een klasse te maken

bedankt voor jullie antwoorden alvast


bedankt

[JHS]

TomVdH: Tja, dat is dan maar zo, in mijn ogen. Je moet volgens mij niet alles zo OO doorgedraafd mogelijk gaan lopen doen omdat dat in de toekomst wellicht nuttig zou kunnen zijn. Als je écht twijfelt zou ik inderdaad eerder voor een class gaan, maar daar was in dit geval in mijn ogen totaal geen sprake van .

[JJ Le Funk]

GJ-tje schreef op maandag 17 april 2006 @ 15:16:
Weet niet of je er aan gedacht hebt...
Maar dat pingen, kan toch alleen maar zien of een PC daadwerkelijk online is? Dus dan hoeft de PC maar aan te staan en je kan een bericht versturen (En dat is natuurlijk ook wel de bedoeling )

Maar... Kunnen er in jouw netwerk niet steeds andere mensen op een andere PC zitten?
Dus stel dat Kees op de PC van Karel zit... Als je dan een message tikt voor Karel... Maar Kees zit er achter, dan zal die wel raar op kijken lijkt me...

Of iedereen moet altijd op zijn / haar eigen plekje gaan zitten, maar je weet maar nooit

Agreed. De specs van dit tool-to-be verdienen nog wat aandacht. Zoals het nu gebouwd wordt is de houdbaarheid wel erg beperkt.

2 dingen:
* De verificatie aan de hand van ip-adres is te summier. Het identificeert niet persé de gebruiker van het systeem, danwel de juiste inlogstatus;
* Als de koppeling tussen IP en persoon verandert (een zekerheid), is het tool niet meer bruikbaar. Enige flexibiliteit is erg wenselijk (database?).

[whoami]

Verwijderd schreef op maandag 17 april 2006 @ 17:30:
Mjah het lijkt me wel heel logisch wat je zegt met betrekking tot performatie enzo ook, maar dit gaat haaks in tegen wat een collega me zei nl:

ik had een programmatje geschreven om mijn Dvd's bij te houden, ik had klassen zoals daar zijn Dvd, borrower enzo
Nu in Dvd had ik een eigenschap Genre, waar ik verder niets wou meedoen, geen opzoekingen in de database op genre enzo. Dit moest gewoon bestaan om aan te duiden in welk type dvd's dit viel.
Mijn collega vertelde me dat dit zeker en vast een klasse moest worden om dat dit toch een belangrijk concept in mijn domein was.
Ik kwam dus uit op een klasse Genre met als enig lid van de klasse een eigenschap genre die als een string geimplementeerd was.

Hierdoor kwam ik tot mijn logica nu van Pasword enzo

Tja.... Voor een 'Genre' kan je idd wel een class maken, maar dat is weer heel iets anders dan een passwoord.
Als je het in tekst gaat uittypen: Op een DVD staat een film, en een film behoort tot een genre.
En: een gebruiker heeft een passwoord.
Als je deze 2 zinnen leest, dan kan je toch uit die eerste zin opmaken dat Genre een entiteit is, en in de tweede zin, dat passwoord een eigenschap is van gebruiker.

Waarom zou je voor passwoord in godsnaam een aparte class willen maken ? Een passwoord is geen entiteit, het is een eigenschap die tot één gebruiker behoort (al kunnen verschillende gebruikers hetzelfde passwoord hebben, maar als gebruiker A, die hetzelfdde paswoord heeft als gebruiker B, zijn wachtwoord veranderd, wil dat niet zeggen dat het passwoord van gebruiker B daarmee ook veranderd wordt).
Bekijk het ook eens vanuit een DB ontwerp bv: voor Genre zal je idd een aparte tabel maken, maar voor passwoord niet. Paswoord zal gewoon een column zijn in de user - tabel.

MrJayMan schreef op maandag 17 april 2006 @ 17:43:
[...]


Agreed. De specs van dit tool-to-be verdienen nog wat aandacht. Zoals het nu gebouwd wordt is de houdbaarheid wel erg beperkt.

Daar is moeilijk iets zinnigs over te zeggen, aangezien wij de eisen natuurlijk niet kennen. 't Kan perfect zijn dat dit perfect voldoet aan de eisen van de gebruiker.

[ Voor 29% gewijzigd door whoami op 17-04-2006 18:37 ]

[H!GHGuY]

EfBe schreef op maandag 17 april 2006 @ 14:21:
[...]

In Java is een value type (int) geen object. In .NET strict genomen wel (ValueType derived van Object), maar in de praktijk ook niet. (boxing).

offtopic:
idd, in Java en .NET zijn value-types geen objecten.
Java kent echter de Integer klasse en .NET de Int32 struct.

Ik wou dus zeggen dat je (met boxing) dus alles als een object kan zien.