Object georiënteerd programmeren

Object-georiënteerd programmeren (OOP) is een programmeertaal paradigma gebaseerd op het concept van de “objecten”, die zijn datastructuren die bevatten gegevens, in de vorm van velden, vaak bekend als attributen, en de code, in de vorm van procedures, vaak bekende als werkwijzen. Een onderscheidend kenmerk van de objecten is die procedures een object toegang vaak de datavelden van het voorwerp waarmee ze zijn verbonden (voorwerpen een begrip “wijzigen deze” of “eigen”). In OO programmeren, zijn computerprogramma’s ontworpen door hen uit voorwerpen die interageren met elkaar. [1] [2] Er is aanzienlijke diversiteit in object-georiënteerd programmeren, maar de meeste populaire talen zijn klasse basis, wat betekent dat de voorwerpen zijn gevallen van klassen, die doorgaans ook bepaalt hun soort.

Veel van de meest gebruikte programmeertalen meerdere paradigma programmeertalen die objectgeoriënteerd programmeren in meer of mindere mate te ondersteunen, meestal in combinatie met imperatief, procedureel programmeren. Significante objectgeoriënteerde talen zijn Python, C ++, Objective-C, Smalltalk, Delphi, Java, Swift, C #, Perl, Ruby en PHP.

Inhoud

  • 1 Kenmerken
    • 1.1 Gedeeld met non-OOP voorganger talen
    • 1.2 Objecten en klassen
    • 1.3 Dynamic verzending / bericht doorgeven
    • 1.4 Inkapseling
    • 1.5 Samenstelling, erfenis, en de delegatie
    • 1.6 Polymorfisme
    • 1.7 Open recursie
  • Geschiedenis 2
  • 3 OOP talen
    • 3.1 OOP in dynamische talen
    • 3.2 OOP in een netwerkprotocol
  • 4 Design Patterns
    • 4.1 Inheritance en gedragsproblemen subtypering
    • 4.2 Bende van Vier design patterns
    • 4.3 Object-oriëntatie en databases
    • 4.4 Real-world modellering en relaties
    • 4.5 OOP en control flow
    • 4.6 verantwoordelijkheid- vs. data-driven design
    • 4.7 SOLID en GRASP richtlijnen
  • 5 Kritiek
  • 6 Formele semantiek
  • 7 Zie ook
    • 7.1 Systemen
    • 7.2 Modeling talen
  • 8 Verwijzingen
  • 9 Verder lezen
  • 10 Externe links

Kenmerken

Objectgeoriënteerde programmeertaal per definitie gebruikt objecten, maar niet alle geassocieerde technieken en structuren direct ondersteund talen die beweren OOP ondersteunen. De onderstaande functies zijn echter vaak tussen talen beschouwd sterk klasse en object-georiënteerde (of multi-paradigma met OOP-ondersteuning), met de genoemde uitzonderingen. [3] [4] [5] [6]

Zie ook: Vergelijking van programmeertalen (object-georiënteerd programmeren) en de Lijst van de programmering termen objectgeoriënteerde

Gedeeld met niet-OOP voorganger talen

Objectgeoriënteerde programmeertalen delen meestal low-level functies met een hoog niveau procedurele programmeertaal talen (die voor het eerst werden uitgevonden). De fundamentele instrumenten die kunnen worden gebruikt om een programma te construeren zijn:

  • Variabelen die informatie geformatteerd in een klein aantal ingebouwde in te slaan data types zoals integers en alfanumerieke tekens. Dit kan onder meer data structuren zoals strings, lijsten en hash tabellen die ofwel worden ingebouwd of het gevolg zijn van een combinatie van variabelen met behulp van het geheugen pointers
  • Procedures – ook wel bekend als functies, methoden, routines, of subroutines – die ingang te nemen, het genereren van output, en gegevens te manipuleren. Moderne talen zijn gestructureerd programmeren constructies zoals lussen en voorwaardelijke.

Modulair programmeren ondersteuning biedt de mogelijkheid om procedures groep in bestanden en modules voor organisatorische doeleinden. Modules naamruimten dus code in één module niet per ongeluk zal worden verward met dezelfde procedure of variabele naam in een ander bestand of module.

Objecten en klassen

Talen die object-georiënteerd programmeren ondersteuning gebruiken meestal erfenis voor het hergebruik van code en uitbreidbaarheid in de vorm van een van beide klassen of prototypes. Degenen die klassen ondersteunen twee belangrijke concepten:

  • Objecten – structuren die zowel data en procedures bevatten
  • Klassen – definities voor de data-formaat en beschikbare procedures voor een bepaald type of klasse van het object; kan ook gegevens en procedures (bekend als klasse methoden) zelf bevatten

Voorwerpen soms overeen dingen in de werkelijke wereld. Bijvoorbeeld kan een grafisch programma voorwerpen zoals “cirkel” “vierkant” moeten “menu.” Een online shopping-systeem kan objecten zoals “winkelwagen”, “klant” en “product.” [7] Soms voorwerpen vertegenwoordigen meer abstracte entiteiten, als een object dat een open bestand staat, of een voorwerp waarvan de dienst van geeft het vertalen van de metingen van de VS gebruikelijke naar metrisch.

Elk object wordt gezegd dat het een te instantie van een bepaalde klasse (bijvoorbeeld een object met de naam van het veld ingesteld op “Maria” zou een instantie van de klasse werknemer). Procedures in object georiënteerd programmeren zijn bekend als methoden; variabelen zijn ook bekend als velden, leden, attributen of eigenschappen. Dit leidt tot de volgende voorwaarden:

  • Klasse variabelen – behoren tot de klasse als geheel; er slechts één kopie van elk
  • Zo variabelen of attributen – gegevens die behoort tot afzonderlijke objecten; ieder object heeft zijn eigen exemplaar van elk
  • Variabelen lid – verwijst naar zowel de klasse en instantie variabelen die zijn gedefinieerd door een bepaalde klasse
  • Methoden van de klasse – behoren tot de klasse als geheel en hebben alleen toegang tot de klasse variabelen en input van de procedure call
  • Bijvoorbeeld methodes – behoren tot individuele objecten, en hebben toegang tot bijvoorbeeld variabelen voor het specifieke doel ze worden aangesproken, ingangen, en klasse variabelen

Objecten worden benaderd enigszins als variabelen complexe interne structuur, en in vele talen effectief pointers, die als actuele verwijzingen naar een enkel exemplaar van het voorwerp in het geheugen binnen een hoop of stapel. Ze bieden een laag van abstractie die kunnen worden gebruikt om gescheiden interne externe code. Externe code kan een object gebruiken door te bellen naar een specifiek geval methode met een bepaalde set van de input parameters, las een instantie variabele, of schrijven naar een instantie variabele. Objecten worden gemaakt door het bellen van een speciaal type methode in de klasse bekend als een constructor. Een programma kan een groot aantal exemplaren van dezelfde klasse te maken als het loopt, die onafhankelijk van elkaar opereren. Dit is een gemakkelijke manier om dezelfde procedures te worden gebruikt op verschillende sets van gegevens.

Object-georiënteerd programmeren dat klassen gebruikt wordt soms klasse gebaseerde programmering, terwijl-prototype op basis van de programmering niet gebruiken meestal klassen. Hierdoor wordt aanzienlijk verschilt toch analoog terminologie de begrippen object en heeft omschreven.

In sommige talen klassen en objecten kan worden samengesteld met behulp van andere concepten, zoals eigenschappen en mixins.

Dynamische verzending / doorgeven van berichten

Per definitie is het de verantwoordelijkheid van het object, niet de externe code, om ‘on-demand’ de procedurele code kan worden uitgevoerd / uitvoert in reactie op een aanroep van de methode, meestal door het opzoeken van de methode tijdens runtime in een tabel geassocieerd het object. Deze functie staat bekend als dynamische verzending, en onderscheidt een object uit een abstract datatype (of module), die een vast (statisch) uitvoering van de verrichtingen van alle gevallen heeft. Als er meerdere methoden die kunnen worden uitgevoerd voor een gegeven naam (sommige taalsteun nodig), is bekend als meervoudige verzending.

Een aanroep van de methode is ook bekend als boodschap doorgeven. Het wordt opgevat als een bericht (de naam van de methode en de invoerparameters) wordt doorgegeven aan het object voor verzending.

Inkapseling

Als een klasse verbiedt bellen code toegang tot interne objectgegevens en krachten toegang via methoden alleen, dit is een sterke vorm van abstractie of informatie ondergedoken bekend als inkapseling. Sommige talen (Java, bijvoorbeeld) laten klassen af te dwingen toegangsbeperkingen expliciet, bijvoorbeeld duiden interne gegevens met de private zoekwoord en het aanwijzen van methoden die bestemd zijn voor gebruik door de code buiten de klas met het public trefwoord. Methoden kunnen ook worden ontworpen publieke, private of tussenliggende niveaus zoals protected (die meestal biedt toegang van andere voorwerpen van dezelfde klasse, maar geen objecten van een andere klasse). In andere talen (zoals Python) dit wordt afgedwongen alleen volgens afspraak (bijvoorbeeld het benoemen van “private” methoden die beginnen met een underscore). Dit is nuttig omdat het voorkomt dat de externe code die betrekking op de interne werking van een object. Dit vergemakkelijkt code refactoring, bijvoorbeeld waardoor de auteur van de klasse te veranderen hoe objecten van die klasse vertegenwoordigen hun gegevens intern zonder dat externe code (zolang “openbare” methode oproepen werken op dezelfde manier). Het stimuleert ook de programmeurs om de code die betrekking heeft op een bepaalde set van gegevens in dezelfde klasse, die zij organiseert voor het begrip ervan door andere programmeurs te zetten. Encapsulation wordt vaak gebruikt als een techniek voor het stimuleren ontkoppeling.

Samenstelling, overerving, en delegatie

Objecten kunnen andere objecten in hun geval variabelen bevatten; dit staat bekend als de samenstelling object. Bijvoorbeeld, kan een object in de Employee klasse (punt) een object in de klasse Adres, bevatten naast haar eigen instantie variabelen zoals “voornaam” en “stand”. Object samenstelling wordt gebruikt om “heeft-een” relaties: iedere werknemer heeft een adres, zodat elke werknemer object heeft een plek om een Address object op te slaan.

Talen die klassen ondersteunen vrijwel altijd steunen erfenis. Dit maakt klassen worden aangebracht in een hiërarchie die aangeeft “is het een type van” relaties. Bijvoorbeeld, klasse Employee erven van de klasse persoon. Alle gegevens en methoden beschikbaar om de bovenliggende klasse ook in het kind klasse met dezelfde naam. Bijvoorbeeld, de klasse Person variabelen ‘voornaam’ en ‘achternaam’ definiëren met methode “make_full_name ()”. Deze zullen ook beschikbaar zijn in de klas werknemer, die de variabelen “positie” en “loon” zou kunnen toevoegen. Deze techniek maakt een eenvoudige hergebruik van dezelfde procedures en gegevensdefinities, naast potentieel spiegelen echte relaties op een intuïtieve manier. Deze klassen en subklassen overeen met sets en subsets in wiskundige logica. In plaats van gebruik te maken van de database tabellen en het programmeren van subroutines, de ontwikkelaar maakt gebruik van objecten kan de gebruiker meer vertrouwd zijn met:. Voorwerpen uit hun toepassingsdomein [8]

Subklassen kan de door superklassen methoden overschrijven. Meervoudige overerving is toegestaan in sommige talen, maar dit oplossen overschrijft ingewikkeld kan maken. Sommige talen hebben speciale ondersteuning voor mixins, maar in elke taal met multiple inheritance, een mixin is gewoon een klasse die niet vertegenwoordigen een is-een-soort-relatie. Mixins worden gewoonlijk gebruikt om dezelfde methoden toe om meerdere klassen. Bijvoorbeeld, klasse UnicodeConversionMixin een methode unicode_to_ascii bieden () als begrepen in klasse FileReader en klasse WebPageScraper, die niet delen een gemeenschappelijke ouder.

Abstracte klassen kunnen niet worden geconcretiseerd in objecten; zij bestaan uitsluitend ten behoeve van overerving in andere “beton” klassen die kunnen worden geïnstantieerd. In Java, de final kan trefwoord gebruikt worden om te voorkomen dat een klasse van wordt subklasse.

De leer van de samenstelling over erfenis voorstanders uitvoering is-een-soort-van de relaties met de samenstelling in plaats van overerving. Bijvoorbeeld, in plaats van de erven van de klasse Person, klasse Werknemer kan elke werknemer object een interne persoon object, wat het heeft dan de mogelijkheid om te verbergen voor externe code, zelfs als klasse persoon heeft vele openbare attributen of methoden te geven. Sommige talen, zoals Go ondersteunen niet erfenis helemaal.

De “open / gesloten principe” bepleit dat klassen en functies “moet openstaan voor de uitbreiding zijn, maar gesloten voor wijziging”.

Delegatie een andere taal eigenschap die kan worden gebruikt als alternatief overerving.

Polymorfisme

Subtypering, een vorm van polymorfisme is bij het oproepen code agnostische vraag of een object behoort tot een ouder klasse of één van zijn nakomelingen zijn. Bijvoorbeeld, een functie “make_full_name ()” een beroep doen op een voorwerp, die zal werken of het voorwerp is van de klasse Person of klasse Werknemer. Dit is een ander type abstractieniveau welke code externe vereenvoudigt de klasse hiërarchie en maakt sterke scheiding zorgen.

Open recursie

In talen die ondersteuning geopend recursie, kunnen methoden object andere methoden op hetzelfde object (inclusief zichzelf) noemen, meestal met behulp van een speciale variabele of trefwoord noemde this of self Deze variabele is laat-gebonden; het stelt een werkwijze bepaald in een klasse andere methode die later wordt gedefinieerd, in sommige subklasse daarvan roepen.

Geschiedenis

Terminologie inroepen “objecten” en “gerichte” in de moderne zin van object-georiënteerd programmeren maakte zijn eerste verschijning op het MIT in de late jaren 1950 en begin 1960. In de omgeving van de kunstmatige intelligentie groep, zo vroeg als 1960, “object” zou kunnen verwijzen naar die items (LISP atomen) met eigenschappen (attributen); [9] [10] Alan Kay werd later tot een gedetailleerd inzicht in LISP internals citeren als een sterke invloed op zijn denken in 1966. [11] Een ander vroeg MIT voorbeeld werd Schetsblok gemaakt door Ivan Sutherland in 1960-1961; in de woordenlijst van de 1963 technisch rapport gebaseerd op zijn proefschrift over Sketchpad, Sutherland gedefinieerde begrippen “object” en “instantie” (met de class-concept onder de “master” of “definitie”), zij het gespecialiseerde grafische interactie. [12 ] Ook een MIT ALGOL versie, AED-0, is een directe link tussen de data structuren (“samenstellingen”, in die dialect) en procedures, voorbode wat werden later aangeduid als “berichten”, “methode”, en “lid functies”. [13] [14]

De formele programmering concept van de objecten werd in de jaren 1960 geïntroduceerd in Simula 67, een grote herziening van Simula I, een programmeertaal ontworpen voor discrete event simulatie, gecreëerd door Ole-Johan Dahl en Kristen Nygaard van de Noorse Computing Center in Oslo. 15 [ ] Simula 67 werd beïnvloed door SIMSCRIPT en CAR “Tony” Hoare’s voorgestelde “record klassen”. [13] [16] Simula introduceerde de notie van klassen en instanties of objecten (evenals subklassen, virtuele methoden, coroutines en discrete event simulatie ) als onderdeel van een expliciete programmeerparadigma. De taal ook gebruikt automatische garbage collection die eerder voor het had uitgevonden functionele programmeertaal taal Lisp. Simula werd gebruikt voor fysische modellering, zoals de modellen te bestuderen en verbeteren van de beweging van schepen en hun content via laadpoorten. De ideeën van Simula 67 beïnvloed veel later talen, waaronder Smalltalk, derivaten van LISP (CLOS), Object Pascal en C ++.

De Smalltalk taal, die werd ontwikkeld bij Xerox PARC (door Alan Kay en anderen) in de jaren 1970, introduceerde de term object-georiënteerd programmeren om het alomtegenwoordige gebruik van objecten en berichten als basis voor de berekening te vertegenwoordigen. Smalltalk makers werden beïnvloed door de ideeën geïntroduceerd in Simula 67, maar Smalltalk werd ontworpen om een volledig dynamisch systeem waarbij klassen kunnen worden aangemaakt en bewerkt dynamisch en niet statisch volgens Simula 67. [17] Smalltalk en daarmee OOP werden geïntroduceerd een breder publiek door de augustus 1981 nummer van Byte Magazine.

In de jaren 1970, had Kay Smalltalk werk de invloed Lisp gemeenschap op te nemen object-gebaseerde technieken die werden ingevoerd om de ontwikkelaars via het Lisp machine. Experimenteren met verschillende uitbreidingen van Lisp (zoals lussen en Flavors invoering van multiple inheritance en mixins) leidde uiteindelijk tot de Common Lisp Object System, die functioneel programmeren en object-georiënteerd programmeren integreert en maakt uitbreiding via een meta-object protocol. In de jaren 1980, waren er een paar pogingen om processor architecturen die hardware-ondersteuning voor objecten in het geheugen, maar deze waren niet succesvol te ontwerpen. Voorbeelden hiervan zijn de Intel iAPX 432 en de Linn Smart Rekursiv.

In 1985, Bertrand Meyer produceerde het eerste ontwerp van de Eiffel taal. Gericht op software kwaliteit, Eiffel behoort tot de zuiver objectgeoriënteerde talen, maar verschilt in die zin dat de taal zelf is niet alleen een programmeertaal, maar een notatie ondersteuning van de gehele software levenscyclus. Meyer beschreef de Eiffel software ontwikkeling methode, gebaseerd op een klein aantal belangrijke ideeën van software engineering en informatica, in Object-Oriented Software Construction. Essentieel voor de kwaliteit focus van Eiffel is Meyer betrouwbaarheid mechanisme, Design by Contract, die een integraal deel uitmaakt van zowel de methode en taal.

Object-georiënteerd programmeren ontwikkeld als de dominante programmering methodologie in de vroege en midden van de jaren 1990 toen programmeertalen ondersteunen van de technieken die op grote schaal beschikbaar kwamen. Deze omvatten Visual FoxPro 3.0, [18] [19] [20] C ++ [nodig citaat], en Delphi [nodig citaat]. Zijn dominantie werd verder versterkt door de stijgende populariteit van grafische user interfaces, die sterk afhankelijk zijn van object-georiënteerd programmeren technieken. Een voorbeeld van een nauw verwante dynamische GUI bibliotheek en OOP taal kan worden gevonden in de Cocoa frameworks op Mac OS X, geschreven in Objective-C, een object-georiënteerde, dynamische messaging uitbreiding van C op basis van Smalltalk. OOP toolkits verbeterde ook de populariteit van de event-driven programmeren (hoewel dit concept niet beperkt blijft tot OOP).

Bij ETH Zürich, Niklaus Wirth had en zijn collega’s ook onderzoeken onderwerpen als data-abstractie en modulair programmeren (hoewel dit in gemeenschappelijk gebruik was geweest in de jaren 1960 of eerder). Modula-2 (1978) omvatte zowel, en hun slagen ontwerp, Oberon, inclusief een onderscheidende benadering van oriëntatie, lessen, en dergelijke object.

Object-georiënteerde functies zijn toegevoegd aan de vele reeds bestaande talen, waaronder Ada, BASIC, Fortran, Pascal en COBOL. Het toevoegen van deze functies om talen die niet in eerste instantie ontworpen voor hen leidde vaak tot problemen met de compatibiliteit en onderhoudbaarheid van de code.

Recentelijk meerdere talen ontstaan die hoofdzakelijk objectgeoriënteerde, maar die ook geschikt procedurele methodologie. Twee van dergelijke talen zijn Python en Ruby. Waarschijnlijk de meest commercieel belangrijke Language objectgeoriënteerde talen Java, ontwikkeld door Sun Microsystems, en C # en Visual Basic.NET (VB.NET), beide ontworpen voor Microsoft’s .NET-platform. Elk van deze twee kaders shows, op zijn eigen manier, het voordeel van het gebruik van OOP door het creëren van een abstractie van de implementatie. VB.NET en C # ondersteuning cross-taal erfenis, waardoor klassen gedefinieerd in de ene taal naar subklasse klassen gedefinieerd in de andere taal.

OOP talen

Deze sectie is niet citeren enige verwijzingen of bronnen. Gelieve te helpen verbeteren van deze sectie door het toevoegen van citaten aan betrouwbare bronnen. Unsourced materiaal kan worden aangevochten en verwijderd. (Augustus 2009)
Zie ook: Lijst van objectgeoriënteerde programmeertalen

Simula (1967) wordt algemeen aanvaard als de eerste taal van de primaire kenmerken van een object-georiënteerde taal. Het werd gemaakt voor het maken simulatieprogramma’s, waarbij wat werd genoemd voorwerpen waren de belangrijkste informatie representatie. Smalltalk (1972-1980) is misschien wel de canonieke voorbeeld, en de een met die veel van de theorie van het object georiënteerd programmeren was ontwikkeld. Wat betreft de mate van oriëntatie object, kan het volgende onderscheid worden gemaakt:

  • Genaamd talen “pure” OO talen, omdat alles in hen wordt consequent behandeld als een object, van primitieven zoals tekens en interpunctie, helemaal tot aan hele klassen, prototypes, blokken, modules, enz. Ze zijn speciaal ontworpen om te vergemakkelijken, zelfs af te dwingen, OO methodes. Voorbeelden: Eiffel, Emerald, [21] JADE, oBIX, Ruby, Scala, Smalltalk, Self.
  • Talen vooral bedoeld voor OO programmeren, maar met een aantal procedurele elementen. Voorbeelden: Delphi / Object Pascal, C ++, Java, C #, VB.NET.
  • Talen die in het verleden zijn procedurele talen, maar zijn uitgebreid met een aantal OO features. Voorbeelden: Pascal, Visual Basic (afgeleid van BASIC), MATLAB, Fortran, Perl, COBOL 2002, PHP, ABAP, Ada 95.
  • Talen met de meeste van de eigenschappen van objecten (klassen, methoden, overerving), maar in een duidelijk oorspronkelijke vorm. Voorbeelden: Oberon (Oberon-1 of Oberon-2).
  • Talen met abstract datatype drager die kan worden gebruikt om OO programmeren lijken, maar zonder alle functies van object-oriëntatie. Dit omvat object- gebaseerd en-prototype op basis van talen. Voorbeelden: Modula-2, Pliant, CLU, JavaScript, Lua.
  • Kameleon talen die meerdere paradigma’s, waaronder OO ondersteunen. Tcl opvalt tussen deze voor TclOO, een hybride object dat zowel ondersteunt-prototype op basis van de programmering en de klasse gebaseerde OO.

OOP in dynamische talen

In de afgelopen jaren, is objectgeoriënteerd programmeren vooral populair geworden in dynamische programmeertalen. Python, Ruby en Groovy zijn dynamische talen gebouwd op OOP principes, terwijl Perl en PHP zijn het toevoegen van object-georiënteerde functies sinds Perl 5 en PHP 4, en ColdFusion sinds versie 6.

Het Document Object Model van HTML, XHTML en XML-documenten op het internet heeft banden met de populaire JavaScript / ECMAScript taal. JavaScript is misschien wel de bekendste-prototype gebaseerde programmering taal, die wendt het klonen van prototypes in plaats van erven van een klasse (tegenstelling tot klasse gebaseerde programmering). Voordat ECMAScript 6, werd slechts een prototype-gebaseerde object model ondersteund. Een andere scripttaal die deze aanpak neemt is Lua.

OOP in een netwerkprotocol

De berichten die stromen tussen computers om de diensten te vragen in een client-server-omgeving kan worden uitgevoerd als de linearisaties objecten gedefinieerd door de klasse van voorwerpen waarvan bekend zowel de client en de server. Bijvoorbeeld, een eenvoudige gelineariseerde voorwerp uit een lengteveld een codepunt identificeren van de klasse en een gegevenswaarde. Een complexer voorbeeld zou een opdracht bestaat uit de lengte en de code punt van de opdracht en waarden bestaande uit lineair objecten die parameters van de commando’s. Elke dergelijke opdracht moet worden geleid door de server van een object waarvan de klasse (of superklasse) herkent de opdracht en kan de gevraagde dienst. Clients en servers kunnen het beste gemodelleerd als complexe object-georiënteerde structuren. Distributed Data Management Architecture (DDM) nam deze aanpak en gebruikt class objecten om objecten te definiëren in vier niveaus van een formele hiërarchie:

  • Gebieden waarin de gegevenswaarden die berichten, zoals de lengte, codepoint en gegevenswaarden vormen.
  • Objecten en verzamelingen van voorwerpen vergelijkbaar met wat zou worden gevonden in een Smalltalk programma voor berichten en parameters.
  • Managers Soortgelijke AS / 400 voorwerpen, zoals een directory en bestanden bestaan uit metadata en registers. Managers conceptueel bieden geheugen en verwerking van de middelen voor hun bevatte objecten.
  • Een client of server, bestaande uit alle managers nodig zijn om een volledige verwerking milieu implementeren, ondersteunen aspecten als directory services, veiligheid en concurrency control.

De eerste versie van DDM gedefinieerde gedistribueerd bestandssysteem diensten. Het werd later uitgebreid tot de oprichting van zijn Distributed Relational Database Architecture (DRDA).

Design patterns

Uitdagingen van objectgeoriënteerd ontwerp worden aangepakt door verschillende methodieken. Meest voorkomende is bekend als de ontwerppatronen gecodificeerd Gamma et al.. Meer algemeen, de term “design patterns kan ‘worden gebruikt om te verwijzen naar een algemene, herhaalbare oplossing voor een veel voorkomend probleem in software design. Sommige van deze veel voorkomende problemen hebben gevolgen en oplossingen bijzonder om objectgeoriënteerde ontwikkeling.

Erfenis en gedragsmatige subtypering

Zie ook: Object-georiënteerd ontwerp

Het is intuïtief te veronderstellen dat overerving wordt een semantische “is een” relatie, en dus concluderen dat voorwerpen geïnstantieerd van subklassen steeds veilig kan worden gebruikt in plaats van die ingekaderde de superklasse. Deze intuïtie is helaas onjuist meeste OOP talen, in het bijzonder in al die waarmee veranderlijk objecten. Subtype polymorfisme zoals opgelegd door het soort checker in OOP talen (met veranderlijk objecten) kunnen niet garanderen behavioral subtypering in elke context. Behavioral subtypering is onbeslisbaar in het algemeen, dus het kan niet door een programma (compiler) worden uitgevoerd. Klasse of object hiërarchieën moeten zorgvuldig worden ontworpen, rekening houdend met mogelijke onjuiste toepassingen die niet syntactisch kan worden gedetecteerd. Dit probleem is bekend als de Liskov substitutieprincipe.

Bende van Vier design patterns

Hoofdartikel: Ontwerp patroon (computer science)

Design Patterns: Elements of Herbruikbare Object-Oriented Software is een invloedrijk boek gepubliceerd in 1995 door Erich Gamma, Richard Helm, Ralph Johnson en John Vlissides, vaak humoristische wijze aangeduid als de “Bende van Vier ‘. Samen met het verkennen van de mogelijkheden en valkuilen van object-georiënteerd programmeren, het beschrijft 23 gemeenschappelijke programmering problemen en patronen voor het oplossen ervan. Vanaf april 2007 is het boek was in zijn 36e druk.

Het boek beschrijft de volgende patronen:

  • Creational patronen (5): Fabriek methode patroon, Abstract fabriek patroon, Singleton, Bouwer patroon, Prototype patroon
  • Structurele patronen (7): Adapter patroon, Bridge patroon, Composite patroon, decorator, Gevel patroon, Vlieggewicht patroon, Proxy patroon
  • Gedragspatronen (11): Chain-of-verantwoordelijkheid patroon, Command patroon, Interpreter patroon, Iterator patroon, Middelaar patroon, Memento patroon, Observer patroon, patroon staat, strategie patroon, Template methode patroon, Bezoeker patroon

Object-oriëntatie en databases

Hoofd artikelen: Object-relationele impedantie mismatch, Object-relational mapping en object-database

Beide object-georiënteerd programmeren en relationele database management systemen (RDBMS) zijn zeer vaak in de software van vandaag Omdat relationele databases geen objecten direct doen slaan (hoewel sommige RDBMSs hebben objectgeoriënteerde functies om deze benadering), er een algemene behoefte aan beide werelden overbruggen. Het probleem van de te overbruggen objectgeoriënteerd programmeren toegang en data-patronen met relationele databases is bekend als object-relationele impedantie mismatch. Er zijn een aantal manieren om te gaan met dit probleem, maar geen algemene oplossing zonder nadelen. [22] Een van de meest gebruikelijke benaderingen object-relationele mapping, zoals gevonden in IDE talen zoals Visual FoxPro en bibliotheken zoals Java Data Objects en Ruby on Rails “ActiveRecord.

Er zijn ook bezwaar databases die kunnen worden gebruikt om RDBMSs vervangen, maar deze zijn niet technisch en commercieel succesvol RDBMSs geweest.

Real-world modellering en relaties

OOP kan worden gebruikt voor real-world objecten en werkwijzen koppelen met digitale tegenhangers. Echter, niet iedereen het erover eens dat OOP faciliteert directe real-world mapping (zie Kritiek sectie) of dat real-world mapping is zelfs een waardig doel; Bertrand Meyer betoogt in Object-Oriented Software Bouw [23] dat een programma is niet een model van de wereld, maar een model van een deel van de wereld; “De werkelijkheid is een neef twee keer verwijderd”. Tezelfdertijd waren zo’n voornaamste beperkingen van OOP opgemerkt. [24] Bijvoorbeeld, de cirkel ellips probleem is moeilijk te hanteren via begrip OOP van overerving.

Echter, Niklaus Wirth (die het adagium nu bekend als populair Wirth de wet: “Software wordt steeds trager sneller dan hardware wordt sneller”) zei van OOP in zijn papier, “Goede Ideeën Through the Looking Glass”, “Dit paradigma nauw weerspiegelt de structuur van de systemen in de echte wereld ‘, en het is daarom zeer geschikt voor het modelleren van complexe systemen met complexe gedragingen “(contrast KISS principe).

Steve Yegge en anderen opgemerkt dat natuurlijke talen niet de OOP aanpak strikt prioritering dingen (objecten / naamwoorden) voor acties (methoden / werkwoorden). [25] Dit probleem kan veroorzaken OOP meer ingewikkelde oplossingen dan procedureel programmeren lijden. [26]

OOP en control flow

OOP werd ontwikkeld om de verhoging van herbruikbaarheid en onderhoudbaarheid van de broncode. [27] Transparante weergave van de control flow had geen prioriteit en werd bedoeld met een compiler worden behandeld. Met het toenemende belang van parallelle hardware en multithreaded codering, ontwikkeling transparante besturingsstroom belangrijker, wat moeilijk te bereiken met OOP. [28] [29] [30] [31]

Verantwoordelijkheid- vs. data-driven design

Verantwoordelijkheid driven design definieert klassen in termen van een contract, dat wil zeggen, moet een klasse worden gedefinieerd rond een verantwoordelijkheid en de informatie die het deelt.Dit staat in contrast met Wirfs-Brock en Wilkerson met data-driven design, waar de lessen worden gedefinieerd rond de data-structuren die moeten worden gehouden. De auteurs stellen dat verantwoordelijkheid gedreven ontwerp de voorkeur.

SOLID en GRASP richtlijnen

SOLID is een ezelsbruggetje bedacht door Michael Feathers dat staat voor en pleit vijf programmering praktijken:

  • Enkele verantwoordelijkheid principe
  • Open / gesloten principe
  • Liskov substitutieprincipe
  • Interface segregatie principe
  • Afhankelijkheid inversie principe

GRASP (Algemeen Verantwoordelijkheid Assignment Software Patterns) is een andere set van richtlijnen bepleit door Craig Larman.

Kritiek

De OOP paradigma is bekritiseerd voor een aantal redenen, waaronder die niet voldoen aan de gestelde doelen van de herbruikbaarheid en modulariteit, [32] [33] en voor overemphasizing één aspect van software-ontwerp en modellering (data / objecten), ten koste van andere belangrijke aspecten (berekening / algoritmes). [34] [35]

Luca Cardelli heeft beweerd dat OOP code is “intrinsiek minder efficiënt” dan procedurele code, die OOP kan langer duren om te compileren, en dat OOP talen “extreem slechte modulariteit eigenschappen met betrekking tot klasse uitbreiding en aanpassing”, en hebben de neiging uiterst complex te zijn . [32] Het laatste punt wordt herhaald door Joe Armstrong, de voornaamste uitvinder van Erlang, die wordt als volgt geciteerd: [33]

Het probleem met objectgeoriënteerde talen is ze hebben al deze impliciete omgeving die ze dragen rond met hen. Je wilde een banaan, maar wat je kreeg was een gorilla die de banaan en de hele jungle.

Een studie van Potok et al. werd geen significant verschil in productiviteit tussen OOP en procedurele benaderingen. [36]

Christopher J. Date verklaard dat kritische vergelijking van OOP met andere technologieën, relationele in het bijzonder, is moeilijk vanwege het ontbreken van een afgesproken en strenge definitie van OOP; [37] echter Date en Darwen hebben een theoretisch fundament OOP voorgesteld OOP gebruikt als een soort van op maat gemaakte het type systeem te ondersteunen RDBMS. [38]

In een artikel beweerd Lawrence Krubner dat in vergelijking met andere talen (LISP dialecten, functionele talen, etc.) OOP talen hebben geen unieke sterke punten, en toebrengen van een zware last van onnodige complexiteit. [39]

Alexander Stepanov vergelijkt object oriëntatie ongunstig voor Generic programmering: [34]

Ik vind OOP technisch ondeugdelijke .. Het probeert de wereld te ontleden in termen van interfaces die variëren op een enkel type. Om rekening te houden met de echte problemen die je nodig hebt multisorted algebra – families van interfaces die meerdere types overspannen. Ik vind OOP filosofisch ondeugdelijke. Zij stelt dat alles is een object. Zelfs als het waar is het is niet erg interessant – te zeggen dat alles is een object zegt helemaal niets.

Paul Graham heeft gesuggereerd dat OOP de populariteit binnen de grote bedrijven is te wijten aan “grote (en vaak wisselende) groepen van middelmatige programmeurs.” Volgens Graham, de door OOP discipline voorkomt dat één programmeur van “het doen van te veel schade.” [40]

Steve Yegge opgemerkt dat, in tegenstelling tot functioneel programmeren: [41]

Object Oriented Programming zet de zelfstandige naamwoorden in de eerste plaats. Waarom zou je naar zo’n moeite om een deel van de toespraak op een voetstuk te zetten? Waarom zou een soort van begrip hebben voorrang op de andere? Het is niet zo dat OOP plotseling werkwoorden minder belangrijk in de manier waarop we eigenlijk denken heeft gemaakt. Het is een vreemd scheve perspectief.

Rijke Hickey, de schepper van Clojure, omschreven doel systemen al te simplistische modellen van de echte wereld. Hij benadrukte het onvermogen van OOP te modelleren tijd goed, die wordt steeds problematischer als softwaresystemen worden meer gelijktijdige. [35]

Eric S. Raymond, een Unix programmeur en open-source software voorstander is kritisch over claims dat het huidige object georiënteerd programmeren als het geweest “Een echte oplossing,” en heeft geschreven dat objectgeoriënteerde programmeertalen hebben de neiging om dik gelaagd programma’s stimuleren dat vernietigen transparantie. [42] Raymond vergelijkt dit ongunstig voor de aanpak met Unix en de C-programmeertaal. [42]

Formele semantiek

Zie ook: De formele semantiek van programmeertalen

Objecten zijn de run-time entiteiten in een object-georiënteerd systeem. Zij kunnen een persoon, een plaats, een bankrekening, een tabel van de gegevens, of een item dat het programma te hanteren vertegenwoordigen.

Er zijn verschillende pogingen tot formalisering van de begrippen die in objectgeoriënteerd programmeren geweest. De volgende begrippen en constructen zijn gebruikt als interpretaties van OOP concepten:

  • co algebraïsche datatypes [43]
  • types abstracte gegevens (die existentiële types) laat de definitie van modules, maar deze niet ondersteunen dynamische verzending
  • recursieve types
  • ingekapseld staat
  • erfenis
  • registers zijn basis voor het begrijpen objecten als Functieliteralen kunnen worden opgeslagen in gebieden (zoals functionele programmeertalen), maar de eigenlijke Calculi behoeft aanzienlijk complexer wezenlijke elementen van OOP incorporeren. Diverse uitbreidingen van System F <: dat de deal met veranderlijk objecten zijn bestudeerd; [44] deze laten zowel subtype polymorfisme en parametrische polymorfisme (generieke)

Pogingen om het vinden van een consensus definitie of theorie achter objecten zijn niet bewezen zeer succesvol (zie echter Abadi & Cardelli, A Theory of objecten [44] voor de formele definities van vele OOP concepten en constructies), en vaak sterk uiteenlopen. Bijvoorbeeld, een aantal definities richten op mentale activiteiten, en een aantal op het programma structureren. Een van de eenvoudigere definities is dat OOP is de handeling van het gebruik van “kaart” datastructuren of arrays die functies en aanwijzingen kunnen bevatten naar andere kaarten, allemaal met een aantal syntactische en scoping suiker bovenop. Inheritance kan worden uitgevoerd door het kloneren van de kaart (soms “prototyping”).

Zie ook

Portal icoon Computer programmering portal
  • Vergelijking van programmeertalen (object-georiënteerd programmeren)
  • Vergelijking van de programmering paradigma
  • Component-based software engineering
  • Ontwerp door contract
  • Object vereniging
  • Objectdatabase
  • Objectmodellering taal
  • Object-georiënteerde analyse en design
  • Object-relationele impedantie mismatch (en The Third Manifesto)
  • Object-relational mapping

Systemen

  • CADES
  • Common Object Request Broker Architecture (CORBA)
  • Distributed Component Object Model
  • Distributed Data Management Architecture
  • Jeroo

Modellering talen

  • IDEF4
  • Interface description language
  • Lepus3
  • UML