Vinnaren i pepparkakshustävlingen!
2022-02-17, 01:10
  #1
Medlem
Tja

Jag är en hobbyprogrammerare och har lyckats skrapa ihop en hel del själv men märker med tiden och projektens storlek att jag tappar kontrollen över struktur vilket leder till att jag inte minns var saker och ting låg vad gäller kod etc... moms spagetti helt enkelt..
Nu vet jag att OOP ska vara hjälpsam i sådana situationer men trots flertal försök att anmana det tänket kan jag inte slå huvudet igenom muren och förstå vad som är vad och i vilka syften.
Hur börjar jag modellera? Och därefter få det i fungernade kod? exempel på mina utmaningar.
Någon som har en bra bok att tipsa om, alternativt en weblänk tänkt till just brogrammers i samma situation.
Tack på förhand.
Citera
2022-02-17, 08:49
  #2
Medlem
Citat:
Ursprungligen postat av ttm
Tja

Jag är en hobbyprogrammerare och har lyckats skrapa ihop en hel del själv men märker med tiden och projektens storlek att jag tappar kontrollen över struktur vilket leder till att jag inte minns var saker och ting låg vad gäller kod etc... moms spagetti helt enkelt..
Nu vet jag att OOP ska vara hjälpsam i sådana situationer men trots flertal försök att anmana det tänket kan jag inte slå huvudet igenom muren och förstå vad som är vad och i vilka syften.
Hur börjar jag modellera? Och därefter få det i fungernade kod? exempel på mina utmaningar.
Någon som har en bra bok att tipsa om, alternativt en weblänk tänkt till just brogrammers i samma situation.
Tack på förhand.

https://www.amazon.com/Head-First-Ob.../dp/0596008678
Citera
2022-02-17, 08:55
  #3
Medlem
dusugermers avatar
Citat:
Ursprungligen postat av ttm
Tja

Jag är en hobbyprogrammerare och har lyckats skrapa ihop en hel del själv men märker med tiden och projektens storlek att jag tappar kontrollen över struktur vilket leder till att jag inte minns var saker och ting låg vad gäller kod etc... moms spagetti helt enkelt..
Nu vet jag att OOP ska vara hjälpsam i sådana situationer men trots flertal försök att anmana det tänket kan jag inte slå huvudet igenom muren och förstå vad som är vad och i vilka syften.
Hur börjar jag modellera? Och därefter få det i fungernade kod? exempel på mina utmaningar.
Någon som har en bra bok att tipsa om, alternativt en weblänk tänkt till just brogrammers i samma situation.
Tack på förhand.
OOP hjälper dig inte med struktur. Om du saknar strukturellt tänkande så blir det inte bättre för att du slänger in objekt där du känner för det.
Du behöver lära dig att tänka strukturellt och bygga upp dina projekt utifrån detta.
OOP är något som många säger sig både använda och förstå, men inser många år senare att "NU fattar jag"... Termen är ganska enkel att förstå vad den går ut på och det är tillika enkelt att börja jobba OO, men det tar som sagt flera år innan man verkligen landar tänket.
Börja med att titta på din kaffebryggare och bygg upp den i ett system enligt OOP. Vad har du för beståndsdelar och hur hänger de ihop? Du kan modellera precis allt som du ser runtomkring dig, gör några försök.
Och kanske det bästa tipset: Det där med arv - skit i det helt och hållet. Använd interfaces.
Citera
2022-02-17, 12:52
  #4
Medlem
Hej håller med dusugermer. Tänkte bara ge några av mina tankar som kanske stödjer, eller inte.

Först, det finns massor skrivet om OOP som är både svårt att förstå och rätt meningslöst i verklighet. Så filtrera ordentlig när du läser saker.

Jag brukar göra så här. Jag börjar med att rita en fyrkant som bild av ett objekt. Sätt namn på objektet, det kanske kan vara användaren Kalle. Sen ritar jag några till fyrkanter och sätter namn på dem. Det kan till exempel vara Kalles lönekonto. Och kanske Storgatans bankomat. Allt beror på vad du håller på med. Du har nu designat några objekt och är en bra bit på vägen. Redan nu kanske du börjar fundera på om du har valt bra objekt -- släng papperet och börja om.

Nästa steg är att fundera igenom vad saker som är utanför objektet skulle vilja göra. Till exempel vill jag få reda på Kalles personnummer. Då ritar jag en metod som jag kallar för get_personNummer. Exakt hur man ritar sånt här är inte viktigt just nu, en pil eller bara namnet bredvid objektet är en bra början. Sen vill jag kanske be automaten att ta ut pengar. Det blir då en metod som kan kallas do_taUtPengar. Den här metoden behöver ha två parametrar (eller kanske fler), hur mycket pengar och vilket lönekonto. Så då skickar jag väl in en referens till Kalles lönekontol, do_taUtSedlar(500 kr, KallesLönekonto). Men skall du ta ut pengar från ett lönekonto så måste det finns en metod för det som lönekonto har. Aha, do_taUtPengar (500 kr). Den metoden kan ju gå fel, det kanske inte finns pengar nog på kontot - vad gör vi då.

Den stora poängen med sån här modellering är att det är "billigt" för oss lata att ändra på saker och ting tills de blir bra. När väl koden skrivits är det mycket jobbigare att ändra.

Det finns ett steg till som du gärna bör göra med objekten som sådana och det är att fundera på deras livstid: hur föds objekten i systemet, hur försvinner (kanske aldrig). När du fått ner såna tankar kan du börja fungera på om det kanske är så att du skall fundera på klasser av objekt. Det kanske inte bara finns en användare, Kalle, det kan ju finnas många som i stort ser likadana ut, men förhoppningsvis har olika personnummer. Prova då att på ett nytt papper skriva upp klassen användare och fundera igenom vad som ändras om Kalle just är en instans av den här klassen. Återigen, bättre att trixa med sånt här innan du börjar skriva kod.

När du väl vet vilka klasser du vill ha och vilka metoder som de skall erbjuda andra, utanför klassen, så är det dags att designa hur klassen ser ut inuti. Vilka variabler behöver varje objekt ha (till exempel personnummer).

Och som dusugermer redan sagt, avstå från att arbeta med arv mellan klasser så länge. Det är en bra ide, men kan bli himla förvirrande.
Citera
2022-04-11, 21:44
  #5
Medlem
Jooncs avatar
Citat:
Ursprungligen postat av ArundoDonax
Hej håller med dusugermer. Tänkte bara ge några av mina tankar som kanske stödjer, eller inte.

Först, det finns massor skrivet om OOP som är både svårt att förstå och rätt meningslöst i verklighet. Så filtrera ordentlig när du läser saker.

Jag brukar göra så här. Jag börjar med att rita en fyrkant som bild av ett objekt. Sätt namn på objektet, det kanske kan vara användaren Kalle. Sen ritar jag några till fyrkanter och sätter namn på dem. Det kan till exempel vara Kalles lönekonto. Och kanske Storgatans bankomat. Allt beror på vad du håller på med. Du har nu designat några objekt och är en bra bit på vägen. Redan nu kanske du börjar fundera på om du har valt bra objekt -- släng papperet och börja om.

Nästa steg är att fundera igenom vad saker som är utanför objektet skulle vilja göra. Till exempel vill jag få reda på Kalles personnummer. Då ritar jag en metod som jag kallar för get_personNummer. Exakt hur man ritar sånt här är inte viktigt just nu, en pil eller bara namnet bredvid objektet är en bra början. Sen vill jag kanske be automaten att ta ut pengar. Det blir då en metod som kan kallas do_taUtPengar. Den här metoden behöver ha två parametrar (eller kanske fler), hur mycket pengar och vilket lönekonto. Så då skickar jag väl in en referens till Kalles lönekontol, do_taUtSedlar(500 kr, KallesLönekonto). Men skall du ta ut pengar från ett lönekonto så måste det finns en metod för det som lönekonto har. Aha, do_taUtPengar (500 kr). Den metoden kan ju gå fel, det kanske inte finns pengar nog på kontot - vad gör vi då.

Den stora poängen med sån här modellering är att det är "billigt" för oss lata att ändra på saker och ting tills de blir bra. När väl koden skrivits är det mycket jobbigare att ändra.

Det finns ett steg till som du gärna bör göra med objekten som sådana och det är att fundera på deras livstid: hur föds objekten i systemet, hur försvinner (kanske aldrig). När du fått ner såna tankar kan du börja fungera på om det kanske är så att du skall fundera på klasser av objekt. Det kanske inte bara finns en användare, Kalle, det kan ju finnas många som i stort ser likadana ut, men förhoppningsvis har olika personnummer. Prova då att på ett nytt papper skriva upp klassen användare och fundera igenom vad som ändras om Kalle just är en instans av den här klassen. Återigen, bättre att trixa med sånt här innan du börjar skriva kod.

När du väl vet vilka klasser du vill ha och vilka metoder som de skall erbjuda andra, utanför klassen, så är det dags att designa hur klassen ser ut inuti. Vilka variabler behöver varje objekt ha (till exempel personnummer).

Och som dusugermer redan sagt, avstå från att arbeta med arv mellan klasser så länge. Det är en bra ide, men kan bli himla förvirrande.

Har du verkligen för vana att blanda både svenska och engelska OCH camelcase och snakecase i samma metodnamn?
Citera

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback