Allmän fråga om klassuppbyggnad...

Fundera kring vad som menas med objekt. Vad ska ett objekt innehålla och vad finns det för likheter mellan olika objekt? Dessa likheter kan du ju exempelvis samla in i en överklass som du i Java med fördel bakar in abstrakt i ett interface... att bara bygga på funktionalitet lite hipp som happ leder ofta till en enda soppa som även direkt strider mot objektorienteringen ;)

Ex.
En stol är en möbel som har fyra ben. En annan möbel har kanske 6 st ben. Då är det smart att kanske ha ett interface som skvallrar om vad varje möbel har för antal ben, men varje klass får själv ansvara för det exakta antalet. Men det är inte intressant för en stol att tala om ifall soffan har 42 sittplatser så den funktionaliten är utanför "ramen".

Du kanske inte blir klokare av just det jag ovan skrev, men faktum är att det handlar om design och vad du tänker dig att dina objekt ska motsvara :)

hehe.. a jag tror nog att mitt är "hipp som happ" modellen.. hmm.. funderar lite.. jag vet inte alls vilka "objekt" jag har.. sitter med Swing fönster och en XML fil.. GUI:t var det tänkt skulle möjliggöra manipulation av XML:n..

du nämnde interface.. är inte det bara som en tom definition eller nåt... som säger vad som får finnas eller inte finnas i en klass.. eller..? vet inte, men kanske som en DTD eller schema för en XML..? som ett regelverk.. har för mig att ActionListener t.ex. är ett interface.. det är därför man får fel när om man glömmer ha med ActionPerformed.. typ det är bra att ha interface pga. att man ska komma ihåg hur man ska använda nåt eller..? (kan vara helt ute o cykla :)

I mitt fall, hur ska jag ta reda på vad basklassen är, och vad den ska innehålla.. och sen detaljer som de här småfunktionerna som jag tidigare lade på ad hoc... hur vet jag var de hör hemma och vem som ska ärva ifrån vem.. hehe.. kanske blir lättare ju mer man håller på.. ska försöka fundera på sånt tills nästa gång..

Det är inte trivialt så där rakt av, med OO. Ofta fastnar man i ett imperativt tänkande och då ballar det lätt ur..

Tänk som sagt igenom vad som menas med "objekt" och tänk på den funktionalitet som du vill tillföra ett objekt som dess egenskaper. En leksaksbil och en gummiboll är båda leksaker, men endast en av dem är trevlig att studsa med... så därför har gummibollen och bilen olika egenskaper.

Äh, jag är nog inte så pedagogisk. Försök läsa en bok om OO! :)

Hej Pew, jo, förr eller senare bör jag nog läsa ordentligt hur det fungerar... tar nog för lång tid o bara testa sig fram.. så kanske man lär sig fel dessutom.. tack för att du försökte förklara iaf ! Det hjälpte lite grann :)

Börja med att fundera på vilka ansvar varje objekt skall ha. Det är den absoluta grunden.

Ett tips för att undersöka om man skall ärva egenskaper eller aggregera (innehålla) är att fråga sig: "is a" och "have a", det vill säga: Är C en A eller har C en A.

Det är som Pew redan sagt ganska svårt att lite snabbt förklara objektorienteringens grunder och det är självklart bra med en bok!

Du ha en mycket hälsosam inställning när du säger att

förr eller senare bör jag nog läsa ordentligt hur det fungerar... tar nog för lång tid o bara testa sig fram.. så kanske man lär sig fel dessutom..

:)

Hittade en pdf som förklarar grundbegrepp och ger lite exempel.
Håll till godo :)

Hej Jon, a tack för länken ! Läste igenom den lite snabbt.. den gav en bra överblick så det var bra :)

satt o funderade lite.. jag har en bokningsapplikation. Därifrån vill jag kunna göra Add (A), Insert (B), Update (C), och Delete (D) (och var och en utav dessa kan jag göra till egna klasser (?).

Är det så att man kanske kan tänka sig att

basklass Z

Z "har" snarare än "är" (som du sa) grafik metoder och ska då ärva dessa (?) (ex makeButtons, makeLabels etc.. ) från en annan klass (G)..

Z "har" också massa XML funktioner (som ligger i klass X) (här kunde jag t.ex lägga countNrOfCases() kom jag på)

Eftersom Z inte kan ärva både G och X måste G först ärva från X, o sen Z ärver G..?

Så nu så "är" A, B, C, D instanser av Z och ska då (innehålla/aggregera) Z då..? (När du säger "innehåller", det är då du menar att man ska instantiera objekt kontra att skriva extends?)

Sen, ska det vara så att metoder som används av mer än en klass ska ligga högre i klasshierarkin..? Och om det bara är en klass ska kan man lägga metoderna direkt i klassen?

hmm.. funderade lite till

Pew skrev:

Fundera kring vad som menas med objekt. Vad ska ett objekt innehålla och vad finns det för likheter mellan olika objekt? Dessa likheter kan du ju exempelvis samla in i en överklass

Egentligen så är ju A, B, C, D metoder.. (behaviour).. när ska man göra klasser av dem och när är det okay att de ligger inbäddade i en annan klass? ABCD använder inte alla Grafik och XML funktioner i G och X klasserna.. så G och X borde bara innehålla det som används av alla klasser (t.ex alla klasser måste iaf kunna koppla till XML filen, men alla behöver inte kunna göra Delete).

hehe.. nä, nu blev jag ännu mer förvirrad.. inser att det nog inte går att svara rakt av på detta.. jag ska återkomma om nån månad eller ett par när jag har läst på mer o har smalare frågor.. :) Tack för svaren igen !

Nej, du är på rätt spår. Om vi tar just Bokning som exempel.
En Bokning är en bra klass att ha. Tänk dig att du har en Bokning på ett papper framför dig. Den innhåller en massa data om Bokningen; namn, resmål, pris o.s.v.

Men det är inte Bokning som ska göra add(), remove() o.s.v.

Nej, för det behövs någon som hanterar bokningen. När jag vill göra en bokning på telefon så ringer jag till en bokningsperson, en som hanterar bokningar. Hos denna lägger jag min bokning.

I oo skulle man då skapa en BokningsHanterare som har metoderna add(Bokning b), remove(Bokning b), find(Bokning b) ... alltså allt som man annars skulle behöva göra med en bokningsperson. Så du ska inte göra funktioinerna Add, Delete... till klasser utan du måste koppla beteendet till föremålet som gör detta.

Anta nu att du har ett system som klarar av att göra olika typer av Bokningar t.ex. InternetBokning och TelefonBokning. I ditt system så lägger man till båda i BokningsHanteraren med add(...). Om man då har en basklass till InternetBokning och TelefonBokning som heter Bokning och som innehåller alla de attribut som BokningsHanteraren behöver för att lagra bokningen. De saker som är speciellt med InternetBokning och TelefonBokning läggs i respektive klasser.

Om du sedan vill ha ut en XML-fil från bokningshanteraren för att kunna skicka t.ex. till Star (flygbolagssystemet) så implementerar man en metod som kan heta något i stil med getBokningsXML().

Lite knepigt att förklara när man inte vet kraven på systemet...

ah, det var jätteintressant.. läste det du skrev några gånger.. aha.. a just det.. så man har en klass BokningsHanterare som motsvarar det en människa gör (lägger till, uppdaterar bokningar).. där finns metoderna då (add, insert osv). Detta är min basklass då..?

Sen själva Bokningen sa du, den gör ju ingenting, utan den innehåller bara data.. alltså det är min XML fil i det här fallet.. ?(vanligtvis antar jag att man lagrar i en "riktig" databas, o sen vid behov genererar XML för att skicka relevant data till inblandad tredje-part som du skrev... fast just nu skriver jag direkt till XML o sparar där.. får göra om senare :)

Så.. hmm.. du skrev t.ex. att man InternetBokning.. Jag hade tänkt att använda servlets för att generera mostvarande GUI som jag redan har i Swing, fast då i HTML.. så då skulle de klasserna ärva från min basklass då antar jag.. hehe.. fast nu är det massa små detaljer som jag har problem med så det dröjer nog..

lät förresten som om du kanske t.o.m. hade gjort nåt sånt här system (tänkte att du beskrev Star osv..? :) Tack för svaret.. får återkomma ang. detta när det blir dags o skriva om applikationen så det blir mer OO på det :)

Jo, man kan nog säga att jag har gjort, gör, kommer att ha skolen gören.

En sak med Objektorienterade språk är att de program man skapar inte hänger ihop genom arv. Klasserna InternetBokning och TelefonBokning ärver båda från klassen Bokning. Men om man klurar lite kan man föreställa sig att InternetBokning används i en serverapplikation där det är en Servlet som tar emot data från en webbsida och skapar en ny bokning men när man ringer in så vill inte telefonisterna sitta med en browser så de har en fristående applikation som skapar bokningar av typen TelefonBokning.

Däremot har inte klassen BokningsHanterare något arv till Bokning eller vice versa.

Det är ganska enkelt att objektorientera så länge det går att matcha ett-till-ett. Det knepiga blir när man börjar göra lite större system får då måste man börja med "konstruerade" objekt.

En kursdeltagare som jag hade i kursen "Objektorienterad analys och design med UML" sa ungefär följande:

Objektorientering är lite som schack; det tar 20 minuter att lära sig reglerna och en livstid att bemästra.