Objektorienteret programmering - Object-oriented programming
Objektorienteret programmering ( OOP ) er et programmeringsparadigme baseret på begrebet " objekter ", som kan indeholde data og kode: data i form af felter (ofte kendt som attributter eller egenskaber ) og kode i form af procedurer (ofte kendt som metoder ).
Et træk ved objekter er, at et objekts egne procedurer kan få adgang til og ofte ændre datafelterne i sig selv (objekter har en forestilling om eller ). I OOP er computerprogrammer designet ved at gøre dem ud af objekter, der interagerer med hinanden. OOP-sprog er forskellige, men de mest populære er klassebaserede , hvilket betyder, at objekter er forekomster af klasser , som også bestemmer deres typer .
this
self
Mange af de mest udbredte programmeringssprog (såsom C ++, Java, Python, etc.) er multi-paradigme og de støtter objektorienteret programmering i større eller mindre grad, typisk i kombination med bydende nødvendigt , proceduremæssig programmering . Væsentlige objektorienterede sprog omfatter: 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
Terminologi, der påberåber sig "objekter" og "orienteret" i den moderne betydning af objektorienteret programmering, fik sit første udseende på MIT i slutningen af 1950'erne og begyndelsen af 1960'erne. I miljøet i den kunstige intelligensgruppe kunne "objekt" allerede i 1960 referere til identificerede genstande ( LISP -atomer) med egenskaber (attributter); Alan Kay citerede senere en detaljeret forståelse af LISP internals som en stærk indflydelse på hans tankegang i 1966.
Jeg tænkte på, at objekter lignede biologiske celler og/eller individuelle computere på et netværk, kun var i stand til at kommunikere med meddelelser (så meddelelser kom helt i begyndelsen - det tog et stykke tid at se, hvordan man foretager beskeder i et programmeringssprog effektivt nok til at være nyttig).
Alan Kay,
Et andet tidligt MIT -eksempel var Sketchpad skabt af Ivan Sutherland i 1960–1961; i ordlisten i den tekniske rapport fra 1963 baseret på sin afhandling om Sketchpad definerede Sutherland begreber om "objekt" og "forekomst" (med klassebegrebet dækket af "mester" eller "definition"), omend specialiseret til grafisk interaktion. En MIT ALGOL- version, AED-0, etablerede også en direkte forbindelse mellem datastrukturer ("plexer", på den dialekt) og procedurer, der præfigurerede det, der senere blev kaldt "meddelelser", "metoder" og "medlemsfunktioner".
I 1962 startede Kristen Nygaard et projekt for et simuleringssprog på det norske computercenter baseret på hans tidligere brug af Monte Carlo-simuleringen og hans arbejde med at konceptualisere virkelige systemer. Ole-Johan Dahl deltog formelt i projektet, og Simula programmeringssprog blev designet til at køre på Universal Automatic Computer (UNIVAC) 1107. Simula introducerede vigtige begreber, der i dag er en væsentlig del af objektorienteret programmering, såsom klasse og objekt , arv og dynamisk binding . Simula blev også designet til at tage hensyn til programmering og datasikkerhed . Af programmeringssikkerhedsmæssige årsager blev en detekteringsproces implementeret, så en sidste udvej skraldespilleren slettede ubrugte objekter i random-access memory (RAM) gennem referencetællinger . Men selvom ideen om dataobjekter allerede var blevet etableret i 1965, blev indkapsling af data gennem omfanget af variabler , f.eks. Private (-) og offentlige (+), ikke implementeret i Simula, fordi det ville have krævet adgangsprocedurerne også skjult.
I de tidlige stadier skulle Simula være en procedurepakke for programmeringssproget ALGOL 60. Undersøgte utilfredse med de begrænsninger, ALGOL havde pålagt, at udvikle Simula til et fuldgyldigt programmeringssprog, der brugte UNIVAC ALGOL 60-kompilatoren. Simula blev fremmet af Dahl og Nygaard i hele 1965 og 1966, hvilket førte til stigende brug af programmeringssproget i Sverige, Tyskland og Sovjetunionen . I 1968 blev sproget bredt tilgængeligt via Burroughs B5500-computere og blev senere også implementeret på URAL-16-computeren . I 1966 skrev Dahl og Nygaard en Simula -kompilator . De blev optaget af at omsætte Tony Hoares rekordklassekoncept , som var blevet implementeret i det friformede , engelsklignende generelle simuleringssprog SIMSCRIPT . De nøjedes med et generaliseret proceskoncept med rekordklasseegenskaber og et andet lag præfikser. Gennem præfiksering kan en proces referere til sin forgænger og have yderligere egenskaber. Simula introducerede således klasse- og underklassehierarkiet og muligheden for at generere objekter fra disse klasser.
En Simula 67 compiler blev lanceret til System/360 og System/370 IBM mainframe computere i 1972. I samme år blev en Simula 67 compiler gratis lanceret til de franske CII 10070 og CII Iris 80 mainframe computere . I 1974 havde sammenslutningen af Simula -brugere medlemmer i 23 forskellige lande. I begyndelsen af 1975 blev en Simula 67-kompilator frigivet gratis for DECsystem-10 mainframe-familien. I august samme år var DECsystem-10 Simula 67-kompilatoren blevet installeret på 28 steder, heraf 22 i Nordamerika. Det objektorienterede Simula-programmeringssprog blev hovedsageligt brugt af forskere, der var involveret i fysisk modellering , såsom modeller til at studere og forbedre skibenes bevægelse og deres indhold gennem lasthavne.
I 1970'erne blev den første version af Smalltalk programmeringssprog udviklet på Xerox PARC af Alan Kay , Dan Ingalls og Adele Goldberg . Smaltalk-72 inkluderede et programmeringsmiljø og blev dynamisk skrevet , og blev først fortolket , ikke kompileret . Smalltalk blev kendt for sin anvendelse af objektorientering på sprogniveau og dets grafiske udviklingsmiljø. Smalltalk gennemgik forskellige versioner, og interessen for sproget voksede. Mens Smalltalk var påvirket af de ideer, der blev introduceret i Simula 67, var det designet til at være et fuldt dynamisk system, hvor klasser kunne oprettes og ændres dynamisk.
I 1970'erne påvirkede Smalltalk Lisp-samfundet til at inkorporere objektbaserede teknikker, der blev introduceret til udviklere via Lisp-maskinen . Eksperimentering med forskellige udvidelser til Lisp (såsom LOOPS og Flavors, der introducerede flere arv og mixins ) førte til sidst til Common Lisp Object System , som integrerer funktionel programmering og objektorienteret programmering og tillader udvidelse via en Meta-objekt-protokol . I 1980'erne var der et par forsøg på at designe processorarkitekturer, der inkluderede hardware -understøttelse af objekter i hukommelsen, men disse lykkedes ikke. Eksempler omfatter Intel iAPX 432 og Linn Smart Rekursiv .
I 1981 redigerede Goldberg augustnummeret af Byte Magazine og introducerede Smalltalk og objektorienteret programmering til et bredere publikum. I 1986 arrangerede Association for Computing Machinery den første konference om objektorienteret programmering, systemer, sprog og applikationer (OOPSLA), som uventet deltog i 1.000 mennesker. I midten af 1980'erne blev Objective-C udviklet af Brad Cox , der havde brugt Smalltalk på ITT Inc. , og Bjarne Stroustrup , der havde brugt Simula til sin ph.d.-afhandling, gik til sidst med at skabe det objektorienterede C ++ . I 1985 producerede Bertrand Meyer også det første design af Eiffelsproget . Fokuseret på softwarekvalitet er Eiffel et rent objektorienteret programmeringssprog og en notation, der understøtter hele softwarens livscyklus. Meyer beskrev Eiffel softwareudviklingsmetoden, baseret på et lille antal nøgleidéer fra software engineering og datalogi, i objektorienteret softwarekonstruktion . Essentielt for kvalitetsfokus på Eiffel er Meyers pålidelighedsmekanisme, Design by Contract , som er en integreret del af både metoden og sproget.
I begyndelsen og midten af 1990'erne objektorienteret programmeringssprog udviklet som den dominerende programmering paradigme når programmeringssprog der understøtter de teknikker blev bredt tilgængelige. Disse omfattede Visual FoxPro 3.0, C ++ og Delphi . Dens dominans blev yderligere forstærket af den stigende popularitet af grafiske brugergrænseflader , der er stærkt afhængige af objektorienterede programmeringsteknikker. Et eksempel på et nært beslægtet dynamisk GUI-bibliotek og OOP-sprog findes i Cocoa- rammerne på Mac OS X , skrevet i Objective-C , en objektorienteret, dynamisk messaging-udvidelse til C baseret på Smalltalk. OOP-værktøjssæt forbedrede også populariteten af hændelsesdrevet programmering (selvom dette koncept ikke er begrænset til OOP).
På ETH Zürich havde Niklaus Wirth og hans kolleger også undersøgt emner som dataabstraktion og modulær programmering (selvom dette havde været almindeligt anvendt i 1960'erne eller tidligere). Modula-2 (1978) inkluderede begge dele, og deres efterfølgende design, Oberon , inkluderede en særpræget tilgang til objektorientering, klasser og sådan.
Objektorienterede funktioner er blevet tilføjet til mange tidligere eksisterende sprog, herunder Ada , BASIC , Fortran , Pascal og COBOL . Tilføjelse af disse funktioner til sprog, der ikke oprindeligt var designet til dem, førte ofte til problemer med kompatibilitet og vedligeholdelse af kode.
For nylig er der opstået en række sprog, der primært er objektorienterede, men som også er kompatible med proceduremetoder. To sådanne sprog er Python og Ruby . Sandsynligvis de mest kommercielt vigtige nylige objektorienterede sprog er Java , udviklet af Sun Microsystems , samt C# og Visual Basic.NET (VB.NET), begge designet til Microsofts .NET- platform. Hver af disse to rammer viser på sin egen måde fordelen ved at bruge OOP ved at skabe en abstraktion fra implementeringen. VB.NET og C# understøtter arv på tværs af sprog, så klasser, der er defineret på et sprog, kan underklasse klasser, der er defineret på det andet sprog.
Funktioner
Objektorienteret programmering bruger objekter, men ikke alle de tilknyttede teknikker og strukturer understøttes direkte på sprog, der hævder at understøtte OOP. Funktionerne nedenfor er almindelige blandt sprog, der anses for at være stærkt klasse- og objektorienterede (eller multi-paradigme med OOP-understøttelse), med nævnte bemærkelsesværdige undtagelser.
- Variabler, der kan gemme oplysninger formateret i et lille antal indbyggede datatyper som heltal og alfanumeriske tegn . Dette kan omfatte datastrukturer som strenge , lister og hashtabeller , der enten er indbygget eller skyldes kombination af variabler ved hjælp af hukommelsespegere .
- Procedurer - også kendt som funktioner, metoder, rutiner eller underrutiner - der tager input, genererer output og manipulerer data. Moderne sprog inkluderer strukturerede programmeringskonstruktioner som sløjfer og betingelser .
Modulær programmeringsstøtte giver mulighed for at gruppere procedurer i filer og moduler til organisatoriske formål. Moduler er navneopdelt, så identifikatorer i et modul vil ikke være i konflikt med en procedure eller variabel, der deler det samme navn i en anden fil eller et modul.
Objekter og klasser
Sprog, der understøtter objektorienteret programmering (OOP), bruger typisk arv til genbrug af kode og udvidelse i form af enten klasser eller prototyper . Dem, der bruger klasser, understøtter to hovedbegreber:
- Klasser - definitionerne for dataformatet og tilgængelige procedurer for en given type eller klasse af objekt; kan også indeholde data og procedurer (kendt som klassemetoder) selv, dvs. klasser indeholder datamedlemmer og medlemsfunktioner
- Objekter - forekomster af klasser
Objekter svarer undertiden til ting, der findes i den virkelige verden. For eksempel kan et grafikprogram have objekter som "cirkel", "firkant", "menu". Et online indkøbssystem kan have objekter såsom "indkøbskurv", "kunde" og "produkt". Nogle gange repræsenterer objekter mere abstrakte objekter, f.eks. Et objekt, der repræsenterer en åben fil, eller et objekt, der leverer tjenesten til at oversætte målinger fra amerikanske sædvanlige til metriske.
Objektorienteret programmering er mere end bare klasser og objekter; det er et helt programmeringsparadigme baseret på [ sic ] objekter (datastrukturer), der indeholder datafelter og metoder. Det er vigtigt at forstå dette; at bruge klasser til at organisere en masse ikke -relaterede metoder sammen er ikke objektorientering.
Junade Ali, Mastering PHP Design Patterns
Hvert objekt siges at være en forekomst af en bestemt klasse (for eksempel kan et objekt med sit navnefelt indstillet til "Mary" være en forekomst af klassemedarbejderen). Procedurer i objektorienteret programmering er kendt som metoder ; variabler er også kendt som felter , medlemmer, attributter eller egenskaber. Dette fører til følgende vilkår:
- Klassevariabler - tilhører klassen som helhed ; der er kun en kopi af hver enkelt
- Instansvariabler eller attributter - data, der tilhører individuelle objekter ; hvert objekt har sin egen kopi af hvert enkelt
- Medlemsvariabler - refererer til både klasse- og instansvariabler, der er defineret af en bestemt klasse
- Klassemetoder - tilhører klassen som helhed og har kun adgang til klassevariabler og input fra procedurekaldet
- Instansmetoder - tilhører individuelle objekter og har adgang til instansvariabler for det specifikke objekt, de kaldes til, input og klassevariabler
Objekter tilgås på lignende måde som variabler med kompleks intern struktur, og er på mange sprog effektivt pejlemærker , der fungerer som faktiske referencer til en enkelt forekomst af objektet i hukommelsen i en bunke eller stak. De giver et lag af abstraktion, der kan bruges til at adskille intern fra ekstern kode. Ekstern kode kan bruge et objekt ved at kalde en bestemt instansmetode med et bestemt sæt inputparametre, læse en forekomstvariabel eller skrive til en forekomstvariabel. Objekter oprettes ved at kalde en særlig type metode i klassen kendt som en konstruktør . Et program kan oprette mange forekomster af samme klasse, som det kører, og som fungerer uafhængigt. Dette er en nem måde at anvende de samme procedurer på forskellige datasæt.
Objektorienteret programmering, der bruger klasser, kaldes undertiden klassebaseret programmering , mens prototype-baseret programmering ikke typisk bruger klasser. Som et resultat bruges væsentligt anderledes, men analog terminologi til at definere begreberne objekt og forekomst .
På nogle sprog kan klasser og objekter sammensættes ved hjælp af andre begreber som træk og mixins .
Klassebaseret vs prototype-baseret
I klasse-baserede sprog de klasser er defineret på forhånd, og de objekter er instantieret baseret på klasserne. Hvis to genstande æble og appelsin instantieres fra klassen Frugt , er de i sig selv frugter, og det er garanteret, at du kan håndtere dem på samme måde; f.eks. kan en programmør forvente eksistensen af de samme attributter som farve eller sukkerindhold eller er_ripe .
I prototype-baserede sprog er objekterne de primære enheder. Der findes ikke engang klasser . Den prototype af et objekt er bare et andet objekt, som objektet er knyttet til. Hvert objekt har et prototype -link (og kun et). Nye objekter kan oprettes baseret på allerede eksisterende objekter valgt som deres prototype. Du kan kalde to forskellige genstande æble og appelsin for en frugt, hvis objektfrugten findes, og både æble og appelsin har frugt som deres prototype. Ideen med frugt klassen findes ikke eksplicit, men som ækvivalens klasse af objekterne deler den samme prototype. Attributter og fremgangsmåderne ifølge den prototypen er overdraget til alle objekter af ækvivalens klasse er defineret af denne prototype. Attributter og metoder, der ejes individuelt af objektet, må ikke deles med andre objekter af samme ækvivalensklasse; f.eks. kan attributten sugar_content uventet ikke findes i apple . Kun enkelt arv kan implementeres gennem prototypen.
Dynamisk afsendelse/beskedoverførsel
Det er objektets ansvar, ikke nogen ekstern kode, at vælge den procedurekode, der skal udføres som svar på et metodeopkald, typisk ved at slå metoden op ved kørselstidspunktet i en tabel, der er knyttet til objektet. Denne funktion er kendt som dynamisk afsendelse og adskiller et objekt fra en abstrakt datatype (eller modul), som har en fast (statisk) implementering af operationerne for alle instanser. Hvis opkaldsvariabiliteten er afhængig af mere end den enkelte type af objektet, som det kaldes på (dvs. mindst et andet parameterobjekt er involveret i metodevalget), taler man om flere forsendelser .
Et metodeopkald er også kendt som meddelelsesoverførsel . Det konceptualiseres som en besked (navnet på metoden og dens inputparametre), der sendes til objektet til afsendelse.
Indkapsling
Indkapsling er et objektorienteret programmeringskoncept, der binder de data og funktioner, der manipulerer dataene sammen, og som både beskytter mod udefra kommende forstyrrelser og misbrug. Datakapsling førte til det vigtige OOP -koncept for data skjul .
Hvis en klasse ikke tillader opkaldskode at få adgang til interne objektdata og kun tillader adgang via metoder, er dette en stærk form for abstraktion eller skjult information, kendt som indkapsling . Nogle sprog (f.eks. Java) lader klasser eksplicit håndhæve adgangsbegrænsninger, f.eks. Angiver interne data med private
søgeordet og angiver metoder beregnet til brug ved kode uden for klassen med public
søgeordet. Metoder kan også være udformet offentlige, private eller mellemliggende niveauer såsom protected
(som giver adgang fra samme klasse og dens underklasser, men ikke objekter af en anden klasse). På andre sprog (som Python) håndhæves dette kun ved konvention (f.eks. private
Kan metoder have navne, der starter med en understregning ). Indkapsling forhindrer ekstern kode i at være bekymret for den interne funktion af et objekt. Dette letter koderefaktorering , f.eks. Gør det muligt for forfatteren af klassen at ændre, hvordan objekter i den klasse repræsenterer deres data internt uden at ændre nogen ekstern kode (så længe "offentlige" metodeopkald fungerer på samme måde). Det opfordrer også programmører til at sætte al den kode, der vedrører et bestemt datasæt, i samme klasse, som organiserer den for let forståelse af andre programmører. Indkapsling er en teknik, der tilskynder til afkobling .
Sammensætning, arv og delegering
Objekter kan indeholde andre objekter i deres instansvariabler; dette er kendt som objektsammensætning . For eksempel kan et objekt i medarbejderklassen indeholde (enten direkte eller gennem en markør) et objekt i adresseklassen ud over sine egne instansvariabler som "fornavn" og "position". Objektsammensætning bruges til at repræsentere "har-a" -forhold: hver medarbejder har en adresse, så hvert medarbejderobjekt har adgang til et sted til at gemme et adresseobjekt (enten direkte indlejret i sig selv eller på et separat sted adresseret via en markør) .
Sprog, der understøtter klasser, understøtter næsten altid arv . Dette gør det muligt at arrangere klasser i et hierarki, der repræsenterer "er-en-type-af" relationer. F.eks. Kan medarbejderen i klassen arve fra klassepersonen. Alle de data og metoder, der er tilgængelige for forældreklassen, vises også i barneklassen med de samme navne. F.eks. Kan klasseperson definere variablerne "fornavn" og "efternavn" med metoden "make_full_name ()". Disse vil også være tilgængelige i klassen Medarbejder, hvilket kan tilføje variablerne "position" og "løn". Denne teknik giver mulighed for let genbrug af de samme procedurer og datadefinitioner, ud over at potentielt afspejle virkelige forhold på en intuitiv måde. Frem for at bruge databasetabeller og programmering af underrutiner bruger udvikleren objekter, som brugeren måske er mere fortrolig med: objekter fra deres applikationsdomæne.
Underklasser kan tilsidesætte de metoder, der er defineret af superklasser. Flere arv er tilladt på nogle sprog, selvom dette kan gøre løsning af tilsidesættelser kompliceret. Nogle sprog har særlig understøttelse af mixins , men på ethvert sprog med flere arv er en mixin simpelthen en klasse, der ikke repræsenterer en is-a-type-relation. Mixins bruges typisk til at tilføje de samme metoder til flere klasser. F.eks. Kan klasse UnicodeConversionMixin levere en metode unicode_to_ascii (), når den er inkluderet i klasse FileReader og klasse WebPageScraper, som ikke deler en fælles forælder.
Abstrakte klasser kan ikke instantieres til objekter; de eksisterer kun med det formål at arve til andre "konkrete" klasser, der kan instantieres. I Java kan final
søgeordet bruges til at forhindre en klasse i at blive underklassificeret.
Læren om sammensætning over arv går ind for implementering af has-a-forhold ved hjælp af sammensætning i stedet for arv. For eksempel kunne klassemedarbejder i stedet for at arve fra klasseperson give hvert medarbejderobjekt et internt personobjekt, som det derefter har mulighed for at skjule for ekstern kode, selvom klasseperson har mange offentlige attributter eller metoder. Nogle sprog, f.eks. Go , understøtter slet ikke arv.
" Åbent/lukket princip " går ind for, at klasser og funktioner "skal være åbne for udvidelse, men lukkede for ændringer".
Delegation er en anden sproglig funktion, der kan bruges som et alternativ til arv.
Polymorfisme
Subtyping - en form for polymorfisme - er, når opkaldskode kan være agnostisk om, hvilken klasse i det understøttede hierarki den opererer på - forældreklassen eller en af dens efterkommere. I mellemtiden kan det samme operationsnavn blandt objekter i et arvshierarki opføre sig anderledes.
For eksempel stammer objekter af typen Cirkel og firkant fra en fælles klasse kaldet Shape. Tegn -funktionen for hver formtype implementerer, hvad der er nødvendigt for at tegne sig selv, mens opkaldskoden kan forblive ligeglad med den særlige form, der tegnes.
Dette er en anden type abstraktion, der forenkler kode uden for klassehierarkiet og muliggør stærk adskillelse af bekymringer .
Åben rekursion
På sprog, der understøtter åben rekursion , kan objektmetoder kalde andre metoder på det samme objekt (inklusive dem selv), typisk ved hjælp af en særlig variabel eller et søgeord kaldet this
eller self
. Denne variabel er sent bundet ; det tillader en metode, der er defineret i en klasse, at påberåbe sig en anden metode, der defineres senere, i en eller anden underklasse deraf.
OOP sprog
Simula (1967) accepteres generelt som værende det første sprog med de primære træk ved et objektorienteret sprog. Det blev skabt til at lave simuleringsprogrammer , hvor det, der blev kaldt objekter, var den vigtigste informationsrepræsentation. Smalltalk (1972 til 1980) er et andet tidligt eksempel, og det, som meget af teorien om OOP blev udviklet med. Med hensyn til graden af objektorientering kan der skelnes mellem følgende:
- Sprog kaldet "rene" OO -sprog, fordi alt i dem behandles konsekvent som et objekt, fra primitiver som tegn og tegnsætning, helt op til hele klasser, prototyper, blokke, moduler osv. De blev designet specielt til at lette, selv håndhæve, OO -metoder. Eksempler: Ruby , Scala , Smalltalk , Eiffel , Emerald , JADE , Self , Raku .
- Sprog designet hovedsageligt til OO -programmering, men med nogle proceduremæssige elementer. Eksempler: Java , Python , C ++ , C# , Delphi / Object Pascal , VB.NET .
- Sprog, der historisk set er processprog , men er blevet udvidet med nogle OO -funktioner. Eksempler: PHP , Perl , Visual Basic (afledt af BASIC), MATLAB , COBOL 2002 , Fortran 2003 , ABAP , Ada 95 , Pascal .
- Sprog med de fleste funktioner i objekter (klasser, metoder, arv), men i en udpræget original form. Eksempler: Oberon (Oberon-1 eller Oberon-2).
- Sprog med abstrakt datatypestøtte, der kan bruges til at ligne OO-programmering, men uden alle funktioner i objektorientering. Dette omfatter objekt- baserede og prototype-baserede sprog. Eksempler: JavaScript , Lua , Modula-2 , CLU .
- Kamæleonsprog, der understøtter flere paradigmer, herunder OO. Tcl skiller sig ud blandt disse for TclOO, et hybridobjektsystem, der understøtter både prototype-baseret programmering og klassebaseret OO.
OOP på dynamiske sprog
I de senere år er objektorienteret programmering blevet særligt populær inden for dynamiske programmeringssprog . Python , PowerShell , Ruby og Groovy er dynamiske sprog bygget på OOP-principper, mens Perl og PHP har tilføjet objektorienterede funktioner siden Perl 5 og PHP 4 og ColdFusion siden version 6.
Den Document Object Model af HTML , XHTML , og XML -dokumenter på internettet har bindinger til den populære JavaScript / ECMAScript sprog. JavaScript er måske det mest kendte prototype-baserede programmeringssprog , der anvender kloning fra prototyper frem for at arve fra en klasse (kontrast til klassebaseret programmering ). Et andet scriptsprog, der tager denne tilgang, er Lua .
OOP i en netværksprotokol
De meddelelser, der flyder mellem computere for at anmode om tjenester i et klient-server-miljø, kan udformes som linearisering af objekter defineret af klasseobjekter, der er kendt af både klienten og serveren. For eksempel ville et enkelt lineariseret objekt bestå af et længdefelt, et kodepunkt, der identificerer klassen, og en dataværdi. Et mere komplekst eksempel ville være en kommando bestående af kommandoens længde og kodepunkt og værdier bestående af lineariserede objekter, der repræsenterer kommandoens parametre. Hver sådan kommando skal ledes af serveren til et objekt, hvis klasse (eller superklasse) genkender kommandoen og er i stand til at levere den ønskede service. Klienter og servere er bedst modelleret som komplekse objektorienterede strukturer. Distributed Data Management Architecture (DDM) fulgte denne tilgang og brugte klasseobjekter til at definere objekter på fire niveauer i et formelt hierarki:
- Felter, der definerer de dataværdier, der danner meddelelser, f.eks. Deres længde, kodepunkt og dataværdier.
- Objekter og samlinger af objekter, der ligner det, der ville findes i et Smalltalk -program til meddelelser og parametre.
- Administratorer, der ligner IBM i Objects , f.eks. Et bibliotek til filer og filer, der består af metadata og poster. Ledere giver konceptuelt hukommelse og behandlingsressourcer til deres indeholdte objekter.
- En klient eller server, der består af alle de ledere, der er nødvendige for at implementere et fuldt behandlingsmiljø, der understøtter aspekter som bibliotekstjenester, sikkerhed og samtidighedskontrol.
Den oprindelige version af DDM definerede distribuerede filtjenester. Det blev senere udvidet til at være grundlaget for Distributed Relational Database Architecture (DRDA).
Design mønstre
Udfordringer ved objektorienteret design løses af flere tilgange. Mest almindeligt er kendt som designmønstrene kodificeret af Gamma et al. . Mere generelt kan udtrykket " designmønstre " bruges til at henvise til ethvert generelt, gentageligt, løsningsmønster til et almindeligt forekommende problem i softwaredesign. Nogle af disse almindeligt forekommende problemer har implikationer og løsninger især på objektorienteret udvikling.
Arv og adfærdsmæssig undertyping
Det er intuitivt at antage, at arv skaber et semantisk " er et " forhold, og dermed at udlede, at objekter, der instantieres fra underklasser, altid sikkert kan bruges i stedet for dem, der instantieres fra superklassen. Denne intuition er desværre falsk i de fleste OOP -sprog, især i alle dem, der tillader objektive objekter. Undertype polymorfisme som håndhævet af typechecken på OOP -sprog (med foranderlige objekter) kan ikke garantere adfærdsmæssig undertypning i nogen sammenhæng. Adfærdsmæssig underskrivning er generelt ubeslutsom, så den kan ikke implementeres af et program (kompilator). Klasse- eller objekthierarkier skal være omhyggeligt designet under hensyntagen til mulige forkerte anvendelser, der ikke kan detekteres syntaktisk. Dette problem er kendt som Liskov -substitutionsprincippet .
Gang of Four designmønstre
Design Patterns: Elements of Reusable Object-Oriented Software er en indflydelsesrig bog udgivet i 1994 af Erich Gamma , Richard Helm , Ralph Johnson og John Vlissides , ofte omtalt humoristisk som "Gang of Four". Sammen med at undersøge mulighederne og faldgruberne ved objektorienteret programmering beskriver den 23 almindelige programmeringsproblemer og mønstre til at løse dem. Fra april 2007 var bogen i sin 36. udgave.
Bogen beskriver følgende mønstre:
- Oprettelsesmønstre (5): Fabriksmetodemønster , Abstrakt fabriksmønster , Singleton -mønster , Bygningsmønster , Prototypemønster
- Strukturelle mønstre (7): Adaptermønster , Bromønster , Kompositmønster , Dekoratormønster , Facademønster , Fluevægtsmønster , Proxy -mønster
- Adfærdsmønstre (11): Chain-of-ansvar mønster , Command mønster , Tolk mønster , Iterator mønster , Mediator mønster , Memento mønster , Observer mønster , State mønster , Strategi mønster , skabelon metode mønster , mønster Visitor
Objektorientering og databaser
Både objektorienteret programmering og relationelle databasesystemer (RDBMS'er) er ekstremt almindelige i software i dag. Da relationsdatabaser ikke gemmer objekter direkte (selvom nogle RDBMS'er har objektorienterede funktioner til at tilnærme dette), er der et generelt behov for at bygge bro mellem de to verdener. Problemet med at bygge bro mellem objektorienterede programmeringsadgange og datamønstre med relationsdatabaser er kendt som objektrelationel impedansfejl . Der er en række tilgange til at håndtere dette problem, men ingen generel løsning uden ulemper. En af de mest almindelige tilgange er objektrelationskortlægning , som findes på IDE- sprog som Visual FoxPro og biblioteker som Java Data Objects og Ruby on Rails 'ActiveRecord.
Der er også objektdatabaser, der kan bruges til at erstatte RDBMS'er, men disse har ikke været så teknisk og kommercielt vellykkede som RDBMS'er.
Virkelig modellering og relationer
OOP kan bruges til at forbinde virkelige objekter og processer med digitale modstykker. Imidlertid er ikke alle enige om, at OOP letter direkte kortlægning i den virkelige verden (se afsnittet Kritik ), eller at kortlægning i den virkelige verden endda er et værdigt mål; Bertrand Meyer argumenterer i Objektorienteret Softwarekonstruktion, at et program ikke er en verdensmodel, men en model for en del af verden; "Virkeligheden er en fætter fjernet to gange". Samtidig er nogle hovedbegrænsninger ved OOP blevet noteret. For eksempel er cirkel-ellipseproblemet svært at håndtere ved hjælp af OOP's koncept om arv .
Imidlertid sagde Niklaus Wirth (der populariserede det ordsprog, der nu er kendt som Wirths lov : "Software bliver langsommere hurtigere, end hardware bliver hurtigere") om OOP i sit papir, "Gode ideer gennem glas", "Dette paradigme afspejler tæt strukturen af systemer 'i den virkelige verden', og det er derfor velegnet til at modellere komplekse systemer med kompleks adfærd "(kontrast KISS -princip ).
Steve Yegge og andre bemærkede, at naturlige sprog mangler OOP -tilgang til strengt at prioritere ting (objekter/ navneord ) før handlinger (metoder/ verber ). Dette problem kan få OOP til at lide mere indviklede løsninger end procedureprogrammering.
OOP og kontrolflow
OOP blev udviklet for at øge kildekodens genanvendelighed og vedligeholdelse . Gennemsigtig repræsentation af kontrolflowet havde ingen prioritet og var beregnet til at blive håndteret af en kompilator. Med den stigende relevans af parallel hardware og multithreaded kodning bliver udviklingen af transparent kontrolflow vigtigere, noget svært at opnå med OOP.
Ansvars- vs. datadrevet design
Ansvarsdrevet design definerer klasser i form af en kontrakt, det vil sige en klasse skal defineres omkring et ansvar og de oplysninger, den deler. Dette står i kontrast af Wirfs-Brock og Wilkerson med datadrevet design , hvor klasser defineres omkring de datastrukturer, der skal holdes. Forfatterne mener, at ansvarligt drevet design er at foretrække.
SOLID og GRASP retningslinjer
SOLID er en hukommelsestegn opfundet af Michael Feathers, der står for og går ind for fem programmeringspraksisser:
- Enkeltansvarsprincip
- Åbent/lukket princip
- Liskov substitutionsprincip
- Grænsefladesegregeringsprincip
- Afhængighedsinversionsprincip
GRASP (General Responsibility Assignment Software Patterns) er et andet sæt retningslinjer, som Craig Larman går ind for .
Kritik
OOP -paradigmet er blevet kritiseret af en række årsager, herunder ikke at opfylde sine erklærede mål om genbrug og modularitet og for at understrege et aspekt af softwaredesign og modellering (data/objekter) på bekostning af andre vigtige aspekter (beregning/algoritmer) .
Luca Cardelli har hævdet, at OOP -koden er "iboende mindre effektiv" end procedurekoden, at OOP kan tage længere tid at kompilere, og at OOP -sprog har "ekstremt dårlige modularitetsegenskaber med hensyn til klasseudvidelse og ændring" og har en tendens til at være ekstremt komplekse . Det sidste punkt gentages af Joe Armstrong , den vigtigste opfinder af Erlang , der citeres for at sige:
Problemet med objektorienterede sprog er, at de har alt dette implicitte miljø, de har med sig. Du ville have en banan, men hvad du fik var en gorilla, der holdt bananen og hele junglen.
En undersøgelse af Potok et al. har ikke vist nogen signifikant forskel i produktivitet mellem OOP og proceduremetoder.
Christopher J. Date udtalte, at kritisk sammenligning af OOP med andre teknologier, især relationel, er vanskelig på grund af mangel på en aftalt og streng definition af OOP; dog har Date og Darwen foreslået et teoretisk fundament om OOP, der bruger OOP som en slags tilpasset type system til at understøtte RDBMS .
I en artikel hævdede Lawrence Krubner, at i forhold til andre sprog (LISP -dialekter, funktionelle sprog osv.) Har OOP -sprog ingen unikke styrker og påfører en tung byrde af unødvendig kompleksitet.
Alexander Stepanov sammenligner objektorientering ugunstigt med generisk programmering :
Jeg finder OOP teknisk uforsvarlig. Det forsøger at nedbryde verden i form af grænseflader, der varierer på en enkelt type. For at håndtere de virkelige problemer har du brug for multisorterede algebraer - familier af grænseflader, der spænder over flere typer. Jeg finder OOP filosofisk usund. Det hævder, at alt er et objekt. Selvom det er sandt, er det ikke særlig interessant - at sige, at alt er et objekt, siger slet ingenting.
Paul Graham har antydet, at OOPs popularitet inden for store virksomheder skyldes "store (og ofte skiftende) grupper af middelmådige programmører". Ifølge Graham forhindrer disciplinen fra OOP enhver programmerer i at "gøre for meget skade".
Leo Brodie har foreslået en forbindelse mellem objekters selvstændige karakter og en tendens til at kopiere kode i strid med princippet om ikke at gentage dig selv om softwareudvikling.
Steve Yegge bemærkede, at i modsætning til funktionel programmering :
Objektorienteret programmering sætter substantiverne først og fremmest. Hvorfor ville du gå så langt for at sætte en del af talen på en piedestal? Hvorfor skal en slags koncept have forrang frem for en anden? Det er ikke som om, at OOP pludselig har gjort verber mindre vigtige i den måde, vi faktisk tænker på. Det er et underligt skævt perspektiv.
Rich Hickey , skaberen af Clojure , beskrev objektsystemer som alt for simple modeller af den virkelige verden. Han understregede OOPs manglende evne til at modellere tiden korrekt, hvilket bliver stadig mere problematisk i takt med at softwaresystemer bliver mere samtidige.
Eric S. Raymond , en Unix- programmør og advokat med open source-software , har været kritisk over for påstande, der præsenterer objektorienteret programmering som "One True Solution", og har skrevet, at objektorienterede programmeringssprog har en tendens til at tilskynde til tykt lagede programmer, der ødelægge gennemsigtighed. Raymond sammenligner dette negativt til tilgangen med Unix og sproget C programmering .
Rob Pike , en programmerer, der er involveret i oprettelsen af UTF-8 og Go , har kaldt objektorienteret programmering " romertallet for computing" og har sagt, at OOP-sprog ofte flytter fokus fra datastrukturer og algoritmer til typer . Desuden citerer han en instans af en Java -professor, hvis "idiomatiske" løsning på et problem var at oprette seks nye klasser, snarere end blot at bruge en opslagstabel .
Formel semantik
Objekter er løbetidsenhederne i et objektorienteret system. De kan repræsentere en person, et sted, en bankkonto, en datatabel eller ethvert element, som programmet skal håndtere.
Der har været flere forsøg på at formalisere de begreber, der bruges i objektorienteret programmering. Følgende begreber og konstruktioner er blevet brugt som fortolkninger af OOP -begreber:
- co algebraiske datatyper
- abstrakte datatyper (som har eksistentielle typer ) tillader definition af moduler, men disse understøtter ikke dynamisk afsendelse
- rekursive typer
- indkapslet tilstand
- arv
- poster er grundlag for at forstå objekter, hvis funktionslitteraler kan gemmes i felter (som i funktionelle programmeringssprog), men de faktiske beregninger skal være betydeligt mere komplekse for at inkorporere væsentlige funktioner i OOP. Flere udvidelser af System F <: der omhandler mutable objekter er blevet undersøgt; disse tillader både undertype polymorfisme og parametrisk polymorfisme (generiske)
Forsøg på at finde en konsensusdefinition eller teori bag objekter har ikke vist sig særlig vellykket (se imidlertid Abadi & Cardelli, A Theory of Objects for formelle definitioner af mange OOP -begreber og konstruktioner), og afviger ofte meget. For eksempel fokuserer nogle definitioner på mentale aktiviteter, og nogle på programstrukturering. En af de enklere definitioner er, at OOP er handlingen med at bruge "kort" datastrukturer eller arrays, der kan indeholde funktioner og tips til andre kort, alle med noget syntaktisk og scoping sukker på toppen. Arv kan udføres ved at klone kortene (undertiden kaldet "prototyping").
Se også
- Sammenligning af programmeringssprog (objektorienteret programmering)
- Sammenligning af programmeringsparadigmer
- Komponentbaseret software engineering
- Design efter kontrakt
- Objektforening
- Objektdatabase
- Objektmodelreference
- Objektmodelleringssprog
- Objektorienteret analyse og design
- Objekt-relationel impedansfejl (og Det tredje manifest )
- Objekt-relationel kortlægning
Systemer
- CADES
- Common Object Request Broker Architecture (CORBA)
- Distribueret komponentobjektmodel
- Distribueret datahåndteringsarkitektur
- Jeroo
Modelleringssprog
Referencer
Yderligere læsning
- Abadi, Martin ; Luca Cardelli (1998). En teori om objekter . Springer Verlag . ISBN 978-0-387-94775-4.
- Abelson, Harold ; Gerald Jay Sussman (1997). Struktur og fortolkning af computerprogrammer . MIT Tryk . ISBN 978-0-262-01153-2.
- Armstrong, Deborah J. (februar 2006). "Quarks of Object-Oriented Development". Kommunikation af ACM . 49 (2): 123–128. doi : 10.1145/1113034.1113040 . ISSN 0001-0782 . S2CID 11485502 .
- Booch, Grady (1997). Objektorienteret analyse og design med applikationer . Addison-Wesley . ISBN 978-0-8053-5340-2.
- Eeles, Peter; Oliver Sims (1998). Bygger forretningsobjekter . John Wiley & Sons . ISBN 978-0-471-19176-6.
- Gamma, Erich ; Richard Helm ; Ralph Johnson ; John Vlissides (1995). Designmønstre: Elementer af genanvendelig objektorienteret software . Addison-Wesley. Bibcode : 1995dper.book ..... G . ISBN 978-0-201-63361-0.
- Harmon, Paul ; William Morrissey (1996). Object Technology Casebook-Lektioner fra prisvindende forretningsprogrammer . John Wiley & Sons. ISBN 978-0-471-14717-6.
- Jacobson, Ivar (1992). Objektorienteret softwareteknik: En use-case-driven tilgang . Addison-Wesley. Bibcode : 1992oose.book ..... J . ISBN 978-0-201-54435-0.
- Kay, Alan . Smalltalks tidlige historie . Arkiveret fra originalen den 4. april 2005 . Hentet 18. april 2005 .
- Meyer, Bertrand (1997). Objektorienteret softwarekonstruktion . Prentice Hall . ISBN 978-0-13-629155-8.
- Pecinovsky, Rudolf (2013). OOP - Lær objektorienteret tænkning og programmering . Bruckner forlag. ISBN 978-80-904661-8-0.
- Rumbaugh, James ; Michael Blaha; William Premerlani; Frederick Eddy; William Lorensen (1991). Objektorienteret modellering og design . Prentice Hall. ISBN 978-0-13-629841-0.
- Schach, Stephen (2006). Objektorienteret og klassisk softwareudvikling, syvende udgave . McGraw-Hill . ISBN 978-0-07-319126-3.
- Schreiner, Axel-Tobias (1993). Objektorienteret programmering med ANSI-C . Hanser. HDL : 1850/8544 . ISBN 978-3-446-17426-9.
- Taylor, David A. (1992). Objektorienterede informationssystemer-Planlægning og implementering . John Wiley & Sons. ISBN 978-0-471-54364-0.
- Weisfeld, Matt (2009). Den objektorienterede tankeproces, tredje udgave . Addison-Wesley . ISBN 978-0-672-33016-2.
- West, David (2004). Object Thinking (udviklerreference) . Microsoft Press . ISBN 978-0-7356-1965-4.