Hvad er objekt orienteret programmering?

Hej Lasserasch

Måske du skulle prøve at læse dette, måske det kunne give dig en ide.

http://en.wikipedia.org/wiki/Object_oriented_programming

det er svært at definere da der er så mange ting i det - men en meget simpel og firkanten forklaring;

Du skal programmere en bil:

hvis du ikke programmerer OOP og bilens sidespejl går i stykker så skal du programmere en helt ny bil og mens du gør det kan bilen slet ikke bruges.

programmerer du derimod en bil vha OOP og sidespejlet går i stykker så programmerer du bare et nyt sidespejl, eller hvis du er endnu mere heldigt og det kun er selve spejlet der er gået i stykker så programmerer du kun et nyt sidespejl - alle de øvrige ting (objekter) på bilen er gode nok og derfor beholder du dem og bilen kan (mere eller mindre) stadig bruges imens. Alt i alt er bilen opbygget af en masse små objekter - nogle er så godt som ingenting (fx spejlet som vel kun har en højde/bredde som en metode for at spejle sig i det) hvorimod andre ting (fx en dør (som igen består af andre objekter)) både har nogle egenskaber og nogle metoder (fx en farve og en form - samt åbn og luk).

På døren sidder formentlig også både et håndtag og en lås - låsen kan låse og låse op og håndtaget åbne og lukke. Men håndtaget og låsen kunne måske lige så vel sidde på en dør til et hus eller et pengeskab - funktionaliten er den samme så har du først lavet et håndtag-objekt kan du genbruge det andre steder. Alt i alt forsøger man at abstrahere fra at man skal programmere i første omgang - man skal derimod nedbryde det man vil lave til små enkeltstående dele der hver har nogle egenskaber (beskrivelser) og metoder (handlinger) som afspejler den virkelig verden.

Oversat til noget programmering betyder det at fx en gæstebog ikke bare er en gæstebog - en gæstebog i sig selv er selvfølgelig et objekt, men indlæggene i gæstebogen er også et objekt. hvor gæstebogen så bare kan være en samling af indlæg (uden egentlig at vide hvad at indlæg er) så har indlæggene nogle egenskaber (titel, tekst, skribent) og nogle metoder (nyt indlæg, slet). alle ting du kan benytte i .NET (textbox, button, label osv) er også objekter - fx har en knap mulighed for at du kan sætte farve, tekst og størrelse på den og så kan du fx klikke på den m.m.

Det lyder mest af alt som om at det du laver er funktions orienteret programmering - dvs samler handlinger i funktioner for overskuelig- og genbrugelighedens skyld.

Ok, har jeg forstået det korrekt hvis jeg så siger følgende :

Når jeg f.eks. har lavet en klasse jeg har kaldt for "functions.cs", så er det vel egentlig et objekt ik? Jeg opretter jo en ny reference på hver form jeg bruger den fra.

Ala : functions functions = new functions();

Og de voids der ligger i functions.cs er vel så metoder eller? Det er en samling af mange forskellige ting jeg har lagt heri.

F.eks. til at sætte egenskaberne for et grid. (Baggrundsfarve, tekststørrelser osv).

Hvis jeg f.eks. på en form havde et grid, så ville jeg sætte dennes egenskaber ved at skrive : functions.StyleGrid(DataGridView1);


Har jeg også forstået det korrekt, hvis jeg siger at man i en objekt orienteret kode, så faktisk ikke "må" udføre flere handlinger i samme void.

f.eks. så ville man vel ikke sætte både baggrundsfarven og tekststørrelsen i "StyleGrid(DataGridView1)"

Så ville man vel skulle kalde en ny void til at sætte baggrundsfarven for objektet, og en anden void som satte tekststørrelsen for objektet.

Hvis jeg har ret i dette, hvor vidt går man så "normalt" hvad angår dette. Kan godt se det ville være smart, da man så kunne kalde f.eks. "SetBGColor(Control A, Color B)" lige meget hvilket objekt man taler om. Så er det jo ligegyldigt om det er et DataGridView eller en label der skal sættes baggrundsfarve på.

Men kan det ikke hurtigt bliver meget uoverskueligt at arbejde på denne måde?

Eller har jeg bare overhovedet ikke forstået det korrekt endnu?

/lasse

så vidt jeg tolker det du skriver så er det stadig funktioner du arbejder med - det er dit datagridview der i dette tilfælde er dit object og det har allerede nogle egenskaber (fx baggrundsfarve og tekststørrelse) og dem vælger du så at lægge ind i en function og kalde derfra i stedet for direkte.

Det er derimod de data du vil vise i dit datagridview der højst sandsynligt er dit objekt - hvis du fx vælger at vise personer deri med navn og adresse samt mulighed for at slette eller ændre data så er person dit objekt med egenskaberne navn og adresse og metoderne slet og opdater.

Ok, så forstår jeg det nok ikke korrekt. Har bare ofte fået at vide, at det var smart at programmere objekt orienteret.

Så forstår jeg nok bare ikke tilgangsvinklen.

En person som ville programmere objekt orienteret, hvordan ville han opbygge sin programkode i forhold til den måde jeg bruger, hvor jeg har forskellige forms med objekter på. Når jeg trykker på f.eks. en knap udfører jeg en handling.

Forstår så åbenbart ikke helt hvordan et objekt orienteret programkode ville gøre ting anderledes.

Men kan være jeg en dag finder ud af det.... Umiddelbart kan jeg ikke lige se fidusen så. måske der skal nogle rigtige programkode eksempler til før jeg fatter det.

Nå, men tak for jeres svar, smid et svar dem som vil have points!

/Lasse

Der er heller ingen der har sagt at det er let :) Det som der nok går galt i dit tilfælde er, at du kun tænker kode og ikke kommer ud i "det virkelige liv". Du skal bort fra at tænke på at en knap er en knap osv - for det er udelukkende frontend til at håndtere dine objekter.

Der er ikke én rigtig opbygning - og det er selvfølgelig med til at gøre det endnu sværere at forstå - men et eksempel på en opbygning ville være, at man havde et database-lag der tog sig af al kommunikation til databasen (select, update, insert, delete, stored procedures...) - derefter havde man et business-lag hvori du opbygger dine objekter (altså fortæller hvilke egenskaber og metoder de har de forskellige dele af dit program (ikke knapper - men objekter i dit program uanset om det er en gæstebog, et regnskab eller whatever)) - og sidste trin er præsentationslaget og det er først hér du begynder at tænke knapper, udseende osv og indsætter du fx en knap der skal slette et objekt så er det herfra du kalder slet-metoden i dit business-lag.

Nej det er vist ikke helt så lige til igen!

Nå, mit hovedet knager nok i forvejen efter byturen igår, så den tanke lader jeg lige ligge på hylden for resten af dagen!

/Lasse

Jeg står også af.. Jeg har lige læst, at sproget C ikke er objekt-orienteret, men at det ikke hindrer programmøren i at tænke objekt-orienteret, når han bruger det... =S

C kender jeg intet til så der kan jeg ikke rigtig komme med input.

Det er på ingen måde let at lære OOP, specielt hvis man kommer fra fx gammeldags ASP synes jeg. Omvendt set er det altså en meget vigtig del af .NET hvis man vil noget med det - selvfølgelig kan ens kunder ikke se hvordan det er bygget op, men foruden at måske andre programmører kommer til at overtage det og ikke vil kunne bruge en forkert struktur til noget så vil jeg også mene at ens egen selvrespekt for et stykke prof arbejde gør at man bør lave det rigtigt fra starten.

En god bog for at komme videre vil evt være "Objekt Orienterede Begreber" som dog måske er lidt abstrakt men ganske god samt "ASP.NET 2.0 Problem - Design - Solution" hvor man følger opbygningen af en webshop.

ok, så ASP er ikke OOP? Troede jeg ellers.. :S

ASP har ikke det fjerneste med OOP at gøre ...

-- asp (Active Server Pages) er en arkitektur, der gør det muligt med en IIS (M$ Internet Information Service) at servere dynamiske sider fra en server, dette kan opnås med en lang række forskellige programmeringssprog, hvor en del er OOP, nogle er OO (ObjektOrienterede), nogle er OB (ObjektBaserede) og nogle ikke nødvendigvis er ObjectEnabled ...

Klassisk ASP er baseret på VBscript, som i et vist omfang er objekt-baseret, men sagtens kan benyttes uden nogensinde at opdage, at der findes objekter (baseret på Visual Basic (/VBA, for Applications), som i kernen er OB, men du vil oftest støde ind i ren procedural kode, hvor objekterne ikke ses eller anvendes !-)

I modsætning til dette kan findes .NET/C#, hvor kodebasen er ekstremt meget baseret på OOP, men dog har en del hjørner, hvor OOP-tingen toner i baggrunden pga. den pragmatiske indgangsvinkel til f.eks. session- og application-variabler, som har en vis sammenligning til singleton-objekter i egentlig OOP (hrm, nu er jeg vist en anelse tyndt ude !-)

Men blandt gyldige asp-kodesprog kan bla. nævnes Java (OOP), C (objekter kan kodes ind, men det kræver virkelig, at man kan programmere, f.eks. fordi garbage-collection skal udføres nærmest manuelt), C++ (en principielt OOP-udvidelse af C), vbscript (et scripting-sprog baseret på klassisk Basic) og f.eks. Jscript (M$-udgaven af ECMA-script, som faktisk kan kodes som ren OOP, men principielt 'bare' er objekt-baseret !-)

Hrm, LISP og andre muligheder findes vist også ...

Jamen så er det jo derfor, jeg synes .NET er så mærkeligt. :)