Jag har ett problem som skulle vara enkelt att lösa med multipla arv men eftersom det inte stöds så undrar jag om det finns något annat bra sätt att lösa det på.

Jag har följande design: Frontend - Controller - Executer. All kommunikation här emellan sköts av WCF där alla metoder är OneWay.

I min frontend så vill jag starta en executer och skickar ett meddelande till controller om att jag vill starta en executer och controller skickar sedan meddelande vidare till rätt executer att den skall startas. Mycket av denna kod är likadan i frontend som det är i controllern.

Här skulle jag vilja skapa en basklass som innehåller StartExecuter som ärvs av frontend och controller (de små skillnader som finns löses med abstrakta metoder) inga problem. Men nu skall Executer skicka tillbaka meddelande om att den har startas till controllern och sedan skall controllern skicka tillbaka till frontenden att executer har startats. Det skulle man kunna lösa genom att skapa en basklass som innehåller ExecuterStarted() metod som executer kan ärva, problemet blir att controllern inte kan ärva denna klass, eftersom controllern redan ärver basklassen som innehåller StartExecuter().. argghhh..

Jag funderade på någon statisk hjälpklass som skulle kunna innehålla den gemensamma koden, men det fallerar på att jag inte kan göra några abstrakta metoder som kan anropas gemensamt men exekveras på olika sätt beroende på om det är frontend/controller/executer som vill skicka meddelandet.

Just nu är jag j-vligt sur på MS för att de inte implementerade multipla arv i .NET vilket gör att jag får ha en massa kod som ser precis likadan ut på olikaställen i min kod...

Någon som har tips på hur jag kan lösa det...

- M

Kort svar: Interfaces

http://msdn2.microsoft.com/en-us/library/87d83y5b(VS.71).aspx

http://msdn2.microsoft.com/en-us/library/ms173156.aspx
http://msdn2.microsoft.com/en-us/library/87d83y5b.aspx

kan du använda dig av compositon då ?

http://www.primos.com.au/primos/Default.aspx?tabid=64

http://en.wikipedia.org/wiki/Object_composition

Arv skall ju typ används i de fall då klassen är av samma sak inte för att Underlätta funktioner.
Då får du fel OO i din OOP.

Du borde ju ha en Motor klass om man säger så. Själva Mamma klassen som sköter allt åt dig.
Denna kan du ju koppla på event som du sedan lyssnar av på så sätt genom att ändra lite i din
tanke bör du ju få en väldig flexibel lösning som inte bryter mot OO lagarna (om man vill följa dem strikt)

mvh Johan

"Kort svar: Interfaces"

Tja Interfaces kommer jag inte ifrån eftersom det handlar om implementation av WCF services. Samt att intefaceses inte hjälper mot problemet att jag får duplikativ kod, som jag eftersträvar.

- M

"Arv skall ju typ används i de fall då klassen är av samma sak inte för att Underlätta funktioner.
Då får du fel OO i din OOP. "

Beroende på hur man ser det så är klassen av samma typ, båda klasserna skall kunna ta emot samma meddelande på samma sätt.

"Du borde ju ha en Motor klass om man säger så. "

Problemet är ju att jag har 2 motor klasser. En för att köra motor framåt och en för att köra motor bakåt. Visst kan man slå ihop dessa, men det vill jag inte eftersom det är bara en av de 3 klasserna som jag vill skall kunna köra både bakåt och framåt, de andra 2 klasserna skall antingen köra framåt eller bakåt.

"väldig flexibel lösning som inte bryter mot OO lagarna"
Om det underlättar mitt arbete och jag slipper ha samma kod på 2 olika ställen, så är jag mer än villig att bryta mot värre lagar än så :)

"Denna kan du ju koppla på event som du sedan lyssnar av "
Det skulle kunna vara en väg runt det, jag skapar en statisk klass (eller en singleton kanske är bäst) som innehåller de methoder som jag vill, och där som jag tänkte anropa en abstract method skulle jag istället kunna kasta ett event som den som refererar till den statiska klassen får lyssna på. Inte speciellt snyggt, men åstakommer det jag vill.

- M

>Problemet är ju att jag har 2 motor klasser. En för att köra motor framåt och en för att köra motor >bakåt. Visst kan man slå ihop dessa, men det vill jag inte eftersom det är bara en av de 3 klasserna >som jag vill skall kunna köra både bakåt och framåt, de andra 2 klasserna skall antingen köra framåt >eller bakåt.

Hum...
En fråga?
För vem är det du inte vill att 2 klasser skall kunna göra både och? Kör du automagisk kod som triggar både fram och bak alltid? Om inte utan du själv valt när fram och bak skall köras så ser inte jag några som helst problem att ha sådan funktion även om den inte används om man inte vill exponera utt vissa metoder så kommer vi till interface igen som "gömmer" metoder för 2 klasser men inte för den du
vill skall kunna nyttja den.

Det låter lite som ditt designval har satt dig i problemet...
En bil kan både köra fram och bak men vill man ta bort backen så plocka bort det aggregatet. :-)
Samma val kan du göra i din kod.

Sedan av detta att dömma:
>Men nu skall Executer skicka tillbaka meddelande om att den har startas till controllern och sedan skall >controllern skicka tillbaka till frontenden att executer har startats.

Låter som ett event/delegate fall..

mvh Johan

"Det låter lite som ditt designval har satt dig i problemet... "
Designen är det inget fel på :)

"Låter som ett event/delegate fall.."
No can do :(. De 3 olika applikationernena var av det kan finnas multipla instance av Frontend och Executers. Är helt separerarde ifrån varandra och kommunicerar endast via envägs WCF methoder. Det betyder att varje applikation är både en server och en klient. Och det finns inga referenser mellan dem där jag kan låta event signaleras...

"Om inte utan du själv valt när fram och bak skall köras så ser inte jag några som helst problem att ha sådan funktion även om den inte används om man inte vill exponera utt vissa metoder så kommer vi till interface igen som "gömmer" metoder för 2 klasser men inte för den du
vill skall kunna nyttja den. "

Okej så jag lägger alla metoder i en basklass och väljer sedan för respektive applikation vilka metoder det skall "implementera" via interfacet. Det är lite förenkelt? vad är kruxet? Varför kunde jag inte komma på det själv? Hur dum är jag egentligen? (obs behöver ej besvaras :)) Eftersom det bara är jag som använda mig av basklassen så borde det fungera hur bra som helst, även om det inte blir riktigt lika snyggt, men fy vad skönt att slippa ha samma kod på 2 ställen, det är värt mer än lite skönhet...

Tack för att du visade mig ljuset....

- M