OOP

http://www.blinkenlights.se/wiki/OO
http://sv.wikipedia.org/wiki/Objektorientering

I princip kan man säga att i "vanlig" icke-oop (t.ex. som i språket C) så gör man såhär (lite pseudokodsaktigt):

// definiera en "struct", några datatyper som sitter ihop
struct point
{
    int x;
    int y;
}

// så har du en funktion som kan påverka en point-struct
void move(point myPoint, int newX, int newY)
{
  // noterea att den här funktionen, som egentligen inte har nåt att göra med "point", måste känna till hur den är definierad
   struct.x = newX;
   struct.y = newY;
}

// sen har du kanske en mainloop
void main()
{
    point cursor_position;
    while (true) // kör så länge som det går
    {
        if (mousePointerHasChangedPosition)
        {
              // uppdatera din egen point
              move(cursor_position, GetCursorPositionFrånOperativSystemetEllerNÅnting().x, GetCursorPositionFrånOperativSystemetEllerNÅnting().y);
        }
    }
}

I ett objektorienterat språk kan det istället se ut såhär:

// definiera en "class", några datatyper och metoder/funktioner
class point
{
private:   // göm dom här för omvärlden, allt omvärlden 
           // behöver kan dom göra genom mina funktioner, i det här fallet "move"
    int x;
    int y;
public:  // här kommer saker som resten av programmet kan se
    void move(int newX, int newY) // behöver inte ta in en struct
    {
         x = newX;  // x och y är "mina" intar
         y = newY;
    }
    int getX() { return x; } // användaren behöver inte veta att x-positionen lagras som en int
    int getY() { return y; } // utan kan bara använda funktionen glatt utan att känna till exakt hur den funkar
}


// sen har du kanske en mainloop igen
void main()
{
    point cursor_position;
    while (true) // kör så länge som det går
    {
        if (mousePointerHasChangedPosition)
        {
              // uppdatera din egen point
              point.move(GetCursorPositionFrånOperativSystemetEllerNÅnting().getX(), 
                         GetCursorPositionFrånOperativSystemetEllerNÅnting().getY());
        }
    }
}

Så skillnaden i stort är att man opererar på objekt som vet hur dom tar hand om sig själva, istället för att man har en uppsättning data och en uppsättning funktioner som opererar på den datan. Det har en bunt fördelar.

Nu finns det fler sätt att programmera på än dom två jag beskrivit, men antar att det var nåt sånt du ville veta.

Enklaste sättet att beskrigva objektorienterad programmering är att det är när man försöker dela in sina problem i objekt.

I spelprogrammering är OO speciellt lämpligt då man kan ha ett objekt för regn, ett för spelare, ett för träd etc.

Det som ofta brukar komplicera det hela är olika språks implementationer av OO.

Som srekel, på kanske ett lite svårtolkat sätt säger. I procedurell programmering skulle man kanske skriva:

while(true): #Klassiska oändliga loopen
    drawrain(raininfo)
    drawhouse(houseinfo)
    moveplayer(playerinfo, movement)
    drawplayer(playerinfo)

Medans med OO skulle det bli:

while(true): #Klassiska oändliga loopen
    myrain.draw()
    myhouse(houseinfo)
    myplayer.move(movement)
    myplayer.draw()

En viktig del i OO är att man kan gömma delar som inte bör synas utåt, till exempel behöver ju inte någon annan än husklassen veta exakt hur den målar upp sig, om det är en statisk bild som lagras gömt i house.image eller om det är en funktion som målar upp den med boxar är ju irellevant för andra delar av programmet, bara den ritas upp ordentligt av house.draw()

Det är dock möjligt att koda rätt så objekorienterat även i språk som inte har något inbyggt stöd för det, det blir bara lite krångligare. Jag rekommenderar att lära sig med ett språk som Ruby eller Python först, då de har en väldigt naturlig OO, allt är objekt i de språken.

Det är rätt svårt o greppa OOP innan man fått lite erfarenhet. Många av mina elever hade svårt med att se nyttan innan de tog ett av deras tidigare lite större projekt och delade upp programmet i klasser istället. Ett bra sätt för att lära ut i början brukar vara att dra paralleller till verkligheten.

Man kan säga att Gud var en programmerare och en jävligt duktig sådan. Om du tänker dig allt i hela universum är programmerat, så är tex människa en klass, medans tex kung Karl Gustav är ett objekt. Gud kodade först en klass för människan, denna klassen bestämmer hur en människa fungerar. Den innehåller all data ( int, string osv ) så som hjärta, hjärna osv. Klassen innehåller även funktioner så som Andas(), Äta( föda p_maten ) osv. Eftersom att Gud gjort en klass så kan han sedan ruggigt enkelt skapa ca 5 miljarder människor med hjälp av tex en array.

Människa JordensMänniskor[5000000000];

Ifall han inte hade använt OOP hade han istället fått skapa variabler lokalt för varje människa och sedan förmodligen fått använda sig av en massa funktioner som skulle varit tvugna och ta väldigt många paramterar. Hjärta i detta exemplet är dessutom i sin tur en klass som gud definerade all funktionalitet för som ett hjärta behöver för att fungera. Sedan om han behöver ett hjärta för en ko eller en människa är endast en mindre skillnad, då kan man använda sig av arv. Lättast är dock om du försöker greppa konceptet innan du gräver djupare.

Objektorientering är enbart ett sätt att abstrahera sitt program. Det är varken bättre eller sämre än andra abstraheringsmetoder. Blir koden lättare att förstå är det bättre, annars inte.

När man börjar skriva väldigt stora program så har man som programmerare ofta mycket att hålla reda på. Man vill ofta abstrahera bort så många detaljer som möjligt. Om man exempelvis skriver ett datorspel och har fixat lite kod för att spela upp ljud så vill man gärna på något vis glömma bort den här koden när man sedan arbetar på grafikkoden. Ljudkoden, som kanske är tusentals rader, gömmer man undan till några funktioner som man förusätter fungerar. Det här är väldigt bra för huvudet och en form av abstrahering, bättre än om man spred ut sin ljudkod mitt i grafikkoden. Det blir lätt en soppa av allt annars.

Objektorientering kan göra det lättare för huvudet om man kodar på något som på en konkret nivå är ett substantiv. Den här tumregeln säger att om man i sitt spel kan välja flera olika vapen (ett substantiv), så kan man skriva objektorienterad kod för vapnen. Objektorienteringen grupperar ihop koncept på en kodnivå precis som människan kan gruppera ihop koncept med varandra på hjärnnivå. Man kan ju exempelvis ladda om ett vapen. Konceptet "ladda om" hör till vapen, inte ljudkoden. Därför är det ju smidigt om man kan associera konceptet "ladda om" och vapnet i koden. Det kan man göra med objektorientering. Vidare. Både en shotgun och en railgun är ju olika typer av vapen, och borde ju alltså teoretiskt kunna dela kod, eller i alla fall för programmeraren fungera på samma vis. Det här kan objektorientering hjälpa till med.

Vad vinner man på detta? Programmeraren kan nu koda med vapen. Det här låter kanske jäkligt konstigt, men om man har lyckats med sin objektorientering så har man förlängt programmeringsspråket man användar på ett sådant vis att man direkt kan översätta hur man abstraherar i huvudet till hur man abstraherar i kod. Med lite övning givetvis.

Dessvärre verkar det finnas någon generellt accepterad åsikt att objektorientering är lösningen på alla jordens programmeringstekniska problem. Det här stämmer givetvis inte, precis lika lite som man kan lösa alla trädgårdstekniska problem med en motorsåg.

Aha. Ja, om man inte kan nån programmering alls kan jag förstå att mitt exempel var lite jobbigt. Förutsatte att du hade lite kunskap inom t.ex. C eller Java (men inte riktigt förstått poängen med OOP). Nåja, good luck!

Jo.

Att lära sig objektorienterad programmering är inte speciellt krångligt. Speciellt inte om du tar ett språk som C++ eller nått liknande. Man måste inte vidta några speciella åtgärder för att "fatta" det hela.

Svenska: http://lava.se/max/
Engelska: http://lava.se/sam/

Lite inte helt på mig men man kan ju säga att C++ inte "tvingar" (se det inte som något negativt) på dig OOP. När du börjar programmera så kan du nog göra ganska mycket i C++ eftersom det har mycket gemensamt med C som inte är OO. Om du läser en bok om C++ kommer de givetvis ta upp OO ganska snart.
Så du får det gradvis med dig i C++.

Men ser man till språk som python är OOP mer naturlig där, som någon skrev så är allt objekt. Där får du OO med "modersmjölken" när du lär dig språket.
Python är dock inte ett dåligt språk, tvärt om.

För att i till slut vara en flexibel och bra programmerare är det ju bra att inte bara ha hjärnan instängd i att allt ska lösas med OO. Som Psionicist skrev så är det inte lösningen på alla världens programmeringsteknisk problem.

Jag tror jag inte lyckades svara på vad du ville ha svar på men jag ville skriva lite

Du kommer inte få OOP "på köpet" om du lär dig C++. Jag tror att enda sättet att lära sig OOP är att först lära sig proceduriskt hur man programmerar, sedan gradvis gå över till OOP. Då förstår du varför och vad det är till för. Då kommer du upptäcka att programmera egentligen är lätt, och att det istället är svårt att designa program istället.

Leta tutorials på nätet och framför allt; skriva program. Få saker beror så mycket på erfarenhet som programmering.

Jag tror faktiskt att det är bäst att börja programmera utan OOP. Det kan man göra i princip alla språk. Har hört att folk som direkt börjar med OOP har svårare att se hur allt verkligen fungerar och får svårigheter när de inte ska programmera objektorienterat. Om du väl kan programmera "vanligt" kommer objektorienteringen inte innebära några konstigheter.

För en som aldrig hållt på med programmering så tycker jag en bok är bättre då den har ett upplägg och tar upp många delar. Inte hop-hafsat tutorial på nätet. Du skrev väl att du redan hade en bok om C++? Börja läs
btw vad heter den och skriven av vem? (så vi kan hylla den eller såga den).

Den är bra!

Den boken brukar rekommenderas. Har den själv fast inte läst i den ännu (kan en del C++ sen tidigare och köpte boken för den var billig då - jag borde nog fan läsa mer programmeringsböcker).

Jag tittade på innehållsförteckningen, det var inte förrens kapitel 10 du börjar programmera OO saker, du kommer ju använda färdiga saker i bibliotek osv som bygger på det tidigare men det "vet" du inte.

Så HTML och CSS kan ses som ett OOspråk? (Förutom att det inte är ett kodspråk, men som liknelse).

Där delar du in en sida i olika klasser (<div>, <p>, <b>) som ges egenskaper av en CSS, alltså får varje klass ett innehåll. Sen kan du skapa, vad kallade ni det? Arv? Om man t ex sätter en class på en div. Då kan den ärva egenskaperna från den förra diven med en viss evolution (förändring). Sen har du ID:n som kan motsvara objekt antar jag?

Försöker bara förstå det i termer som jag kan ta till mig, för det mesta jag läst här är bara godis i klubben för inbördes beundran. No offence

Ja darkmoon, det är samma koncept som man använder sig av när man pillar HTML/CSS. Om man ska jämföra med HTML/CSS så är den stora skillnaden att man kan skapa sina egna taggar.

darkmoon: Haha, det var ett nytt sätt att se på HTML + CSS