gode programmerings teknikker

[dalai]

er det noen som har en anbefaling av en god bok hvor man lærer god, strukturert og modularisert objektorientert programmering? (helst delphi)

 

har lyst til å begynne å kode litt mer som de proffe gutta :o

[Format71]

er det noen som har en anbefaling av en god bok hvor man lærer god, strukturert og modularisert objektorientert programmering? (helst delphi)

 

har lyst til å begynne å kode litt mer som de proffe gutta :o

 

Tomes of Delphi: Algorithms and Datastructures (http://www.wordware.com/Merchant2/merchant...Code=1556227361)

 

Den syns jeg er meget god. Den er jo ikke først og fremst en 'tenk objektorientert'-bok, men den gir deg en grundig innføring i mye annet nyttig på en OO måte.

 

-Vegar

[dalai]

den så grei ut den, men jeg er først og fremst ute etter en slik 'tenk objekt-orientert' bok. har du noen andre tips?

[dalai]

det hadde jo vært kjempeflott hvis den hadde vært litt rettet mot .NET frameworken også

[Legion]

en Alg/Dat bok bør du kjøpe uansett. den vil hjelpe deg å tenke riktig og bli bedre på problemløsning.

 

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition) er en UML, OOA og OOD bok. det er ikke noe programmeringsbok, men mer en bok om forståelse av analyse/design av systemer vha UML og ikke minst Patterns som er i bruk.

 

for litt avansert forståelse kan det også være av interesse å se på SICP. Riktig nok en Lisp og funksjonell programmeringsbok, men av mange sett på som en Bibel når det gjelder forståelse av programmering. at det er Lisp bør ikke avskrekke noen, man lærer syntax på et par timer.

 

ingen av disse bøkene er Delphi-bøker, de er derimot geniale bøker på sitt område, så det er anbefallt å se på dem om det er dette som var av interesse

[Format71]

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition)

 

Har jeg forstått det rett dersom jeg tror du er en hobby programmerer som fortsatt er litt i startfasen? Eller er du i fast jobb og har en del fra strukturert programmering? Patterns er vel og bra, men UML kan jeg love deg at du ikke vil ha noe med å gjøre hvis du er der jeg tror. Man kan vel nesten si det sånn at UML gjør for programmereren det kommunen gjør for folk som skal bygge seg garasje. Papir, byråkrati, formaliteter, totalt bortkastet tid...

 

Dette er selvfølgelig ikke tilfelle dersom du skal i gang med et kjempe prosjekt og jobbe sammen med 20 andre og har oppdragsgivere som krever at du produserer bunker med dokumentasjon på hva som gjøres osv.osv.

 

Patterns derimot er en flott ting. Enkelt sagt er patterns ting som går igjen. F.eks. vil du mange ganger komme borti at mange objekter trenger å få vite om endringer som skjer i ett annet objekt. Siden det er mange som har trengt dette før deg finnes det ferdig lagde oppskrifter på hvordan det kan/bør gjøres. Det var på vei en patternsbok for Delphi, men den ble trukket tilbake av en eller annen grunn. Tror det var en ny forfatter som satte igang igjen, men har ikke sett noe siden.

 

En hver OO-programmeringsbok tror jeg vil gi deg litt nytte, men så fort det begynner å blande inn analyse og design tror jeg du kommer til å legge fra deg boka på et så tidlig stadie at du ikke vil få så mye igjen for det....

 

Det er nå hva jeg tror - I alle fall stemmer det bra på meg...

 

-Vegar

[dalai]

jeg tror du er inne på noe helt vesentlig der vegar.

jeg har nettopp fått meg jobb som programutvikler (etter hvert mer rettet mot web-programmer) og har erfaring fra programmering i gamle Turbo Pascal og Visual Basic og litt Java. Alt dette er da fra hobby basis og noe på høyskolen. På skolen fikk vi også noe som het UML i vrangstrupen, akkurat slik som du sa. (mye mye bortkastet tid dersom det er et lite prosjekt)

I min jobbsituasjon vil jeg lage programmer sammen med 0-2 andre (mest sannsynlig 1), så det er ikke noe sånn stort behov for kjempemye dokumentasjon og samkjøring.

 

Jeg kunne som sagt godt tenkt meg å tenke litt mer objektorientert programmering, (Ikke som i Visual Basic 6 liksom..) og hvis du har rett i dette med Patterns så må du si ifra dersom du kommer over noe stoff/bøker om dette for du la frem en problemstilling jeg kjente meg igjen godt i.

[Legion]

at UML diagrammer av diverse typer er en papirmølle er det ingen tvil om. en person som arbeider alene vil heller aldri(?) ha bruk for det. det er ikke før man er i større team(4-5 +) med noe større prosjekter at det kan være nyttig.

 

å ha lært OOA og OOD er ikke bortkastet, aldri. derimot vil en dreven proggis vite når og om det er nødvendig og til hvilken grad. det er veldig tørt, uten tvil. jeg mener alikvell at noe systemeringskunnskaper er nyttig å ta med seg, ikke nødvendigvis direkte på programmeringssiden, men på forståelsessiden.

[Format71]

å ha lært OOA og OOD er ikke bortkastet, aldri. derimot vil en dreven proggis vite når og om det er nødvendig og til hvilken grad. det er veldig tørt, uten tvil. jeg mener alikvell at noe systemeringskunnskaper er nyttig å ta med seg, ikke nødvendigvis direkte på programmeringssiden, men på forståelsessiden.

 

Det er svært lite som kan betegnes som bortkastet lærdom (navnet på alle figurene i pokemon?) og selvfølgelig er det kjekt å kunne. Men har du som meg kun 24 timer i døgnet osv...

 

Her hos oss bruker vi Extreme Programming og har veldig gode erfaringer med det. Vet at XP ikke utelukker sa & d, men den har tatt hensyn til at det er svært svært få prosjekter som ender opp der man først hadde tenkt seg. Så hvorfor benytte store deler av ressursene på sa og d når det i de aller aller fleste tilfeller viser seg at meste parten av arbeidet man da gjorde ikke ble med over målstreken?

 

-Vegar

[Format71]

Jeg kunne som sagt godt tenkt meg å tenke litt mer objektorientert programmering, (Ikke som i Visual Basic 6 liksom..) og hvis du har rett i dette med Patterns så må du si ifra dersom du kommer over noe stoff/bøker om dette for du la frem en problemstilling jeg kjente meg igjen godt i.

 

Det beste er å bare begynne. Bryt alt ned i småbiter og se på hvilke tjenester du har behov for og hvordan du enklest kan kapsle inn disse tjenestene i små utbyttbare enheter. F.eks. kan det være at du lager en mp3-spiller (for hvem gjør ikke det her på forument... ;-) ) Lag deg et objekt som representerer en sang og ett objekt som representerer en liste med sang-objekter. Vips har du en playliste. lar du sang-objektet og sangliste-objektet ha en felles basisklasse kan du til og med støtte at en sangliste inneholder ander sanglister osv.

 

Bruk fantasien, fornuften og tiden så vil du merke at det kommer etter hvert. Du lærer ikke så himla mye av bøker uansett. Ikke slike ting. Det må komme med erfaring. Tror jeg... I alle fall er det min erfaring. Har noen OOP bøker liggende, men de gir deg bare forståelse for begrepene (arv, polymorfi, inkapsling osv) Det var først etter noen år som programmerer at jeg begynte å se nytten og bruken av det, og hele tiden er det slik at du utvikler deg. Leser jeg halvt års gammel kode tenker jeg ofte 'dæsken det var dårlig kode. Jeg burde jo ha skilt det og det ut i et eget objekt, så kunne jeg ha ....'.

 

Og da kommer men inn på et annet utrolig viktig tema - forøvrig en viktig del av XP (Extreme Programming) - nemmelig refactoring. Og da kommer man inn på behovet for å ha gode unit-tester, og da kommer man inn på osv osv ;-)

 

-Vegar

[Legion]

Det er svært lite som kan betegnes som bortkastet lærdom (navnet på alle figurene i pokemon?) og selvfølgelig er det kjekt å kunne. Men har du som meg kun 24 timer i døgnet osv...

 

Her hos oss bruker vi Extreme Programming og har veldig gode erfaringer med det. Vet at XP ikke utelukker sa & d, men den har tatt hensyn til at det er svært svært få prosjekter som ender opp der man først hadde tenkt seg. Så hvorfor benytte store deler av ressursene på sa og d når det i de aller aller fleste tilfeller viser seg at meste parten av arbeidet man da gjorde ikke ble med over målstreken?

 

I hear you.

Pokemon er nok etter min tid, men jeg var rimelig stødig på Transformers figurene.

skal en være ærlig så er det stort sett et godt klassediagram en trenger av de forskjellige typene som finnes, de "andre" går som regel under betegnelsen de jæ##a diagrammene.

at ting ikke slutter som de startet er ikke noen bombe, brukere har en tendens til å endre oppfattning av hva de vil ha/vet ikke hva de vil ha.

 

poenget jeg noe klossete ville fram til er at forståelse er viktigere enn programmeringsspråk og syntax, ikke at en skulle systemere seg til døde eller drukne i overarbeid

[Format71]

I hear you.

Pokemon er nok etter min tid, men jeg var rimelig stødig på Transformers figurene.

skal en være ærlig så er det stort sett et godt klassediagram en trenger av de forskjellige typene som finnes, de "andre" går som regel under betegnelsen de jæ##a diagrammene.

 

Jeg tilhører vel også egentlig Transformers-epoken, men har aldri brydd meg. I stede har jeg ikke helt vokst fra Lego, og har nå begynt å samle på nytt etter at småbrødre har overtatt rubbel og bit...

 

Må nok inrømme at jeg et par ganger har lett etter egnet klassediagram-tegne-verktøy ala visio e.l. for å få litt oversikt over masse flygende tanker/eksisterende kratt-kode. Så et stilig program, tror muligens det var en del av nye AQTest, som analyserte og tegnet for deg. Slikt har jeg sansen for ;-)

 

God helg,

-Vegar

[Legion]

aah, Lego

jeg har lenge vurdert å kjøpe Lego Mindstorms, plukke opp en bok og lage/programmere roboter...vi får se

 

når det gjelder diagramverktøy så har jeg snubblet over Poseidon http://www.gentleware.com

[Format71]

aah, Lego

jeg har lenge vurdert å kjøpe Lego Mindstorms, plukke opp en bok og lage/programmere roboter...vi får se

 

når det gjelder diagramverktøy så har jeg snubblet over Poseidonhttp://www.gentleware.com

 

Fikk Mindstorms til jul av kona i fjor. Kjempe stilig! Men dessverre blir det veldig skjeldent til at jeg får brukt det. Har kjøpt noen små technics set og noe tog og greier. Det er sånn at guttungen på 2 også begynner å syns er boro.

 

Skal ta en nærmere titt på Poseidon. Ved første øyekast ser det ikke så veldig dumt ut. Mange takk.

 

-Vegar