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 . thisself

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

UML -notation for en klasse. Denne Button -klasse har variabler for data og funktioner . Gennem arv kan der oprettes en underklasse som en delmængde af Button -klassen. Objekter er forekomster af en klasse.

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.

Den TIOBE programmeringssprog popularitet indeks graf fra 2002 til 2018. I 2000'erne den objektorienterede Java (blå) og den proceduremæssige C (sort) konkurrerede om den øverste position.

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).

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.

Delt med sprog uden for OOP

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 privatesøgeordet og angiver metoder beregnet til brug ved kode uden for klassen med publicsø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. privateKan 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 finalsø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 thiseller 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:

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:

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:

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:

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å

Systemer

Modelleringssprog

Referencer

Yderligere læsning

eksterne links