Walker
I så fall så skulle jag istället skapa en klass för en person. Denna personen har sedan en roll Anställd som också är en klass. Anställd innehåller mao ett person objekt, men ärver inte från person objektet. Samma person skall kunna bli ägare i företaget, genom att tilldela en ägarroll till detta person objekt.
Ja, det upplägget är ju också en tanke. Ska titta lite närmare på det. Tack för tipset om boken också
Overload
Jag förstår inte riktigt upplägget, men kanske är det för att jag inte är något vidare på hela OOP-snacket.
Är UserBase och UserExtended egna klasser? Och vad gör/är alla benämningar som ID och FirstName, för de är ju inte metoder i klassen iallafall?
Ja, alla är egna klasser. Jag har inte tagit med några metoder här utan bara egenskaper. UserBase är grundklassen som de övriga ärver från. I övrigt så ärver UserBase från en annan Base-klass där jag har gemensamma metoder som behövs på andra ställen också.
Jon
Enilgt skolbokens alla regler känns ditt upplägg bra.
Problemet som jag brukar stöta på är att man kanske gör saker och ting lite väl komplicerade ibland. Rent programmeringsmässigt kan det bli väldigt mycket enklare att hantera endast en userclass även om man kan bryta ner den och overheaden i just detta fallet är inte särskilt stor.
Ja, det blir lätt att man driver iväg och gör saker lite väl komplicerade. Bryter ner allt i minsta beståndsdelar, osv. Det är nog något som sitter i ryggmärgen sen skoltiden. ;)
Att använda bara en userclass har självklart slagit mig, men anledningen att jag gjort så här är att jag i min första version av ramverket byggt 4 olika applikationer. Mina User-klasser har uppkommit från vad jag använder i de olika applikationerna. Det minsta jag behöver för en applikation är det som är i UserBase.
Men som sagt, nu gäller detta inte bara användare utan även t.ex. produkter.
Men jobbar man mycket med t.ex roller tycker jag att din modell kan passa bra in eftersom det säkert tillkommer funktioner som endast är dedikerade för vissa roller också.
Japp, jag jobbar med roller. Utöver dessa klasser har jag Role, Permission, PermissionCategory, osv. Varje UserBase-klass har t.ex. en collection av roller.
Det jag ser som mycket positivt i sammanhanget är att du inte har gjort som ack så många andra och utgåt från en datamodell utan har tänkt objekt/klasser från början.
En stor fördel är att du slipper aggregera t.ex company och department som ju är klasser i sig själva där det inte behövs.
Det är just det här som gjort att jag tänker så här. Om jag har en basic-applikation så har jag aldrig några behov av något annat än UserBase.
Fortsätt att utveckla dina idéer och gör gärna ett UML-diagram så blir det lättare för utomstående att förstå hur du tänker
Jo, jag har ett UML-diagram också, det började bli för stort för att hålla kontroll över det annars. :)
En sak: eftersom alla ärver UserExtended kan steget UserBase->UserExtended kännas överflödigt i mina ögon.
Anledningen till att dessa två är uppdelade är att jag i mina små applikationer aldrig har användning för det som finns i Extended. Det kändes naturligt att göra en uppdelning.
Spango
Det beror på hur du tänker använda dem. Finns det något tillfälle då du verkligen kommer behöva att använda t.ex. en UserSubscriber på samma sätt som en UserCompany? Om ja, fortsätt på din inslagna väg. Om nej, avbryt. Ärv inte för att spara dig själv besväret att skriva några variabelnamn igen, utan för att du faktiskt behöver polymorfismen.
[/user]
Jag använder alla mina User-klasser på samma sätt, det är därför jag använder arv.
Om man jämför de två applikationerna jag har idag som använder UserSubscriber och UserCompany så använder de båda alla egenskaper och metoder från Extended och Base. Däremot så har de ingen användning för den andres egenskaper och metoder.
Men när det gäller just dessa två så måste jag ta en runda till, jag är inte helt säker på att det aldrig kommer dyka upp möjligheten att UserCompany behöver det som finns i UserSubscriber. Man kan ju inte förbereda för allt och det tänker jag inte göra, det är därför jag har mina klasser istället så om det dyker upp nya behov så ärver jag från dessa och skapar en ny unik klass med andra egenskaper.
I användar-fallet så kommer jag även i en annan applikation behöva en projektanvändare som ärver UserCompany.
Jag använder inte arv för att spara mig själv något besvär. Jag skriver om allt så många gånger att det inte spelar någon roll. ;)
