Sourcecode: Introduksjon til Objekt Orientert Programmering

[abcd423417984]

Introduksjon til Objekt Orientert Programmering

Objekt Orientert Programmering eller OOP er blitt et vanlig uttrykk i mesteparten av dagens programmeringsspråk, men hva er egentlig dette?

 

Les artikkelen her

[pertm]

Jeg synnes dere kanskje burde tatt med en del fordeler med OOP, slik som innkapsling av informasjon, slik at ikke andre deler av koden kan forandre ting det ikke har noe med å forandre.

 

Når dere snakker om arv, så snakker dere om public og protected uten å forklare hva dere mener med disse ordene. Jeg vet det men en som trenger en introduksjon til OOP vil nok ikke kunne det.

[abcd423417984]

hmmm...trodde jeg hadde tatt med dette. kanskje jeg har formulert det dårlig ellernoe slik?

 

EDIT: er jo et helt avsnitt om sistnevnte. Er det utydlig hva jeg mener?

 

Ellers nevner jeg såvidt det du snakker om innkapsling av informasjon i følgende:

 

"Det er blant annet veldig vanlig å bruke OOP da man driver med datamodellering, men også som en måte å samle relevant kode som hører sammen for å få en ryddigere og mer effektiv kode."

 

Skal lese over da jeg får tid og se om det er noe jeg kan føye til. Noen forslag?

[pertm]

Beklager jeg må ha lest det avsnittet der det står om public & protected litt for raskt.

 

Det siste synnes jeg er noe uklart om er med.

 

En annen ting som ikke er nevnt som kunne vært tatt med er noen negative sider ved OOP. Det jeg tenker mest på er at det er få eller ingen vitenskaplige undersøkelser som visser at OOP er mer effektiv/bedre enn non OOP. Det er nok noen mindre forsøk som har gitt dette resultat, men ingen større resultater.

[daysleper]

..første negative jeg kommer på er at virtuelle metoder (polymorfi (eller åssen det skrives)) kan være tregere enn vanlige funksjonskall. Men så er det som regel en grunn til at man velger å bruke en slik løsning- og man hadde sikkert valgt en løsning som ville gitt samme tap i hastighet for å få samme effekten hvis man ikke brukte OOP for å få til det man er ute etter.

 

..så var kanskje ikke så negativt alikevell..

[pertm]

En annen ting som kan nevnes er at arv fra flere klasser kan være vanskelig å gjennomføre selv i de språk som støtter det.

 

Noe som jeg er usikker på om har noe med OOP som er smart å bruke er templates.

 

Det kunne vært tatt med og forkalart overloading og overriding av funksjoner. Jeg er ikke sikker på om dette siste ville vært noe for en introduksjon, men en vil ganske fort komme til det.

[MailMan13]

Tror desverre ikke den artikkelen er egnet til å forklare noen som ikke vet hva det går i noe som helst, det blir den for overfladisk og 'lettvindt' til... Det er nye og anderledes konsepter som trenger grundigere forklaring og eksempler.

 

Ellers er jeg veldig enig med petterm, begreper som innkapsling, abstraksjon og polymorfi er selve kjernen i hva man prøver å oppnå med objektorienterte metoder, og det kommer ikke frem i det heletatt.

 

det ligner litt for mye på en gjennomsnittlig besvarelse på "Hva mener vi med oop" fra en eksamen i "innføring i programmering" et eller annet sted...

[daysleper]

-- klippet vekk denne fryktelig lange posten siden det som ble skrevet ligger (mer eller mindre) i artikkelen under utvikling nå --

Endret 4. desember 2003 av daysleper

[abcd423417984]

det der går mer over på oop i spesifikke språk. Poenget mitt var å kun ta teorien.

[daysleper]

Ja - jeg har hoppet litt frem og tilbake; kanskje mest for min egen del.

 

Hvis vi tenker oss at posten er splittet i flere deler, så stemmer første del mer med det å være en introduksjon.

 

Kodeeksempler er noe man kanskje begynner med i en senere del av guiden, men jeg hoppet liksom rett på med et eksempel nå -- sånn at vi hadde et konkret eksempel å fortelle om og kanskje jobbe mot i en senere artikkel.

 

Ta idéer og/eller tekst -- rett på det du vil og bruk det hvis du liker det. Hvis ikke kan du ignorere det jeg har skrevet. Det var/er ment som et påbegynnt forsøk.

Endret 12. november 2003 av daysleper

[pertm]

det der går mer over på oop i spesifikke språk. Poenget mitt var å kun ta teorien.

Dere kunne jo istedenfor gå over pseudokode der det er skrevet kode. Det nok vært enklere å forstå

 

Desuten er synnes jeg koden daysleeper skrev ikke er det beste eksemplet på OOP. Det burde vært et objekt postkontor som main bare oppretteter og bruker etter som en skal gjøre forskjellige ting.

[pertm]

Jeg har tenkt litt på dette og tror at en kan gjøre det enklere å forstå ved å gjøre noe liknende slik h filer i C++ ser ut. Jeg tror alle cout og kode generelt som daysleper har gjør det vanskeligere å forstå. Jeg tror det er enklere å forstå med mindre kode slik jeg har satt det opp på samme eksempel som daysleper hadde. Jeg håper dette hjelper noe.

 

class Adresse
{
protected:
 string gate;
 string poststed;
 int postnr
 string land;

public:
 Adresse(string gate, string poststed,int postnr,string land=0);
 string getAdresse();
 string getPoststed();
 int getPostnr();
 string getLand();

}

Her har jeg hva som trengs for en enkel adresse. Land er noe som ikke nødvendig hvis det ikke er tatt med så er det i Norge og ikke noe betydning.

 

I Java ville en denne delen av koden sett anderledes ut enn den gjør i C++:

Adresse(string gate, string poststed,int postnr,string land=0);

Slik kan det se ut i Java også i C++ også hvis en vil:

Adresse(string gate, string poststed,int postnr);
Adresse(string gate, string poststed,int postnr,string land);

Her vil gjerne den første metoden kalle den andre, men behøver ikke. Dette er typisk:

Adresse(string gate, string poststed,int postnr)
{
 Adresse(string gate, string poststed,int postnr,0);
}

Skrevet på en av disse måtene kan man velge om man vil skrive med hvilket land det er til når en gjør metodekallet. Så lenge man sender innenfor Norge blir denne ikke tatt med.

 

 

class Adressat
{
protected:
 Adresse adresse;
public:
 Adressat(Adresse adresse);
 virtual string get_navn()=0;
}

Dette er en klasse som har en virtuel funksjon. Det kan ikke bli et objekt av denne klassen. I Java ville det være litt anderledes og ikke vært "=0"

 

Her hadde det nok vært mulig å ha en annen oppsett på det. Istedenfor at Adressat inneholder Adresse kunne det omvendte også være tilfelle at Adresse inneholder Adressat. Grunnen til det er at flere personer kan ha samme adresse, mens en person har (normalt) ikke flere adresser.

 

class Person : public Adressat
{
protected:
 string fornavn, etternavn;
public:
 Person(Adresse adresse, string fornavn, string etternavn);
 string get_navn();
}

 

class Firma: public Adressat
{
protected:
 string navn;
public
 Person(Adresse adresse, string navn);
 string get_navn();
}

Disse to klassene arver begge Adressat klassen. Det kan finnes et objekt av typen Firma eller Person, men aldri av typen Adressat

 

class Pakke 
{
protected:
 int kolli_nr;
 Adressat fra, til;
 bool hentet;
 dato hentet, levert;
public:
 Pakke(int kolli_nr, Adressat fra, Adressat til, dato levert);
 bool kontroller_nr(int nr);
 void Hentet(dato hentet);
 
}

Her er en klasse som bruker objekter av typen Adressat. Et objekt av denne klassen, vil ikke vite om det er en Person eller Firma som sender/mottar en pakke, men det trenger det heller ikke vite.

 

 

Etter hvert kan en nok ta med mer pseudokode. Kan nok være en fordel å starte med lite. Skal en holde det generelt så bør en ha lite virkelig kode eller kode som spesifikt for et språk.

 

Edit: så jeg hadde skrevet noen ekstra klasser som jeg egentlig ikke trengte for forklare det jeg ville i notepad.

class Lager
{
protected:
 Pakker[] pakker;//en liste med pakker
public:
 Lager();
 void ny_pakke(Pakke pakke);
 Pakke getPakke(int Koli_nr);

}

class Postkontor
{
protected:
 string navnpostkontor;
 Lager lager;
public:
 postkontor(string navn);
 metoder mot lager...


}

Endret 13. november 2003 av pertm

[daysleper]

Sånn fort å gæli, burde nesten lest innlegget ditt 2 ganger til (tar det litt siden ), men:

 

Jeg har tenkt litt på dette og tror at en kan gjøre det enklere å forstå ved å gjøre noe liknende slik h filer i C++ ser ut.  Jeg tror alle cout og kode generelt som daysleper har gjør det vanskeligere å forstå. Jeg tror det er enklere å forstå med mindre kode slik jeg har satt det opp på samme eksempel som daysleper hadde. Jeg håper dette hjelper noe.

 

class Adresse
{
protected:
 string gate;
 string poststed;
 int postnr
 string land;

public:
 Adresse(string gate, string poststed,int postnr,string land=0);
 string getAdresse();
 string getPoststed();
 int getPostnr();
 string getLand();

}

Her har jeg hva som trengs for en enkel adresse.

 

Det er helt sikkert lurere å splitte ting opp og ta for seg header-filene først ja.

 

Grunnen til at jeg tok "alt i ett" nå sånn med en gang var for å ha et konkret eksempel å jobbe mot. Jeg tenkte det ville bli lettere for oss på denne måten -- å se at vi kom til å ende opp med noe som virket til slutt og forklare hvordan vi tenkte for å komme frem til dette.

 

Så i en introduksjon (eller kanskje i en egen del som tar for seg kode-eksempel-delen av OOP) er det nok noen "rene" og enkle header-filer som bør brukes før selve implementerings-koden fylles inn (i .cpp-filer), ja.

 

 

-- klippe litt --

 

Her hadde det nok vært mulig å ha en annen oppsett på det. Istedenfor at Adressat inneholder Adresse kunne det omvendte også være tilfelle at Adresse inneholder Adressat. Grunnen til det er at flere personer kan ha samme adresse, mens en person har (normalt) ikke flere adresser.

 

-- klippe litt --

 

Det du snakker om rundt her er vel og bra -- vi får med oss virtuelle og abstrakte metoder og klasser, men kanskje det hadde vært lurere å kun konsentrere seg om lageret og enkle objekter/klasser i første om gang og heller "utvide" eksempelet slik at vi får med oss disse tingene siden.

 

 

Etter hvert kan en nok ta med mer pseudokode. Kan nok være en fordel å starte med lite. Skal en holde det generelt så bør en ha lite virkelig kode eller kode som spesifikt for et språk.

 

Edit: så jeg hadde skrevet noen ekstra klasser som jeg egentlig ikke trengte for forklare det jeg ville i notepad. 

class Lager
{
protected:
 Pakker[] pakker;//en liste med pakker
public:
 Lager();
 void ny_pakke(Pakke pakke);
 Pakke getPakke(int Koli_nr);

}

class Postkontor
{
protected:
 string navnpostkontor;
 Lager lager;
public:
 postkontor(string navn);
 metoder mot lager...


}

 

Helt enig her .. std::map ødelegger ganske mye; siden den inneholder nesten alt vi trenger fra før av. Så det finnes to muligheter:

 

- Forklare at std::map er en klasse, og at den har metoder og at det kan lages objekter av den på samme måten som man lager objekter av egne klasser.

- Lage en egen klasse som tar for seg oppgavene til std::map (det var dette du tenkte på kanskje).

 

Er ikke sikker på hva som er lurest jeg egentlig?

Sånn generellt sett skal man jo bruke det som allerede finnes i standard-biblioteket (jeg går ut i fra at Java har en tilsvarende klasse som C++'s std::map).

 

På en annen side kunne man lært mye av å implementere en egen container-klasse .. men da ville guiden blitt en del lengre.

Vi kunne selvfølgelig gjordt denne enkel - ved å "jukse"; bruke std::map eller std::vector i "private" delen til klassen.

Endret 14. november 2003 av daysleper

[daysleper]

http://sourcecode.no/art.php?artikkelid=3738&p=forum

EDIT: Denne er nå gammel, se den siste posten for siste versjon av artikkelen!

 

..bruk linkene "Neste side" og "Forrige side" på bunnen til å navigere med siden dropdownboksen tilsynelatende ikke går å navigere med før artikkelen er publisert.

Det skal fungere fint å kopiere og lime inn teksten fra artikkelen her når man ønsker å sitere fra den i sammenheng med kommentarer og rettinger.

 

Skal ta til etteretning det du og jeg har snakket om pertm - slik at det reflekteres i artikkelen; må bare få tid! Det er ingen ting i veien for at du kan skrive noen ord i "innførings-modus" slik at jeg kan lime dem inn i artikkelen hvis du har lyst.

 

.. tror kanskje vi bør implemente en egen container-klasse og "jukse" som jeg nevnte helt på slutten.

Kanskje vi til slutt eller siden kan nevne at man i stedet fint kunne brukt std::map.

 

Høres dette ut som en fornuftig ikke-helt-på-trynet idé?

Håper fortsatt på hjelp og/eller masse kjeft hvis jeg skriver/gjør noe galt. "I'm with that!"

Endret 4. desember 2003 av daysleper

[pertm]

Det ser ut som en bra begynnelse.

 

Man bruker blandt annet OOP når man jobber med datamodellering med det mål å få en ryddigere og mer effektiv kode. Man prøver altså stadig å unngå det evige "spaghetti" problemet som lett oppstår i koden hos språk som ikke bruker denne metologien. Riktig ord her?

Jeg synes det er riktig ord, selv om jeg ville sagt at man kan få spagetti kode med non OOP. En kan også si at en har masse goto settninger som gjør koden uocersiktlig, men det blir vel igjen ganske mye for spesifike programmeringsspråk.

 

 

Har ikke tid til å kommentere mer nå.

[daysleper]

Tok å endret litt på kildekoden -- kanskje et lite hakk bedre nå:

 

http://scm.nostdal.net/cgi-bin/viewcvs.cgi...ts/oopintro.cpp (klikk på den øverste (markup)-linken for å se siste versjon)

 

Har desverre ikke fått tid til å skrive mer på selve teksten i guiden. Har sliti med Internett som har vært nede og har i stedet, i mellomtiden, tatt for meg andre guider som var lettere å skrive om.

 

+at jeg lever bittelitt "offline" også, uansett om Internett er nede eller ikke.

[pertm]

Tok å endret litt på kildekoden -- kanskje et lite hakk bedre nå:

 

http://scm.nostdal.net/cgi-bin/viewcvs.cgi...ts/oopintro.cpp (klikk på den øverste (markup)-linken for å se siste versjon)

Koden ser bra ut, men det er nok litt for konkret(og for mye C++) for en generell innføring i OOP.

 

Så foresten at du er litt inkonsikvent i hvordan du starter parantesene.

class Person {
public:
string fornavn() { return(_fornavn); }
void fornavn(string fornavn_) { _fornavn = fornavn_; }
string etternavn() { return(_etternavn); }
void etternavn(string etternavn_) { _etternavn = etternavn_; }
private:
string _fornavn;
string _etternavn;
}; // class Person

Her starter du med parantes etter klassen men i metoder venter du til neste linje slik som på den under.

Pakke(int kollinr_ = 0)
:_kollinr(kollinr_)
{
}

PS. Jeg vet at ved å bare kopiere koden slik forsvant noe av formateringen din, men ikke det jeg ville visse.

[daysleper]

...det er nok litt for konkret(og for mye C++) for en generell innføring i OOP.

 

Ja, den er nok det. Det kan hende jeg fjerner den til en senere del i guiden.

Tanken er å ha flere mer generelle eksempler før denne, men å bruke denne som et mål kanskje.

Kom gjerne med noen eksempler, gjerne i Java og/eller C++.

 

 

Så foresten at du er litt inkonsikvent i hvordan du starter parantesene.

 

Nja, det er et system i det. Jeg gjør det for å skille mellom klasser og metoder/funksjoner og har alltid gjordt det slik:

 

class A {
public:
  A(int tall_)
      :tall(tall_)
  {
      // konstruktører med initialisering av variabler setter jeg som regel opp slik uansett
  }
  
  void b();
  {
      // for større "inline" funksjoner
  }

  void c();

  void d() { // for mindre "inline" funksjoner }

private:
  int tall;
}; // class A  <-- for å lett se at klassen A "slutter" her


void A::c()
{
}


class B {
}; // class B


class C {
}; // class C


funksjon()
{
}


main()
{
}

 

Dette er måten jeg (og andre i flere bøker her) alltid har formatert koden på; så jeg kommer til å fortsette slik, tror jeg.

 

Takk for at du ser over koden -- det er ikke så mye tilbakemelding å få her alltid; så man famler rundt i mørket med tanke på om ting er bra/dårlig -- riktig/galt.

[daysleper]

Nå har jeg skrevet den om (igjen); jeg føler virkelig at jeg sliter med å forklare det her godt nok.

 

Det er linkene (view/download) på toppen i begge tilfeller som er de aktuelle linkene for å laste ned:

PDF-versjon

Postscript-versjon

 

Her er det den øverste linken (markup) som gjelder.

Kildekoden: http://scm.nostdal.net/cgi-bin/viewcvs.cgi...ts/oopintro.cpp

 

Det å bruke publiserings-systemet her på sourcecode.no ble veldig tungvinnt for meg nå under kladding, så jeg håper det går bra at jeg fra nå av poster i disse formatene.

 

Ting er rotete og i litt "hulte-ti-bulter" rekkefølge akkurat nå; spesiellt litt ut i dokumentet. Jeg prøver å finne en god start, og driver derfor å omrokkerer litt.

 

Oppdatering følger snart ..

[pertm]

Jeg har sett litt på det men har ikke så mye tid til å se på det før etter jeg er ferdig med eksamen.

 

En ting jeg tror kan være lurt for å forklare OOP er å starte med å ikke nevne kode i det hele tatt, men starte med objekter. Burde da kanskje ha flere eksempler som dette.

 

Objekter lenger nede i herakiet vil ha visse egenskaper til felles mens objekter som er høyere oppe vil være mer generelle og kan omfatte større forskjell i hva de egentlig er

• Kjøretøy
  • Båt
    • Seilbåt
      
    • Motorbåt
      
    • Skip
      

    [*]Fly

    [*]Tog

    [*]Bil

    • Personbil, 4hjul motor...
      • Diverse merker...
        

      [*]Lastebil

      [*]Buss

      [*]Motorsykkel