Hva betyr egentlig Objekt orientert progammering?

[Equerm]

Som topic sier lurer jeg på om noen kunne fortalt meg hva det egentlig betyr når et programmeringsspråk er objekt orientert?

[☀ ❄]

http://en.wikipedia.org/wiki/Object-oriented_programming

 

Objektorientert programmering betyr kort sagt at du har objekter av en spesiell klasse med egenskaper og evner, som utfører handlinger (på hverandre).

 

Fido ville vært et objekt av klassen Dog.

 

Edit: Innlegg 555

Endret 19. februar 2005 av Myubi

[Terrasque]

Det betyr ganske enkelt at du kan lage "objekter".

 

For eksempel hvis du lager et program som jobber med personer. Alle personene har en viss mengde felles data (fødselsdato, navn, mann/kvinne, yrke, osv osv) og felles funksjoner (for eksempel kalkulere alder utifra fødselsdato og dagens dato). Du kan da lage et person-objekt, som på en måte fungerer som et template.

 

Eksempel:

 

class person:
 __init__(self, fornavn, etternavn, fødselsdato):
    self.fornavn = fornavn.capitalize()
    self.etternavn = etternavn.capitalize()
    self.fødselsdato = fødselsdato

 def alder(self):
   return self.fødselsdato - dagsDato

 def fullnavn(self):
   return "%s %s" % (self.fornavn, self.etternavn)

 def formeltnavn(self):
   return "%s, %s" % (self.etternavn, self.fornavn)

person1 = person("kari", "havdAl", "220481")
print person1.formeltnavn()
print person1.alder()

 

Det vil skrive ut:

 

Havdal, Kari

23

 

Den klassen kan brukes om igjen til flere personer ( person2 = person("kåre", "nissen","121172") ), og kan og brukes som basis til å lage en ny klasse.

 

class deadman(person):
 def alder(self):
   return "DECEASED"

 

Håper du forstod dette

 

EDIT: Oj, forsent..

Endret 19. februar 2005 av Terrasque

[A_N_K]

Objektorientering er en måte å strukturere programmer på. Det er et steg opp fra prosedyrell programmering, dvs. at abstraksjonsnivået heves fra å samle bruddstykker med kode i prosedyrer til entiteter (objekter) med data og metoder (rutiner som opererer på denne typen objekt). OO fokuserer på å sentralisere programfunksjonalitet i objekter som utstyres med metoder som andre objekter interagerer med, dvs. at omverdenen forventes å betrakte et objekt som en "svart boks" med assosiert oppførsel og ikke kun en samling med primitive data (tenk C-struct).

 

Sentrale konsepter i OO er arv og polymorfi, dvs. at man kan utvide eksisterende objekttyper (klasser) med ny funksjonalitet eller simpelthen reimplementere deler av interfacet til klassen man arver fra. Hvis man f.eks har en eksisterende kodebase som forventer objekter av en viss type kan man i ettertid endre objekter som interfacer med denne koden, dvs. at bak det kjente interfacet kan man endre oppførselen. Som et eksempel kan man nevne grafikktoolkits som Qt. Qt-biblioteket forventer at vindusobjekter er av typen QWidget, så lenge man arver fra denne klassen kan man implementere sine egne vinduer som ser ut slik man vil, objektene har uansett det grensesnittet Qt-biblioteket forventer og kan interagere med.

 

Håper at dette gjorde ting klarere (ikke mer diffust i alle fall?) :]

[A!1]

A_N_K : Elsker du å spre forvirring?

 

Synes Myubi forklarte ganske greit, men dessverre så er det ikke helt riktig.

Objektorientert programmering betyr kort sagt at du har objekter av en spesiell klasse med egenskaper og evner, som utfører handlinger (på hverandre).

 

Fido ville vært et objekt av klassen Dog.

 

Men dessverre er objektorientering et veldig omfattende tema som er vanskelig å forklare på en veldig enkel måte.

 

Dele opp ordene:

Programmering - skrive kode

Objekt - En ting eller noe man kan ta på

Orientering - bygge noe i en bestemt retning eller finne ut hvor en befinner seg i terrenget.

 

Altså:

Skrive programkode om objekter og finne ut hvor en befinner seg i "skogen" av objekter.

 

Litt mer konsist betyr det at man definerer egenskapene til eventuelle objekter i

Klasser:

Definerer/beskriver egenskapene til objekter og hvordan objektet utfører operasjoner/metoder på seg selv.

 

Objekt:

En instans av en klasse. Dvs at man har opprettet et objekt i minnet på datamaskinen. Dette refereres til av en referanse, som gjerne kalles en variabel.

 

Variabel:

En referanse til en minneadresse, der maskinen finner et objekt. Variablene gir man et navn som er beskrivende og lettfattende for mennesker.

 

Altså til Myubis eksempel:

Vi har en variabel ved navn Figo.

Figo inneholder en referanse til et objekt av typen/klassen Hund.

Hunder inneholder variabler/egenskaper som størrelse, vekt, lengdePåHår og rase og operasjoner/metoder som Logre(), Sikle(), SpiseTøffel(), Sove(), Løpe().

 

Myubi snakker også om Handliner, regner med at han da mener Events som for øvrig ikke har noe med objektorientering å gjøre.

 

Tror jeg har fått beskrevet emnet på en enkel måte her, som sagt så er det flere ting som objektorientering medfører, men de handler ikke om HVA DET ER...

Endret 19. februar 2005 av Mental

[A_N_K]

Mental: Hva behager? :_P Skjønner ikke helt hva du mente med å spre forvirring. Jeg mener jeg forklarte hva som ligger i begrepet objektorientering på en bra måte (prøvde å sette ting i kontekst). Måten du beskriver objekter på kan relateres til standard C-structer, dvs. at en instans av en struct kan ses på et objekt (med det unntak at metoder deklareres utenfor klassedefinisjonen). Men det å orientere programstrukturen rundt objekter er noe annet enn simpelthen å operere på definerte (beskrevet i en struct/klasse-deklarasjon) adresseområder i RAM (å si at et objekt opererer på seg selv synes jeg er en forvirrende beskrivelse), du overser f.eks glatt arv/polymorfi som er meget sentrale konsepter i OO.

 

Edit: Jeg får presisere at et objektorientert programmeringsspråk vil si at det har direkte støtte for OO-programmering. Man kan f.eks emulere OO i C (vha. morsomme makroer osv.), men det er altså ikke støtte for det i språket.

Endret 19. februar 2005 av A_N_K

[☀ ❄]

Synes A_N_K hadde en god forklaring, jeg.

 

Jeg kan være enig i at forklaringen min ikke var spesielt presis eller utfyllende, men det var heller ikke målet. Å si at noe av den ikke er riktig er derimot galt. Med mindre du kan peke på noe konkret du mener er galt?

 

Med handlinger mener jeg metoder / medlemsfunksjoner. (Det norske ordet for "events", som du tolket det som, er forresten "hendelser", ikke "handlinger".)

 

Objekt - En ting eller noe man kan ta på

Jeg lurer svært på hvordan du tar på f.eks. en std::exception.

 

Det er andre ukorrektheter i teksten din, men jeg gidder ikke å spikke fliser i kveld.

[A!1]

Jeg lurer svært på hvordan du tar på f.eks. en std::exception.

Men du skjønnte vel poenget og relateringen/sammenligningen med virkeligheten? Og for å svare på spørsmålet ditt, du "tar på" en std::excecption ved å finne ut informasjon om den.

 

I den første posten din, så sier du enten at du har objekter som utfører handlinger på hverandre eller klasser som utfører handlinger på hverande, hverken det ene eller det andre er riktig eller har noe med objektorientering å gjøre. Det at man har Klasser og Objekter har dog kanskje noe med OO å gjøre...

 

Ellers sier du at

Fido ville vært et objekt av klassen Dog.

hvilket er feil. Fido ville vært en variabel med en referanse til et objekt av klassen Dog. - Er det riktige.

 

Å si at det du sa ikke er helt riktig er ikke det samme som å si at det er helt galt, bare at noe av det du sa ikke stemmer... ta det som konstruktiv kritikk... var ikke vondt ment...

 

Det er andre ukorrektheter i teksten din, men jeg gidder ikke å spikke fliser i kveld.

Svarer med dine egne ord:

Å si at noe av den ikke er riktig er derimot galt. Med mindre du kan peke på noe konkret du mener er galt?

 

A_N_K :

du overser f.eks glatt arv/polymorfi som er meget sentrale konsepter i OO

Sentraliteten i hvordan arv virker i et objektorientert miljø kan vi godt diskutere i en annen tråd, men det har INGENTING med spørsmålet denne tråden startet med: "Hva betyr egentlig Objekt orientert progammering?"

 

Dette spørsmålet har jeg forsøkt å besvare... på en måte som burde være FORSTÅELIG også for folk som aldri har programmert noe før.

 

Jeg unnskylder at jeg var uforskammet overfor deg, jeg overreagerte nok. Men jeg finner posten du skrev svært komplisert og innviklet og reagerte nok på at du skrev dette etter en slik post:

Håper at dette gjorde ting klarere (ikke mer diffust i alle fall?) :]

 

Jeg beklager selvfølgelig på det dypeste, dersom dine intensjoner med posten IKKE var å forvirre.

 

DETTE ER DET SISTE JEG KOMMENTERER DENNE SAKEN.

[A_N_K]

Jeg er ikke helt enig i at man skal se bort ifra arv/polymorfi ved forklaring av OO-begrepet (har blitt fortalt at Ole Johan Dahl fant opp sen binding av metoder). OO ble innført for å bedre modulariteten av programmer, dvs. strukturere programmet i selvstendige enheter som kommuniserer seg i mellom (på det abstrakte plan). Arv/polymorfi er en viktig mekanisme for å oppnå minst mulig avhengigheter mellom klassene som programmets oppgaver (aspekter) deles opp i. OO er ett av mange paradigmer, og det hjelper etter min mening å se hva som skiller det fra andre paradigmer (spesielt prosedyrell programmering). Se f.eks hva som skiller objektorienterte container-klasser i Java (inspirert av Smalltalk Collections) fra generiske containere i C++ (STL). Grunnen til at jeg går såpass detaljert til verks er at jeg selv synes det var mye forvirrende/diffus informasjon da jeg lærte om objekter, og skulle nå ønske at ting hadde vært mer konsist forklart da jeg lærte språket. Hvis dette blir for detaljert/teknisk går det selvfølgelig an å holde seg til Myubis/Terrasques forklaringer.

 

For å si det enkelt: OO er en måte å komponere et program ved å identifisere mindre oppgaver, som hver utføres av samarbeidende enheter. Hver enhet (objekt) tilhører en bestemt klasse, si f.eks at man har en Maler som har som oppgave å male geometriske objekter som Kvadrat eller Trekant. For å gjøre det enkelt for Maler bestemmer vi at Kvadrat og Trekant begge arver klassen Form. Dermed trenger Maler kun å vite at han maler objekter av typen Form, som har en metode mal(). Kvadrat og Trekant implementerer altså denne metoden på ulike vis uten at Maler trenger å vite dette.

Endret 19. februar 2005 av A_N_K

[Equerm]

Tusen tusen takk for mange gode svar! Alt ble mye mer klart nå. Som noen andre påpekte så vart det nok litt vanskelig for en person som meg som ikke har programmert serlig mye å skjønne den første forklaringen til A_N_K. Men etter de neste postene skjønte jeg mye mer.

 

Takk for hjelpen

 

-Equerm

[A_N_K]

Den første forklaringen min var sannsynligvis vel teknisk for en som er ny i faget, men jeg ønsket å komplettere de foregående forklaringene med (min oppfatning av) motivasjonen for OO og hvordan OO står i forhold til andre paradigmer (hvordan skiller det seg fra aspektorientering f.eks). Med motivasjonen tenker jeg på hvorfor Kristen Nygaard og Ole Johan Dahl bestemte seg for å utvikle et objektorientert programmeringsspråk (Simula), istedenfor å bruke prosedyrelle språk (C f.eks). Etterhvert som du får litt erfaring på egen hånd, vil jeg tippe at du ser nytten av konsise tekniske forklaringer selv om de kan være vanskelige å fordøye i første omgang. Lykke til