Hur lägga upp strukturen på en applikation?

Skall utveckla en applikation tillsammans med min grupp på IT-universitetet. Vi har gjort en E/R-modell, task list mm. Jag har en hel del frågor som jag gärna skulle vilja få svar på.

1. Hur delar man upp vilka klasser som man ska ha? Ska man utgå från entiteterna på E/R-modellen? Något mer man kan tänka på?

2. Metoder som behövs i klasserna finns det något speciellt sätt att komma fram till dessa? Exempelvis genom att titta på attributen i E/R-modellen?

3. Applikationen skall förutom detta ha ett grafisktanvändargränssnitt och koppling till en databas. Hur löser man detta på bästa sätt? Vart ska lyssnarklasserna ligga? Ska alla SQL-frågor ligga som metoder i databasklassen?

Det som jag har svårt att förstå är hur allt ska fungera tillsammans, dvs hur det ska knytas ihop. Finns kanske något exempel på nätet?

oj oj, ingen som har svar på mina frågor? :(

Lite OT, men i alla fall.

Compusa skrev:

oj oj, ingen som har svar på mina frågor? :(

Frågeställningen var intressant, och jag tror nog många wF-medlemmar sitter inne på bra svar, tankar och ideér kring frågan. Däremot tror jag nog inte att du kan förvänta dig någon expressleverans när det gäller svar, utan du får nog räkna med att ibland få vänta mer än någon timme. :)

Har funnit nyckeln till mitt problem och det är MVC, Model View Controll.

Behöver du inte koppla in UML i det hela för att få det förståerligt?
Vill du redovisa resultatet hår på wF tror jag många skulle finna det intressant.

Förmodligen kommer jag (vi) köra en något förenklad variant. Det här med UML är mer än vad jag begriper än så länge.

Lasp skrev:

Behöver du inte koppla in UML i det hela för att få det förståerligt?
Vill du redovisa resultatet hår på wF tror jag många skulle finna det intressant.

Nu har vi börjat läsa om UML i kursem Technical Analysis & Design, oj oj vilket ämne, känns väldigt stort men ack så viktigt. En dansk föreläsare från IT-universitetet i Danmark som vi blir utbildade av.

Har köpt kurslitteraturen:
- Sommerville, Software Engineering
- Larman, Applying UML and Patterns

Bra en till här på wF som anar kraften i UML.
Välkommen i gänget. All programutveckling måste dras igenom den här vägen. Hoppas att vi alla orkar och förstår. Lycka till.

Lasp skrev:

Bra en till här på wF som anar kraften i UML.
Välkommen i gänget. All programutveckling måste dras igenom den här vägen. Hoppas att vi alla orkar och förstår. Lycka till.

Det kanske skall nämnas att det finns alternativ till UML.
Och att inte alla utvecklare tycker att de alternativen oftast är bättre eller är bättre i vissa lägen.

Inte för att jag är någon fanatiker av något av det men tyckte det behövde tillägas.

"Kraften i UML"... Tillåt mig hångarva. Det är lika mycket kraft i UML, som är en notationsform, som det är i C++, som är ett programeringsspråk.

UML för UML's skull är totalt meningslöst.

Det som Compusa ställde som fråga är jätteviktigt och i princip helt omöjligt att svara på... Lite som att fråga "hur långt är ett snöre". Dock svarar C på det själv genom att nämna MVC, som är ett vanligat förekommande design pattern.

Just design patterns är väldigt bra. De visar "best practise" för många standardproblem. De ger även riktlinjer för hur man kan strukturera liknande problem. UML är en bra notationsteknik för att beskriva hur man skall dela in det i klasser och hur specificeringen och realiseringen av klasser och metoder ser ut.

För att släppa ut lite "hemligheter" som vi lär ut i våra kurser "Design Patterns" och "Arkitekturdesign":
- Undvik dubbelriktade beroenden mellan två paket
- Sträva till att ha så få statiska beroenden mellan delsystem/paket som möjligt.
(Minsta antal enkelriktade beroenden = (antal delsystem - 1)
Exempel 2 delsystem: Minst 1 statiskt enkelriktat beroende
4 delsystem: Minst 3 statiska enkelriktade beroenden
7 delsystem: Minst 6 statiska enkelriktade beroenden

Största antal enkelriktade beroenden = summaserie till (antal delsystem - 1), dvs. 1 + 2 + ... + (antal delsystem - 1)
Exempel
2 delsystem: Max 1 statiskt enkelriktat beroende
4 delsystem: Max 6 statiska enkelriktade beroenden
7 delsystem: Max 21 statiska enkelriktade beroenden
Ju färre statiska beroenden desto bättre!)
- Beroenden från förändringsbenägna delar till stabila.
- ABSOLUT INTE PÅ NÅGRA VILLKOR CIRKULÄRA BEROENDEN.

Lite generellt om design av klasser:
- Varje klass ansvarar för manipulering av sina egna attribut. Mao, har du en integer antal i klassen Räknare så skall du inte göra Räknare.antal++ från någon annan klass utan implementera metoden Räknare.adderaEtt().
- Gör inte för stora klasser.
- Gör inte klasser som "gör allt". Låt varje klass bara ansvara för en liten del av logiken.
- Undvik överdesing.
- Lär dig design patterns och använd och anpassa dessa.

Det två böckerna du har köpt är otroligt bra.

/Lime

> Lime
Jag beklagar den mycket otydliga formuleringen.
"UML för UML's skull är totalt meningslöst." Helt rätt.
Se mitt svar som ett snabbt sammanfattade av de första inläggen. :birp :birp :birp
Och jag kan inte skylla på nått!

Och när vi ändå är inne på designpatterns så vill jag rekommendera, som den brukar kallas; GOF. Gang of Four.

Design Patterns - Elements of Reusable Object-Oriented Software
ISBN: 0-201-63361-2

Code Complete (ny utgåva nyligen) är också rätt trevlig att läsa om man är ute efter struktur.

Lime skrev:

"Kraften i UML"... Tillåt mig hångarva. Det är lika mycket kraft i UML, som är en notationsform, som det är i C++, som är ett programeringsspråk.

UML för UML's skull är totalt meningslöst.

Det som Compusa ställde som fråga är jätteviktigt och i princip helt omöjligt att svara på... Lite som att fråga "hur långt är ett snöre". Dock svarar C på det själv genom att nämna MVC, som är ett vanligat förekommande design pattern.

Just design patterns är väldigt bra. De visar "best practise" för många standardproblem. De ger även riktlinjer för hur man kan strukturera liknande problem. UML är en bra notationsteknik för att beskriva hur man skall dela in det i klasser och hur specificeringen och realiseringen av klasser och metoder ser ut.

För att släppa ut lite "hemligheter" som vi lär ut i våra kurser "Design Patterns" och "Arkitekturdesign":
- Undvik dubbelriktade beroenden mellan två paket
- Sträva till att ha så få statiska beroenden mellan delsystem/paket som möjligt.
(Minsta antal enkelriktade beroenden = (antal delsystem - 1)
Exempel 2 delsystem: Minst 1 statiskt enkelriktat beroende
4 delsystem: Minst 3 statiska enkelriktade beroenden
7 delsystem: Minst 6 statiska enkelriktade beroenden

Största antal enkelriktade beroenden = summaserie till (antal delsystem - 1), dvs. 1 + 2 + ... + (antal delsystem - 1)
Exempel
2 delsystem: Max 1 statiskt enkelriktat beroende
4 delsystem: Max 6 statiska enkelriktade beroenden
7 delsystem: Max 21 statiska enkelriktade beroenden
Ju färre statiska beroenden desto bättre!)
- Beroenden från förändringsbenägna delar till stabila.
- ABSOLUT INTE PÅ NÅGRA VILLKOR CIRKULÄRA BEROENDEN.

Lite generellt om design av klasser:
- Varje klass ansvarar för manipulering av sina egna attribut. Mao, har du en integer antal i klassen Räknare så skall du inte göra Räknare.antal++ från någon annan klass utan implementera metoden Räknare.adderaEtt().
- Gör inte för stora klasser.
- Gör inte klasser som "gör allt". Låt varje klass bara ansvara för en liten del av logiken.
- Undvik överdesing.
- Lär dig design patterns och använd och anpassa dessa.

Det två böckerna du har köpt är otroligt bra.

/Lime

Mycket intressant läsning, dags att plöja sidor =)

ABSOLUT INTE PÅ NÅGRA VILLKOR CIRKULÄRA BEROENDEN

När två klasser har referenser till varandra?
Klass1 har referens till Klass2 och klass2 har en referens till klass1.

/Viktor

Viktor skrev:

ABSOLUT INTE PÅ NÅGRA VILLKOR CIRKULÄRA BEROENDEN

När två klasser har referenser till varandra?
Klass1 har referens till Klass2 och klass2 har en referens till klass1.

/Viktor

Ja. Klass A använder sig av Klass B som använder sig av Klass A.

Hmmm :)

Vi håller på att göra ett spel i skolan (dock i Smalltalk och inte Java) och där kan jag se flera sådanna beroenden, dessa är altså helt fel?

Ex 1: Varje rum i slottet vet vilka varelser som är i det rummet och varje varelse vet vilket rum den är i (varelsen har en referens till rummet och rummet har en referens till varelsen)
Ex 2: Varje dörr i ett rum har dels referens till de två rum som dörren sammanbinder men sedan har dessa rum en referens till dörren.

Är detta altså circulära beroenden? Någon som kan komma med en alternativ lösning?

/Viktor

Jag skulle vilja tillägga en viktig sak i diskussionen, nämligen denna:

Utgå aldrig från en EAR-modell när du skapar objektorienterade applikationer. Jag har sett många bra objektmodeller slås sönder av EAR-tänk.

Tyvärr så är man hänvisad till relationsdatabaser när det kommer till lagring om man inte är lite riskvillig och high-tech och provar på en oo-databas. Jag har dock inte träffat på någon som har tillfredställande funktionalitet/prestanda.

Vägen jag tar och predikar för är o/r mappers (objekt/relations mappers). De tillåter att man bygger en objektmodell som sedan mappas mot en relationsdatabas transparent. Detta gör att man kan arbeta objektorienterat hela vägen. :)

Phorpher skrev:

Viktor skrev:

ABSOLUT INTE PÅ NÅGRA VILLKOR CIRKULÄRA BEROENDEN

När två klasser har referenser till varandra?
Klass1 har referens till Klass2 och klass2 har en referens till klass1.

/Viktor

Ja. Klass A använder sig av Klass B som använder sig av Klass A.

Njea... Dubbelriktade anrop är en sak. Beroenden är en annan.

Antag att du har en lyssnare ThingListnerer som implementerar metoden happening(HappeningEvent e). Denna metod anropas av SomeThing som har en metod addListener(Listener l).

I detta fall så anropar ThingListener först SomeThing och SomeThing sedan ThingListener när något händer.

Beroendet är dock sådant att ThingListener känner till SomeThing men inte åt andra hållet. A beror på B och det är inte ett cirkulärt beroende.

Om däremot SomeThing skapar en ny klass AnyThing som i sin tur skapar en ny instans av ThingListener som den adderar till SomeThing, då har vi ett cikulärt beroende. A känner till B känner till C känner till A. Då kan man få debugga i all evighet.

Skillnaden kan, lite förenklat, vara sådan att man kan säga "A känner till B" så är det ett beroende och "B använder sig av A" så är det ett anrop.

Viktor sa A känner till B och Phorpher A använder sig av B... skillnaden är icke stor men dock märkbar.

Viktor skrev:

Hmmm :)

Vi håller på att göra ett spel i skolan (dock i Smalltalk och inte Java) och där kan jag se flera sådanna beroenden, dessa är altså helt fel?

Ex 1: Varje rum i slottet vet vilka varelser som är i det rummet och varje varelse vet vilket rum den är i (varelsen har en referens till rummet och rummet har en referens till varelsen)
Ex 2: Varje dörr i ett rum har dels referens till de två rum som dörren sammanbinder men sedan har dessa rum en referens till dörren.

Är detta altså circulära beroenden? Någon som kan komma med en alternativ lösning?

/Viktor

Nej, det är inte fel. Vad det handlar om är två olika saker. Det ena är design och det andra är under körning.

Som du skriver det så är rummen beroende av dörrarna men dörrarna är inte beroende av rummen. Ett rum skapar en dörr.

När en varelse kommer in i rummet så lägger den till sig själv i det rummet och då får rummet en referens till varelsen. Detta för att t.ex. en annan varelse skall kunna komma in i rummet och fråga efter vad som finns i rummet och då få den första varelsens beskrivning.

När varelsen sedan flyttar på sig så tar man bort sig själv ur rumets lista över varelser.

Jämför detta med lyssnare. En lyssnare känner till det den lyssnar på men objektet som lyssnas på använder sig av metoder i lyssnaren. Det första är beroendet, det andra användningen.

Om du däremot gjorde så att när en varelse kommer in i rummet så lägger den till sig i rummet men när den skall flytta på sig så är det rummet som flyttar på varelsen. Då blir det troligtvis ett cirkulärt beroende.

I Eclipse, det helt fantastiska verktyget, finns det plug-ins som kontrollerar just den här typen av beroenden automatiskt och varnar. Otroligt praktiskt.

I Eclipse, det helt fantastiska verktyget, finns det plug-ins som kontrollerar just den här typen av beroenden automatiskt och varnar. Otroligt praktiskt.

Vad heter dem? Är de fria?