Här kommer en liten metodikfråga.

Jag bygger ett framework som skall ligga till grund för flera olika applikationer.
Beroende på applikation så finns det vissa objekt som har olika antal egenskaper. Min första tanke är då självklart arv. En baseclass som de olika versionerna ärver ifrån.

En stor nackdel med att sitta själv och jobba är att man inte har något bollplank för sina idéer så jag tänkte kolla om någon här vill ge lite åsikter om detta.

T.ex. mina användare
<code>
UserBase
ID
FirstName
LastName
Email
Password
Active

UserExtended Inherits UserBase
Address1
Address2
Zip
City
Phone
Mobile
Fax
Notes

UserSubscriber Inherits UserExtended
CC
CCMonth
CCYear
CCType
Instructions

UserCompany Inherits UserExtended
Company
Department
Extension
Title
</code>
Nu är dessa lite förenklade, men själva tanken bakom är som sagt att ha en BaseClass som övriga klasser ärver från, och det är väl grunden i objekt-orienterad programmering.

Om man då skapar en UserSubscriber så skulle man i denna klass New() först köra MyBase.New() och sedan fylla sina egna variabler, osv.

Hur känns det här för er övriga OOP-freak?
Ser ni något som talar emot den här tekniken? Grotta inte ner er i själva egenskaperna och att det är Users, jag har samma upplägg för t.ex. produkter (grundprodukter, livsmedel, luftfilter, bilar, m.m.)

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

Jag tycker att de arv du visar i inlägget inte direkt motsvaras av vad som står i litteraturen om OOP. Om man utgår från dina arv så skulle man kunna säga att ett UserCompany har egenskaper som finns i klassen UserBase(ex. FirstName). Sett till verkligheten så låter detta lite märkligt d v s ett UserCompany har väl inte egenskapen FirstName. Min åsikt är att du bör avgränsa dina arv mer.

håller med Ludvig. De två undre ser ut att vara helt egna klasser. Hur skall du annars kunna hantera det faktum att en person kan arbete på två företag samtidigt, eller har flera prenumerationer?

<quote>
Jag tycker att de arv du visar i inlägget inte direkt motsvaras av vad som står i litteraturen om OOP. Om man utgår från dina arv så skulle man kunna säga att ett UserCompany har egenskaper som finns i klassen UserBase(ex. FirstName). Sett till verkligheten så låter detta lite märkligt d v s ett UserCompany har väl inte egenskapen FirstName. Min åsikt är att du bör avgränsa dina arv mer.
</quote>
Jo, en företagsanvändare har FirstName och LastName. UserCompany är alltså en användare som tillhör ett företag, inte företaget i sig. Det finns en annan klass för det, Company.

<quote>
De två undre ser ut att vara helt egna klasser. Hur skall du annars kunna hantera det faktum att en person kan arbete på två företag samtidigt, eller har flera prenumerationer?
</quote>
En prenumerant har en Collection av prenumerationsobjekt och kan på så sätt ha flera prenumerationer.
Situationen där en person arbetar på flera företag har jag inte med. Det ligger flera anledningar bakom, men om man vill kan UserCompany ha en Collection av företag istället.

I ett annat forum fick jag även lite förslag om att man har själva grundklassen Person och sedan har man klasser som Anställd, Ägare, Prenumerant m.m. som inte ärver utan inkluderas i en collection i Person-klassen. Personligen känns det fel för det skulle innebära att man får gå tillbaka och ändra i Person-klassen om det dyker upp nya "roller" som personen kan ha. Annars blir det svårt att ha starkt typade collections.


För att förtydliga lite mer:
-------------------------
En enkel applikation med inloggning har endast behov av de egenskaper och metoder som finns i UserBase.
-------------------------
En Adressboksapplikation behöver de egenskaper och metoder som finns i UserExtended. Men beroende av vad det är för typ av adressbok så kanske man planerar in UserCompany för att få en indelning.
-------------------------
Min kund www.ekoladan.se behöver UserSubscription eftersom det är en prenumerationstjänst.
-------------------------
En projekthanteringsapplikation behöver UserCompany eftersom kundanvändarna kopplas till olika företag. Adminanvändarna behöver UserProject (projektanvändare) som ärver UserCompany eftersom de skall tillhöra och registrera tid på olika projekt.
-------------------------

<quote>
Hur känns det här för er övriga OOP-freak?
Ser ni något som talar emot den här tekniken? Grotta inte ner er i själva egenskaperna och att det är Users, jag har samma upplägg för t.ex. produkter (grundprodukter, livsmedel, luftfilter, bilar, m.m.)
</quote>
Detta förenklade exempel gäller endast användare, men det kunde lika gärna ha varit produkter.
T.ex. En grundprodukt som sedan ärvs av Livsmedel, Luftfilter, Bil, Resa, m.m.
Jag har heller inte tagit med några metoder utan endast några egenskaper.
Frågeställningen i sig gällde alltså själva teorin med arv och OO generellt i era applikationer, inte specifikt vad jag har i mina förenklade exempel. ;)

Risken med OO är ofta att man gör det lite väl komplicerat. Sitter väl i ryggmärgen sen skolan att dela in i så små objekt som möjligt. T.ex. en Extended User skulle kunna ha en collection av Address objekt och en collection av PhoneNumber objekt, osv.

När jag pluggade OO (1996) så fick vi i början lära oss förstå principerna genom "real-life" exempel. T.ex. en läskautomat och en biltvätt och så skulle vi göra så många objekt som gick. Det kunde bli en hel del, ända ner till myntinkastet på läskautomaten och tvåldispensern på biltvätten.

Att jag grottar ner mig i klasser beror till stor del på att de grunder jag gör då enkelt kan användas i både webb- och desktopapplikationer. Sen är ju .NET ett riktigt OO-språk så jag ser ingen anledning att inte göra det när det gäller större projekt.

Hur gör ni själva i era applikationer, ni som jobbar med OO?

/pD
<www.pdc.se>
<www.pdc.se/blog>
<www.patrik-dahlen.nu>

Jag tycker att man skall utgå ifrån de fysiska attributen som t.ex. en användare faktiskt har. Visst i ett projekt kan man ha flera användare, men samma användare kan också ha olika roller i olika projekt. För att avspegla verkligheten anser jag att måste bryta ut den fysiska personen och behandla den för sig och sedan behandla de olika rollerna som den fysiska personen kan ha för sig. Sedan tycker jag inte att man skall vara 100% renlärig utan man får anpassa sig efter vad som är optimalt. Ett exempel om du har en global organisation och vill byta namn på en avdelning, på hur många ställen vill du byta namn?

En bra grej som vi kör med är K.I.S.S. (keep it simple stupid)

En bra tumregel när man jobbar med arv är att man använder sig av uttrycket "Är en/Är ett". Ponera att du har en basklass som heter Person. Utifrån denna klass har du två subklasser Man och Kvinna. En Man är en Person och en Kvinna är en person. Regeln "Är en/Är ett" fungerar bra. För att bevisa motsatsen kan du vända på det och säga: en Person är en Kvinna. Detta påstående stämmer inte. En Person behöver nödvändigtvis inte vara en kvinna, det kan ju lika gärna vara en man.

Arv är en mycket kraftfull mekanism inom OOP men jag tycker att det bör användas på lämplig nivå. Att utveckla en lång arvshierarki kan ibland bli tungrott att arbeta med.

Ett annat tips kan vara att när du modellerat fram en arvshierarki kan du utgå från din subklass längs ner och "stämma av" egenskaperna som finns uppåt i hierarkin. Anta att du har en Bromsklass som i sin tur har 2 subklasser ABS-broms och Standardbroms. Bromsklassen har en egenskap som heter Vikt. Titta på subklasserna och avgör om det är lämpligt att dom skall ha egenskapen Vikt.