Objektorientert programmering - Object-oriented programming

"Objektorientert" omdirigerer her. For andre betydninger av objektorientert, se Objektorientering .
"Objektorientert programmeringsspråk" omdirigerer her. For en liste over objektorienterte programmeringsspråk, se Liste over objektorienterte programmeringsspråk .

Programmeringsparadigmer

Objektorientert programmering ( OOP ) er et programmeringsparadigme basert på begrepet " objekter ", som kan inneholde data og kode: data i form av felt (ofte kjent som attributter eller egenskaper ), og kode, i form av prosedyrer (ofte kjent som metoder ).

Et trekk ved objekter er at objektets egne prosedyrer kan få tilgang til og ofte endre datafeltene i seg selv (objekter har en forestilling om eller ). I OOP er dataprogrammer designet ved å gjøre dem ut av objekter som samhandler med hverandre. OOP-språk er forskjellige, men de mest populære er klassebaserte , noe som betyr at objekter er forekomster av klasser , som også bestemmer deres typer . thisself

Mange av de mest brukte programmeringsspråkene (som C ++, Java, Python, etc.) er multi-paradigme og de støtter objektorientert programmering i større eller mindre grad, vanligvis i kombinasjon med imperativ , prosessuell programmering . Viktige objektorienterte språk inkluderer: Java , C ++ , C# , Python , R , PHP , Visual Basic.NET , JavaScript , Ruby , Perl , SIMSCRIPT , Object Pascal , Objective-C , Dart , Swift , Scala , Kotlin , Common Lisp , MATLAB og Smalltalk .

Historie

UML -notasjon for en klasse. Denne Button -klassen har variabler for data og funksjoner . Gjennom arv kan en underklasse opprettes som en delmengde av Button -klassen. Objekter er forekomster av en klasse.

Terminologi som påberoper seg "objekter" og "orientert" i moderne forstand av objektorientert programmering, gjorde sin første opptreden på MIT på slutten av 1950-tallet og begynnelsen av 1960-tallet. I miljøet til den kunstige intelligensgruppen , så tidlig som i 1960, kunne "objekt" referere til identifiserte gjenstander ( LISP -atomer) med egenskaper (attributter); Alan Kay siterte senere en detaljert forståelse av LISP internals som en sterk innflytelse på hans tenkning i 1966.

Jeg tenkte på at objekter var som biologiske celler og/eller individuelle datamaskiner på et nettverk, bare i stand til å kommunisere med meldinger (så meldinger kom helt i begynnelsen - det tok litt tid å se hvordan man gjorde meldinger på et programmeringsspråk effektivt nok til å være nyttig).

Alan Kay,

Et annet tidlig MIT -eksempel var Sketchpad laget av Ivan Sutherland i 1960–1961; i ordlisten til den tekniske rapporten fra 1963 basert på avhandlingen hans om Sketchpad, definerte Sutherland forestillinger om "objekt" og "forekomst" (med klassekonseptet dekket av "mester" eller "definisjon"), om enn spesialisert til grafisk interaksjon. En MIT ALGOL- versjon, AED-0, etablerte også en direkte kobling mellom datastrukturer ("plexer", på den dialekten) og prosedyrer, og forhåndsdefinerte det som senere ble kalt "meldinger", "metoder" og "medlemsfunksjoner".

I 1962 startet Kristen Nygaard et prosjekt for et simuleringsspråk ved Norwegian Computing Center , basert på hans tidligere bruk av Monte Carlo-simuleringen og hans arbeid med å konseptualisere virkelige systemer. Ole-Johan Dahl ble formelt med i prosjektet og programmeringsspråket Simula ble designet for å kjøre på Universal Automatic Computer (UNIVAC) 1107. Simula introduserte viktige konsepter som i dag er en vesentlig del av objektorientert programmering, for eksempel klasse og objekt , arv. og dynamisk binding . Simula ble også designet for å ta hensyn til programmering og datasikkerhet . For programmering sikkerhetshensyn en søkeprosessen ble implementert slik at gjennom referanse teller en siste utvei søppelinnsamler slettet ubrukte gjenstander i random-access memory (RAM). Men selv om ideen om dataobjekter allerede var etablert innen 1965, ble ikke innkapsling av data gjennom omfanget av variabler , for eksempel private (-) og offentlige (+), implementert i Simula fordi det ville ha krevd tilgangsprosedyrer også skjult.

I de tidlige stadiene skulle Simula være en prosedyrepakke for programmeringsspråket ALGOL 60. Misfornøyd med begrensningene som ble pålagt av ALGOL, bestemte forskerne seg for å utvikle Simula til et fullverdig programmeringsspråk, som brukte UNIVAC ALGOL 60-kompilatoren. Simula ble promotert av Dahl og Nygaard gjennom 1965 og 1966, noe som førte til økende bruk av programmeringsspråket i Sverige, Tyskland og Sovjetunionen . I 1968 ble språket allment tilgjengelig gjennom Burroughs B5500-datamaskinene , og ble senere også implementert på URAL-16-datamaskinen . I 1966 skrev Dahl og Nygaard en Simula -kompilator . De ble opptatt av å praktisere Tony Hoares rekordklassekonsept , som hadde blitt implementert i gratisformet engelsk-lignende simuleringsspråk SIMSCRIPT . De nøyde seg med et generalisert prosesskonsept med rekordklasseegenskaper og et andre lag med prefikser. Gjennom prefiks kan en prosess referere til forgjengeren og ha flere egenskaper. Simula introduserte dermed klasse- og underklassehierarkiet, og muligheten til å generere objekter fra disse klassene.

En Simula 67 -kompilator ble lansert for system-/360- og System/370 -IBM -datamaskinene i 1972. Samme år ble en Simula 67 -kompilator lansert gratis for de franske CII 10070- og CII Iris 80 -datamaskinene . I 1974 hadde Association of Simula Users medlemmer i 23 forskjellige land. Tidlig i 1975 ble en Simula 67-kompilator utgitt gratis for DECsystem-10 mainframe-familien. I august samme år hadde DECsystem-10 Simula 67-kompilatoren blitt installert på 28 steder, 22 av dem i Nord-Amerika. Det objektorienterte Simula-programmeringsspråket ble hovedsakelig brukt av forskere som var involvert i fysisk modellering , for eksempel modeller for å studere og forbedre bevegelsen av skip og deres innhold gjennom lasteporter.

På 1970 -tallet ble den første versjonen av Smalltalk programmeringsspråk utviklet på Xerox PARC av Alan Kay , Dan Ingalls og Adele Goldberg . Smaltalk-72 inkluderte et programmeringsmiljø og ble dynamisk skrevet , og ble først tolket , ikke kompilert . Smalltalk ble kjent for sin anvendelse av objektorientering på språknivå og sitt grafiske utviklingsmiljø. Smalltalk gikk gjennom forskjellige versjoner og interessen for språket vokste. Mens Smalltalk ble påvirket av ideene som ble introdusert i Simula 67, var det designet for å være et fullt dynamisk system der klasser kunne opprettes og endres dynamisk.

På 1970-tallet påvirket Smalltalk Lisp-samfunnet til å inkorporere objektbaserte teknikker som ble introdusert for utviklere via Lisp-maskinen . Eksperimentering med forskjellige utvidelser til Lisp (for eksempel LOOPS og Flavors som introduserte flere arv og mixins ) førte til slutt til Common Lisp Object System , som integrerer funksjonell programmering og objektorientert programmering og tillater utvidelse via en Meta-objekt-protokoll . På 1980 -tallet var det noen få forsøk på å designe prosessorarkitekturer som inkluderte maskinvarestøtte for objekter i minnet, men disse var ikke vellykkede. Eksempler inkluderer Intel iAPX 432 og Linn Smart Rekursiv .

I 1981 redigerte Goldberg augustutgaven av Byte Magazine , og introduserte Smalltalk og objektorientert programmering for et bredere publikum. I 1986 arrangerte Association for Computing Machinery den første konferansen om objektorientert programmering, systemer, språk og applikasjoner (OOPSLA), som uventet deltok av 1000 mennesker. På midten av 1980-tallet ble Objective-C utviklet av Brad Cox , som hadde brukt Smalltalk ved ITT Inc. , og Bjarne Stroustrup , som hadde brukt Simula til doktorgradsavhandlingen, gikk til slutt for å lage den objektorienterte C ++ . I 1985 produserte Bertrand Meyer også det første designet av Eiffelspråket . Med fokus på programvarekvalitet er Eiffel et rent objektorientert programmeringsspråk og en notasjon som støtter hele programvarens livssyklus. Meyer beskrev Eiffel-programvareutviklingsmetoden, basert på et lite antall sentrale ideer fra programvareingeniør og datavitenskap, i Object-Oriented Software Construction . Essensielt for kvalitetsfokuset til Eiffel er Meyers pålitelighetsmekanisme, Design by Contract , som er en integrert del av både metoden og språket.

Den TIOBE programmeringsspråk popularitet indeks grafen fra 2002 til 2018. På 2000-tallet objektorientert Java (blå) og prosessuelle C (svart) konkurrerte for topplasseringen.

I begynnelsen og midten av 1990-tallet objektorientert programmering utviklet som den dominerende programmering paradigme når programmeringsspråk som støtter teknikkene ble allment tilgjengelig. Disse inkluderte Visual FoxPro 3.0, C ++ og Delphi . Dens dominans ble ytterligere forsterket av den økende populariteten til grafiske brukergrensesnitt , som er svært avhengige av objektorienterte programmeringsteknikker. Et eksempel på et nært beslektet dynamisk GUI-bibliotek og OOP-språk finnes i Cocoa- rammene på Mac OS X , skrevet i Objective-C , en objektorientert, dynamisk meldingsutvidelse til C basert på Smalltalk. OOP-verktøysett økte også populariteten til hendelsesdrevet programmering (selv om dette konseptet ikke er begrenset til OOP).

På ETH Zürich hadde Niklaus Wirth og hans kolleger også undersøkt temaer som dataabstraksjon og modulær programmering (selv om dette hadde vært i vanlig bruk på 1960 -tallet eller tidligere). Modula-2 (1978) inkluderte begge deler, og deres etterfølgende design, Oberon , inkluderte en særegen tilnærming til objektorientering, klasser og slikt.

Objektorienterte funksjoner er lagt til på mange tidligere eksisterende språk, inkludert Ada , BASIC , Fortran , Pascal og COBOL . Å legge disse funksjonene til språk som ikke opprinnelig var designet for dem, førte ofte til problemer med kompatibilitet og vedlikehold av koden.

Nylig har det dukket opp en rekke språk som først og fremst er objektorienterte, men som også er kompatible med prosessuell metodikk. To slike språk er Python og Ruby . Sannsynligvis de mest kommersielt viktige nyere objektorienterte språkene er Java , utviklet av Sun Microsystems , samt C# og Visual Basic.NET (VB.NET), begge designet for Microsofts .NET- plattform. Hver av disse to rammene viser på sin egen måte fordelen med å bruke OOP ved å lage en abstraksjon fra implementeringen. VB.NET og C# støtter tverrspråklig arv, slik at klasser som er definert på ett språk, kan underklasse klasser definert på det andre språket.

Funksjoner

Objektorientert programmering bruker objekter, men ikke alle de tilknyttede teknikkene og strukturene støttes direkte på språk som hevder å støtte OOP. Funksjonene som er oppført nedenfor er vanlige blant språk som anses å være sterkt klasse- og objektorienterte (eller multi-paradigme med OOP-støtte), med nevneverdige unntak nevnt.

Se også: Sammenligning av programmeringsspråk (objektorientert programmering) og Liste over objektorienterte programmeringsuttrykk

Delt med språk som ikke er OOP

Modulær programmeringsstøtte gir muligheten til å gruppere prosedyrer i filer og moduler for organisatoriske formål. Moduler er navneskilt, så identifikatorer i en modul vil ikke være i konflikt med en prosedyre eller variabel som deler samme navn i en annen fil eller modul.

Objekter og klasser

Språk som støtter objektorientert programmering (OOP) bruker vanligvis arv for gjenbruk og utvidbar kode i form av klasser eller prototyper . De som bruker klasser støtter to hovedbegreper:

  • Klasser - definisjonene for dataformatet og tilgjengelige prosedyrer for en gitt type eller klasse av objekter; kan også inneholde data og prosedyrer (kjent som klassemetoder) selv, dvs. klasser inneholder datamedlemmene og medlemsfunksjonene
  • Objekter - forekomster av klasser

Objekter tilsvarer noen ganger ting som finnes i den virkelige verden. For eksempel kan et grafikkprogram ha objekter som "sirkel", "firkant", "meny". Et online shoppingsystem kan ha objekter som "handlevogn", "kunde" og "produkt". Noen ganger representerer objekter mer abstrakte enheter, som et objekt som representerer en åpen fil, eller et objekt som tilbyr tjenesten til å oversette målinger fra USA som er vanlige til metriske.

Objektorientert programmering er mer enn bare klasser og objekter; det er et helt programmeringsparadigme basert på [ sic ] objekter (datastrukturer) som inneholder datafelt og metoder. Det er vesentlig å forstå dette; å bruke klasser for å organisere en haug med ikke -relaterte metoder sammen er ikke objektorientering.

Junade Ali, Mastering PHP Design Patterns

Hvert objekt sies å være en forekomst av en bestemt klasse (for eksempel kan et objekt med navnefeltet satt til "Mary" være en forekomst av klasseansatt). Prosedyrer i objektorientert programmering er kjent som metoder ; variabler er også kjent som felt , medlemmer, attributter eller egenskaper. Dette fører til følgende vilkår:

  • Klassevariabler - tilhører klassen som helhet ; det er bare ett eksemplar av hver
  • Forekomstvariabler eller attributter - data som tilhører individuelle objekter ; hvert objekt har sin egen kopi av hvert objekt
  • Medlemsvariabler - refererer til både klasse- og forekomstvariablene som er definert av en bestemt klasse
  • Klassemetoder - tilhører klassen som helhet og har kun tilgang til klassevariabler og innganger fra prosedyreoppropet
  • Forekomstmetoder - tilhører individuelle objekter , og har tilgang til forekomstvariabler for det spesifikke objektet de kalles til, innganger og klassevariabler

Objekter er tilgjengelig på en måte som variabler med kompleks intern struktur, og er på mange språk effektivt pekere som fungerer som faktiske referanser til en enkelt forekomst av objektet i minnet i en haug eller bunke. De gir et lag med abstraksjon som kan brukes til å skille intern fra ekstern kode. Ekstern kode kan bruke et objekt ved å kalle en bestemt forekomstmetode med et bestemt sett med inndataparametere, lese en forekomstvariabel eller skrive til en forekomstvariabel. Objekter blir opprettet ved å kalle en spesiell type metode i klassen kjent som en konstruktør . Et program kan opprette mange forekomster av samme klasse som det kjører, som fungerer uavhengig. Dette er en enkel måte for de samme prosedyrene å bli brukt på forskjellige datasett.

Objektorientert programmering som bruker klasser kalles noen ganger klassebasert programmering , mens prototypebasert programmering vanligvis ikke bruker klasser. Som et resultat brukes betydelig forskjellig, men analog terminologi for å definere begrepene objekt og forekomst .

På noen språk kan klasser og objekter komponeres ved hjelp av andre konsepter som trekk og mixins .

Klassebasert vs prototypebasert

I klassebaserte språk er klassene definert på forhånd og objektene blir instantiert basert på klassene. Hvis to gjenstander eple og appelsin blir instantiert fra klassen Frukt , er de iboende frukt, og det er garantert at du kan håndtere dem på samme måte; f.eks. kan en programmerer forvente eksistensen av de samme attributtene som farge eller sukker_innhold eller er_ripe .

I prototypebaserte språk er objektene de primære enhetene. Ingen klasser eksisterer engang. Den prototype av et objekt er bare en annen gjenstand som objektet er knyttet til. Hvert objekt har en prototypelink (og bare en). Nye objekter kan opprettes basert på allerede eksisterende objekter valgt som deres prototype. Du kan kalle to forskjellige objekter eple og appelsin en frukt, hvis objektfrukten eksisterer, og både eple og appelsin har frukt som prototype. Ideen om fruktklassen eksisterer ikke eksplisitt, men som ekvivalensklassen til objektene som deler den samme prototypen. Attributtene og metodene til prototypen er delegert til alle objektene i ekvivalensklassen definert av denne prototypen. Attributtene og metodene som eies individuelt av objektet, kan ikke deles av andre objekter av samme ekvivalensklasse; f.eks. kan attributtet sugar_content uventet ikke finnes i apple . Bare enkelt arv kan implementeres gjennom prototypen.

Dynamisk utsendelse/melding

Det er objektets ansvar, ikke noen ekstern kode, å velge den prosessuelle koden som skal utføres som svar på et metodeanrop, vanligvis ved å slå opp metoden ved kjøretid i en tabell knyttet til objektet. Denne funksjonen er kjent som dynamisk utsendelse , og skiller et objekt fra en abstrakt datatype (eller modul), som har en fast (statisk) implementering av operasjonene for alle forekomster. Hvis anropsvariabiliteten er avhengig av mer enn enkelttypen av objektet den kalles til (dvs. minst ett annet parameterobjekt er involvert i metodevalget), snakker man om flere forsendelser .

En metodeoppringning er også kjent som meldingsoverføring . Det blir konseptualisert som en melding (navnet på metoden og dens inndataparametere) som sendes til objektet for utsendelse.

Innkapsling

Innkapsling er et objektorientert programmeringskonsept som binder sammen dataene og funksjonene som manipulerer dataene, og som både beskytter mot forstyrrelser fra utsiden og misbruk. Datakapsling førte til det viktige OOP -konseptet med dataskjuling .

Hvis en klasse ikke tillater ringekode å få tilgang til interne objektdata og bare tillater tilgang via metoder, er dette en sterk form for abstraksjon eller skjuling av informasjon, kjent som innkapsling . Noen språk (for eksempel Java) lar klasser håndheve tilgangsbegrensninger eksplisitt, for eksempel å privateangi interne data med søkeordet og angi metoder beregnet for bruk av kode utenfor klassen med publicsøkeordet. Metoder kan også utformes offentlige, private eller mellomliggende nivåer som protected(som gir tilgang fra samme klasse og dens underklasser, men ikke objekter av en annen klasse). På andre språk (som Python) håndheves dette bare etter konvensjon (for eksempel kan privatemetoder ha navn som starter med en understreking ). Innkapsling forhindrer ekstern kode i å være opptatt av det interne arbeidet til et objekt. Dette forenkler refaktorering av kode , for eksempel slik at forfatteren av klassen kan endre hvordan objektene i den klassen representerer dataene sine internt uten å endre noen ekstern kode (så lenge "offentlige" metodeanrop fungerer på samme måte). Det oppfordrer også programmerere til å sette all koden som er opptatt av et bestemt datasett i samme klasse, som organiserer den for enkel forståelse av andre programmerere. Innkapsling er en teknikk som oppmuntrer til frakobling .

Sammensetning, arv og delegering

Objekter kan inneholde andre objekter i forekomstvariablene; dette er kjent som objektsammensetning . For eksempel kan et objekt i medarbeiderklassen inneholde (enten direkte eller gjennom en peker) et objekt i adresseklassen, i tillegg til sine egne forekomstvariabler som "fornavn" og "posisjon". Objektsammensetning brukes til å representere "har-a" -forhold: hver ansatt har en adresse, så alle ansatteobjekter har tilgang til et sted å lagre et adresseobjekt (enten direkte innebygd i seg selv, eller på et eget sted adressert via en peker) .

Språk som støtter klasser støtter nesten alltid arv . Dette gjør at klasser kan arrangeres i et hierarki som representerer "er-en-type-av" relasjoner. Klasse ansatt kan for eksempel arve fra klasse person. Alle dataene og metodene som er tilgjengelig for foreldreklassen, vises også i barneklassen med samme navn. Klasseperson kan for eksempel definere variabler "fornavn" og "etternavn" med metoden "make_full_name ()". Disse vil også være tilgjengelige i klassen Employee, som kan legge til variablene "posisjon" og "lønn". Denne teknikken tillater enkel gjenbruk av de samme prosedyrene og datadefinisjonene, i tillegg til å potensielt gjenspeile virkelige forhold på en intuitiv måte. I stedet for å bruke databasetabeller og programmere underrutiner, bruker utvikleren objekter brukeren kan være mer kjent med: objekter fra applikasjonsdomenet.

Underklasser kan overstyre metodene definert av superklasser. Flere arv er tillatt på noen språk, selv om dette kan gjøre løsning overstyring komplisert. Noen språk har spesiell støtte for mixins , men på et hvilket som helst språk med flere arv, er en mixin rett og slett en klasse som ikke representerer en is-a-type-relasjon. Mixins brukes vanligvis for å legge til de samme metodene i flere klasser. For eksempel kan klasse UnicodeConversionMixin tilby en metode unicode_to_ascii () når den er inkludert i klassen FileReader og klassen WebPageScraper, som ikke deler en felles overordnet.

Abstrakte klasser kan ikke instantieres til objekter; de eksisterer bare med det formål å arve til andre "konkrete" klasser som kan instantieres. I Java kan finalsøkeordet brukes til å forhindre at en klasse blir underklassert.

Læren om sammensetning over arv går inn for å implementere ha-a-forhold ved å bruke komposisjon i stedet for arv. For eksempel, i stedet for å arve fra klasseperson, kan klasse -ansatt gi hvert ansatt -objekt et internt personobjekt, som den deretter har mulighet til å skjule for ekstern kode, selv om klasseperson har mange offentlige attributter eller metoder. Noen språk, som Go, støtter ikke arv i det hele tatt.

" Åpent/lukket -prinsippet " går inn for at klasser og funksjoner "skal være åpne for forlengelse, men lukket for endring".

Delegasjon er en annen språkfunksjon som kan brukes som et alternativ til arv.

Polymorfisme

Subtyping - en form for polymorfisme - er når ringekode kan være agnostisk om hvilken klasse i det støttede hierarkiet den opererer på - foreldreklassen eller en av dens etterkommere. I mellomtiden kan det samme operasjonsnavnet blant objekter i et arvehierarki oppføre seg annerledes.

For eksempel er objekter av typen Circle and Square avledet fra en vanlig klasse som heter Shape. Tegnfunksjonen for hver type form implementerer det som er nødvendig for å tegne seg selv mens ringekoden kan forbli likegyldig til den spesifikke formen som tegnes.

Dette er en annen type abstraksjon som forenkler kode utenfor klassehierarkiet og muliggjør sterk separasjon av bekymringer .

Åpen rekursjon

På språk som støtter åpen rekursjon , kan objektmetoder kalle andre metoder på det samme objektet (inkludert seg selv), vanligvis ved å bruke en spesiell variabel eller et nøkkelord kalt thiseller self. Denne variabelen er senbundet ; det tillater en metode definert i en klasse å påberope seg en annen metode som er definert senere, i noen underklasse derav.

OOP språk

Se også: Liste over objektorienterte programmeringsspråk

Simula (1967) er generelt akseptert som det første språket med hovedtrekkene i et objektorientert språk. Den ble laget for å lage simuleringsprogrammer , der det som ble kalt objekter var den viktigste informasjonsrepresentasjonen. Smalltalk (1972 til 1980) er et annet tidlig eksempel, og det som mye av teorien om OOP ble utviklet med. Når det gjelder graden av objektorientering, kan følgende skilles:

OOP på dynamiske språk

De siste årene har objektorientert programmering blitt spesielt populær innen dynamiske programmeringsspråk . Python , PowerShell , Ruby og Groovy er dynamiske språk bygget på OOP-prinsipper, mens Perl og PHP har lagt til objektorienterte funksjoner siden Perl 5 og PHP 4, og ColdFusion siden versjon 6.

The Document Object Model av HTML , XHTML og XML -dokumenter på Internett har bindinger til den populære Java / ECMAScript språk. JavaScript er kanskje det mest kjente prototypebaserte programmeringsspråket , som bruker kloning fra prototyper i stedet for å arve fra en klasse (kontrast til klassebasert programmering ). Et annet skriptspråk som bruker denne tilnærmingen er Lua .

OOP i en nettverksprotokoll

Meldingene som flyter mellom datamaskiner for å be om tjenester i et klient-server-miljø kan utformes som linearisering av objekter definert av klasseobjekter kjent for både klienten og serveren. For eksempel vil et enkelt linearisert objekt bestå av et lengdefelt, et kodepunkt som identifiserer klassen og en dataverdi. Et mer komplekst eksempel ville være en kommando som består av kommandoens lengde og kodepunkt og verdier som består av lineariserte objekter som representerer kommandoens parametere. Hver slik kommando må rettes av serveren til et objekt hvis klasse (eller superklasse) gjenkjenner kommandoen og kan levere den forespurte tjenesten. Klienter og servere er best modellert som komplekse objektorienterte strukturer. Distributed Data Management Architecture (DDM) tok denne tilnærmingen og brukte klasseobjekter til å definere objekter på fire nivåer i et formelt hierarki:

  • Felt som definerer dataverdiene som danner meldinger, for eksempel lengde, kodepunkt og dataverdier.
  • Objekter og samlinger av objekter som ligner på det som finnes i et Smalltalk -program for meldinger og parametere.
  • Administratorer som ligner på IBM i Objects , for eksempel en katalog til filer og filer som består av metadata og poster. Ledere gir konseptuelt minne og behandlingsressurser for objektene de inneholder.
  • En klient eller server som består av alle lederne som er nødvendige for å implementere et fullt behandlingsmiljø, som støtter aspekter som katalogtjenester, sikkerhet og samtidighetskontroll.

Den første versjonen av DDM definerte distribuerte filtjenester. Det ble senere utvidet til å være grunnlaget for Distributed Relational Database Architecture (DRDA).

Designmønstre

Utfordringer med objektorientert design tas opp av flere tilnærminger. Mest vanlig er kjent som designmønstrene kodifisert av Gamma et al. . Mer generelt kan begrepet " designmønstre " brukes til å referere til ethvert generelt, repeterbart, løsningsmønster på et vanlig problem i programvaredesign. Noen av disse vanlige problemene har implikasjoner og løsninger spesielt på objektorientert utvikling.

Arv og atferdsmessig undertyping

Se også: Objektorientert design

Det er intuitivt å anta at arv skaper et semantisk " er et " forhold, og dermed slutte at objekter som er instantiert fra underklasser, alltid kan brukes trygt i stedet for de som er instantiert fra superklassen. Denne intuisjonen er dessverre falsk i de fleste OOP -språk, spesielt i alle de som tillater foranderlige objekter. Subtype polymorfisme som håndheves av typen brikken i OOP språk (med foranderlig gjenstander) kan ikke garantere atferds subtyping i enhver sammenheng. Atferdsmessig undertyping er generelt uavgjort, så den kan ikke implementeres av et program (kompilator). Klasse- eller objekthierarkier må være nøye designet, med tanke på mulig feil bruk som ikke kan oppdages syntaktisk. Dette problemet er kjent som Liskov -substitusjonsprinsippet .

Gang of Four designmønstre

Hovedartikkel: Designmønster (informatikk)

Design Patterns: Elements of Reusable Object-Oriented Software er en innflytelsesrik bok utgitt i 1994 av Erich Gamma , Richard Helm , Ralph Johnson og John Vlissides , ofte omtalt humoristisk som "Gang of Four". Sammen med å utforske mulighetene og fallgruvene til objektorientert programmering, beskriver den 23 vanlige programmeringsproblemer og mønstre for å løse dem. Fra april 2007 var boken i 36. utgave.

Boken beskriver følgende mønstre:

Objektorientering og databaser

Hovedartikler: Objekt-relasjonell impedans-mismatch , Objekt-relasjonell kartlegging og Objektdatabase

Både objektorientert programmering og relasjonsdatabasehåndteringssystemer (RDBMS) er ekstremt vanlige i programvare i dag. Siden relasjonsdatabaser ikke lagrer objekter direkte (selv om noen RDBMS har objektorienterte funksjoner for å tilnærme dette), er det et generelt behov for å bygge bro mellom de to verdenene. Problemet med å bygge bro mellom objektorientert programmeringstilgang og datamønster med relasjonsdatabaser er kjent som objektrelasjonell impedans-mismatch . Det er en rekke tilnærminger for å takle dette problemet, men ingen generell løsning uten ulemper. En av de vanligste tilnærmingene er objektrelasjonskartlegging , som finnes på IDE- språk som Visual FoxPro og biblioteker som Java Data Objects og Ruby on Rails 'ActiveRecord.

Det er også objektdatabaser som kan brukes til å erstatte RDBMS, men disse har ikke vært så teknisk og kommersielt vellykkede som RDBMS.

Virkelig modellering og relasjoner

OOP kan brukes til å knytte virkelige objekter og prosesser til digitale kolleger. Imidlertid er ikke alle enige om at OOP tilrettelegger for direkte kartlegging i den virkelige verden (se avsnittet Kritikk ) eller at virkelighetskartlegging til og med er et verdig mål; Bertrand Meyer argumenterer i Object-Oriented Software Construction at et program ikke er en modell av verden, men en modell for en del av verden; "Virkeligheten er en fetter to ganger fjernet". Samtidig har noen hovedbegrensninger ved OOP blitt notert. For eksempel er sirkel-ellipseproblemet vanskelig å håndtere ved bruk av OOPs konsept om arv .

Imidlertid sa Niklaus Wirth (som populariserte ordtaket som nå er kjent som Wirths lov : "Programvare blir tregere raskere enn maskinvare blir raskere") om OOP i avisen sin, "Gode ideer gjennom glasset", "Dette paradigmet gjenspeiler nøye struktur av systemer 'i den virkelige verden', og den er derfor godt egnet til å modellere komplekse systemer med kompleks atferd "(kontrast KISS -prinsippet ).

Steve Yegge og andre bemerket at naturlige språk mangler OOP -tilnærmingen til å prioritere ting (objekter/ substantiv ) strengt før handlinger (metoder/ verb ). Dette problemet kan føre til at OOP lider mer kronglete løsninger enn prosessuell programmering.

OOP og kontrollflyt

OOP ble utviklet for å øke kildekodeens gjenbrukbarhet og vedlikehold . Transparent representasjon av kontrollflyten hadde ingen prioritet og var ment å bli håndtert av en kompilator. Med den økende relevansen av parallell maskinvare og flertrådskoding , blir det viktigere å utvikle transparent kontrollflyt, noe som er vanskelig å oppnå med OOP.

Ansvars- vs. datadrevet design

Ansvarsdrevet design definerer klasser i form av en kontrakt, det vil si at en klasse skal defineres rundt et ansvar og informasjonen den deler. Dette står i kontrast av Wirfs-Brock og Wilkerson med datadrevet design , der klasser er definert rundt datastrukturer som må holdes. Forfatterne mener ansvarsdrevet design er å foretrekke.

SOLID og GRASP retningslinjer

SOLID er et minneord oppfunnet av Michael Feathers som står for og går inn for fem programmeringsmetoder:

GRASP (General Responsibility Assignment Software Patterns) er et annet sett med retningslinjer som Craig Larman tar til orde for .

Kritikk

OOP -paradigmet har blitt kritisert av en rekke årsaker, inkludert å ikke oppfylle de uttalte målene om gjenbruk og modularitet, og for å legge vekt på et aspekt av programvaredesign og modellering (data/objekter) på bekostning av andre viktige aspekter (beregning/algoritmer) .

Luca Cardelli har hevdet at OOP -koden er "iboende mindre effektiv" enn prosedyrekode, at OOP kan ta lengre tid å kompilere, og at OOP -språk har "ekstremt dårlige modularitetsegenskaper med hensyn til klasseutvidelse og modifikasjon", og har en tendens til å være ekstremt komplekse . Det siste punktet gjentas av Joe Armstrong , den viktigste oppfinneren av Erlang , som siteres for å si:

Problemet med objektorienterte språk er at de har alt dette implisitte miljøet de har med seg. Du ville ha en banan, men det du fikk var en gorilla som holdt bananen og hele jungelen.

En studie av Potok et al. har ikke vist noen vesentlig forskjell i produktivitet mellom OOP og prosessuelle tilnærminger.

Christopher J. Date uttalte at kritisk sammenligning av OOP med andre teknologier, spesielt relasjonelle, er vanskelig på grunn av mangel på en avtalt og streng definisjon av OOP; Imidlertid har Date og Darwen foreslått et teoretisk grunnlag for OOP som bruker OOP som et slags tilpassbart type system for å støtte RDBMS .

I en artikkel hevdet Lawrence Krubner at sammenlignet med andre språk (LISP -dialekter, funksjonelle språk, etc.) har OOP -språk ingen unike styrker og påfører en tung byrde av unødvendig kompleksitet.

Alexander Stepanov sammenligner objektorientering ugunstig med generisk programmering :

Jeg synes OOP er teknisk uforsvarlig. Den prøver å dekomponere verden når det gjelder grensesnitt som varierer på en enkelt type. For å håndtere de virkelige problemene trenger du multisorterte algebraer - familier av grensesnitt som spenner over flere typer. Jeg synes OOP er filosofisk uforsvarlig. Den hevder at alt er et objekt. Selv om det er sant, er det ikke veldig interessant - å si at alt er et objekt, sier ingenting i det hele tatt.

Paul Graham har antydet at OOPs popularitet i store selskaper skyldes "store (og ofte skiftende) grupper av middelmådige programmerere". I følge Graham forhindrer disiplinen som OOP pålegger enhver programmerer fra å "gjøre for mye skade".

Leo Brodie har foreslått en sammenheng mellom objekters frittstående natur og en tendens til å duplisere kode i strid med ikke gjenta deg selv -prinsippet om programvareutvikling.

Steve Yegge bemerket at, i motsetning til funksjonell programmering :

Objektorientert programmering setter substantivene først og fremst. Hvorfor ville du gå så langt for å sette en tale i en sokkel? Hvorfor skal en type konsept gå foran en annen? Det er ikke som om OOP plutselig har gjort verb mindre viktige i måten vi faktisk tenker på. Det er et merkelig skjevt perspektiv.

Rich Hickey , skaperen av Clojure , beskrev objektsystemer som altfor forenklede modeller av den virkelige verden. Han understreket manglende evne til OOP til å modellere tid riktig, noe som blir stadig mer problematisk etter hvert som programvaresystemer blir mer samtidige.

Eric S. Raymond , en Unix- programmerer og åpen kildekode- talsmann, har vært kritisk til påstander som presenterer objektorientert programmering som "One True Solution", og har skrevet at objektorienterte programmeringsspråk har en tendens til å oppmuntre til tykt lagrede programmer som ødelegge åpenhet. Raymond sammenligner denne ufordelaktig tilnærmingen tatt med Unix og programmeringsspråket C .

Rob Pike , en programmerer som er involvert i opprettelsen av UTF-8 og Go , har kalt objektorientert programmering "de romerske tallene for databehandling" og har sagt at OOP-språk ofte flytter fokus fra datastrukturer og algoritmer til typer . Videre siterer han en forekomst av en Java -professor hvis "idiomatiske" løsning på et problem var å lage seks nye klasser, i stedet for bare å bruke en oppslagstabell .

Formell semantikk

Se også: Formell semantikk i programmeringsspråk

Objekter er løpetidsenhetene i et objektorientert system. De kan representere en person, et sted, en bankkonto, en tabell med data eller ethvert element programmet må håndtere.

Det har vært flere forsøk på å formalisere begrepene som brukes i objektorientert programmering. Følgende konsepter og konstruksjoner har blitt brukt som tolkninger av OOP -konsepter:

Forsøk på å finne en konsensusdefinisjon eller teori bak objekter har ikke vist seg særlig vellykket (se imidlertid Abadi & Cardelli, A Theory of Objects for formelle definisjoner av mange OOP -konsepter og konstruksjoner), og divergerer ofte ofte. Noen definisjoner fokuserer for eksempel på mentale aktiviteter, og noen på programstrukturering. En av de enklere definisjonene er at OOP er handlingen om å bruke "kart" datastrukturer eller matriser som kan inneholde funksjoner og pekere til andre kart, alle med noe syntaktisk og avgjørende sukker på toppen. Arv kan utføres ved å klone kartene (noen ganger kalt "prototyping").

Se også

Systemer

Modelleringsspråk

Referanser

Videre lesning

Eksterne linker