Vra

Aangesien die debat sonder betekenisvolle terme is betekenislose, Ek het gedink ek sou punt op die olifant in die kamer en vra:Wat presies maak'n taal "voorwerp-georiënteerde"?Ek is nie op soek vir'n handboek antwoord hier nie, maar een wat gebaseer is op jou ervarings met OO tale wat goed werk in jou domein, wat dit ookal mag wees.

'n verwante vraag wat kan help om die eerste antwoord is:Wat is die argetipe van die voorwerp-georiënteerde tale en hoekom?

Was dit nuttig?

Oplossing

Definisies vir Object-Oriëntering is natuurlik 'n groot blik wurms , maar hier is my 2 sent:

Vir my is Object-Oriëntering is alles oor voorwerpe wat saam deur die stuur van boodskappe. Dit wil sê, om my, die enkele belangrikste eienskap van 'n objekgeoriënteerde taal.

As ek moes 'n geordende lys van al die eienskappe wat 'n objekgeoriënteerde taal moet hê sit, sou dit so lyk:

  1. voorwerpe stuur van boodskappe aan ander voorwerpe
  2. Alles is 'n Object
  3. Laat Binding
  4. Subtype Polimorfisme
  5. erfenis of iets soortgelyk ekspressiewe, soos Delegering
  6. Enkapsulering
  7. Inligting verberg
  8. Abstraksie

Dit is duidelik dat hierdie lys is baie omstrede, aangesien dit sluit 'n groot verskeidenheid van tale wat wyd beskou as objekgeoriënteerde, soos Java , C # en C ++ , wat almal in stryd met punte 1, 2 en 3. daar is egter geen twyfel dat dié tale voorsiening te maak vir objekgeoriënteerde programmering (maar so ook C ) en selfs fasiliteer (wat C nie doen). So, ek het gekom om tale wat dié vereistes voldoen noem "suiwer objek-georiënteerde".

As argetipiese objekgeoriënteerde tale ek sou noem Self en newspeak .

Beide voldoen aan die bogenoemde vereistes voldoen. Albei is geïnspireer deur en opvolgers om Smalltalk , en albei eintlik daarin slaag om "meer OO" te wees in 'n sekere sin. Die dinge wat ek graag oor die self en newspeak is dat beide neem die boodskap stuur paradigma tot die uiterste (newspeak selfs meer so as Self).

In newspeak, alles is 'n boodskap te stuur. Daar is geen geval veranderlikes, geen velde, geen eienskappe, geen konstantes, geen klas name. Hulle is almal nagevolg deur gebruik te maak van getters en etters.

In Self, is daar geen klasse , net voorwerpe. Dit beklemtoon, wat OO is regtig oor:. Voorwerpe, nie klasse

Ander wenke

Volgens Booch, die volgende elemente: Groot:

  • Abstraksie
  • Enkapsulering
  • Modulariteit
  • Hiërargie (Inheritance)

Klein:

  • Tik
  • Concurrency
  • Persistence

Eintlik Objekgeoriënteerde regtig kom neer op "boodskap verby"

In 'n proses taal, ek noem 'n funksie soos volg:

  f(x)

En die naam f is waarskynlik verplig om 'n bepaalde blok kode tydens kompilering. (Tensy dit 'n prosedurele taal met 'n hoër orde funksies of verwysings na funksies, maar kan ignoreer die moontlikheid vir 'n tweede.) So hierdie reël van die kode kan net beteken een ondubbelsinnige ding.

In 'n objekgeoriënteerde taal te slaag ek 'n boodskap aan 'n voorwerp, miskien soos volg:

 o.m(x) 

In hierdie geval. m is nie die naam van 'n blok van die kode, maar 'n "metode selector" en wat blok kode eintlik kry geroep is afhanklik van die voorwerp o in een of ander manier. Hierdie reël van die kode is meer dubbelsinnig of algemene omdat dit verskillende dinge in verskillende situasies kan beteken, afhangend van o.

In die meerderheid van OO tale, die voorwerp o het 'n "klas", en die klas bepaal watter blok kode genoem word. In 'n paar van OO tale (die bekendste, Javascript) o het nie 'n klas, maar het metodes direk daaraan gekoppel is tydens looptyd, of het hulle geërf het van 'n prototipe.

My afbakening is dat nie klasse of erfenis nodig is vir 'n taal te OO wees. Maar hierdie polimorfiese hantering van boodskappe is noodsaaklik.

Hoewel jy kan fake dit met funksie wysers in sê C, dit is nie genoeg vir C 'n OO taal genoem te word nie, want jy gaan hê om jou eie infrastruktuur te implementeer. Jy kan dit doen, en 'n OO styl is moontlik, maar die taal het dit nie aan jou gegee.

Dit is nie regtig die tale wat OO is, dit is die kode.

Dit is moontlik om objek-georiënteerde C-kode skryf (met structs en selfs funksioneer wyser lede, as jy wil) en ek het 'n paar mooi goeie voorbeelde daarvan gesien. (Quake 03/02 SDK opkom.) Dit is ook beslis moontlik prosedure te skryf (maw nie-OO) kode in C ++.

Gegewe dat ek sou sê dit is die ondersteuning van die taal se vir die skryf van 'n goeie OO kode wat maak dit 'n "objekgeoriënteerde taal." Ek sou nooit die moeite met die gebruik van funksie wyser lede in structs in C, byvoorbeeld, vir wat sou wees gewone lid funksies; daarom sal ek sê dat C is nie 'n OO taal.

(Uitbreiding op hierdie, kan 'n mens sê dat Python is nie objekgeoriënteerde, óf, met die verpligte "self" verwysing op elke stap en konstruktors genoem init , noem maar op, maar dit is 'n Godsdienstige bespreking. )

Smalltalk word gewoonlik beskou as die argetipiese OO taal, hoewel Simula word dikwels aangehaal as die eerste OO taal.

Huidige OO tale kan losweg gekategoriseer deur watter taal hulle leen die meeste konsepte van:

  • Smalltalk-agtige: Ruby, Objective-C
  • Simula-agtige: C ++, Object Pascal, Java, C #

Sover ek kan sê, die hoof vertoning van wat 'n taal "Objekgeoriënteerde" ondersteun die idee van die groepering van data, en metodes wat werk op daardie data, wat oor die algemeen deur klasse, modules, erfenis, polimorfisme bereik , ens.

hierdie bespreking vir 'n oorsig van wat mense dink (dink?) Object-Oriëntering beteken.

As vir die "argetipiese" OO taal -. Dit is inderdaad Smalltalk, as Kristopher daarop gewys

Ondersteun klasse, metodes, eienskappe, inkapseling, data wegkruip, erfenis, polimorfisme, abstraksie ...?

nie rekening gehou met die teoretiese implikasies, dit blyk te wees

"Enige taal wat 'n navraag het 'n beroep 'n klas" :-P

Om verder wat AIB gesê, sou ek sê dat 'n taal is nie regtig objekgeoriënteerde tensy die standaard biblioteke wat beskikbaar is objekgeoriënteerde. Die grootste voorbeeld hiervan is PHP. Hoewel dit al die standaard objekgeoriënteerde konsepte, die feit dat so 'n groot persentasie van die standaard biblioteke nie objekgeoriënteerde ondersteun beteken dat dit byna onmoontlik is om jou kode te skryf in 'n objekgeoriënteerde wyse.

Dit maak nie saak dat hulle die bekendstelling van naamruimtes as al die standaard biblioteke jy nog nodig het om al jou funksie 'n beroep met dinge soos mysql_ en pgsql_, voorvoegsel toe in 'n taal wat naamruimtes in die werklike API ondersteun, kan jy ontslae te raak van funksies met mysql_ en het net 'n eenvoudige "sluit system.db.mysql. *" aan die bokant van jou lêer sodat dit sou weet waar die dinge vandaan kom.

wanneer jy klasse kan maak, dit is objekgeoriënteerde
byvoorbeeld: Java is objekgeoriënteerde, javascript is nie, en c ++ lyk soos 'n soort van "voorwerp-nuuskierig" taal

In my ervaring, tale is nie objekgeoriënteerde,-kode is.

'n Paar jaar gelede het ek die skryf van 'n suite van programme in Apple, wat nie werklik enige objek-georiënteerde funksies bied afdwing, toe ek begin om grok OO. Dit is onbeholpe om voorwerpe in Apple skryf, hoewel dit moontlik is om klasse, konstruktors te skep, en dies meer as jy die tyd neem om uit te vind hoe.

Die taal was die korrekte taal vir die domein: om verskillende programme op die Macintosh om saam te werk om 'n paar outomatiese take gebaseer op insette lêers te bereik. Neem die moeite om self-af te dwing 'n objek-georiënteerde styl was die korrekte ontwikkeling keuse, want dit het gelei tot kode wat makliker was om moeilikheid-skiet, toets, en verstaan.

Die funksie wat ek die meeste opgemerk in die verandering van die kode oor van prosedurele om OO was inkapseling:. Beide van eiendomme en metode oproepe

Simples: (vergelyk versekering karakter)

1-Polimorfisme 2-Erfenis 3-Enkapsulering 4-Hergebruik. :)

Object: 'n voorwerp is 'n bron van data. Byvoorbeeld, as MyList is 'n winkel lys voorwerp, MyList kan jou inkopielys te teken.

Klas: 'n Klas is 'n tipe van voorwerp. Baie voorwerpe van dieselfde klas mag bestaan; byvoorbeeld, MyList en YourList kan beide wees winkel lys voorwerpe.

Metode: 'n prosedure of funksie wat werk op 'n voorwerp of 'n klas. 'N Metode is wat verband hou met 'n bepaalde klas. Byvoorbeeld, kan addItem 'n metode wat 'n item dra by tot 'n winkel lys voorwerp wees. Soms is 'n metode is wat verband hou met 'n gesin van klasse. Byvoorbeeld, kan addItem bedryf op enige Lys, waarvan 'n winkel lys is net een tipe.

Erfenis: A klas kan eienskappe besit van 'n meer algemene klas. Byvoorbeeld, die winkel lys klas erf vanaf die klas Lys die eiendom van die stoor van 'n reeks van items.

Polimorfisme: Die vermoë om 'n metode oproep werk het 'n hele paar verskillende klasse van voorwerpe, selfs al is daardie klasse nodig het verskillende implementering van die metode oproep. Byvoorbeeld, kan 'n reël van die kode in staat wees om die "addItem" metode 'n beroep op elke soort Lys, selfs al is die toevoeging van 'n item om 'n winkel lys is heeltemal anders as die toevoeging van 'n item om 'n Winkelwagen.

objekgeoriënteerde: Elke voorwerp weet sy eie klas en watter metodes te manipuleer voorwerpe in daardie klas. Elke winkel lys en elke Winkelwagen weet wat implementering van addItem geld vir dit.

In hierdie lys, die een ding wat werklik onderskei objekgeoriënteerde tale van prosedurele tale (C, Fortran, Basic, Pascal) is polimorfisme.

Bron: https://www.youtube.com / kyk? v = mFPmKGIrQs4 & lys = PL-xxv-cvA_iAlnI-BQr9hjqADPBtujFJd

Ek is bly om dit te deel met julle ouens, dit was baie interessant en nuttig vir my. Dit is 'n uittreksel uit 'n 1994 Rolling Stone onderhoud waar Steve (nie 'n programmeerder) verduidelik OOP in eenvoudige terme.

Jeff Goodell:? Wil jy verduidelik, in eenvoudige terme, presies wat objekgeoriënteerde sagteware is

Steve Jobs: voorwerpe soos mense. Hulle leef, asemhaal dinge wat kennis binne hulle oor hoe om dinge te doen het en het geheue binne hulle, sodat hulle dinge kan onthou. En eerder as interaksie met hulle op 'n baie lae vlak, interaksie tussen jou en hulle op 'n baie hoë vlak van abstraksie, soos ons hier doen.

Hier is 'n voorbeeld: As ek jou wasgoed voorwerp, kan jy my gee jou vuil klere en stuur vir my 'n boodskap wat sê: "Kan jy my klere gewas, asseblief." Ek weet toevallig waar die beste wasgoed plek in San Francisco is. En ek praat Engels, en ek het dollars in my sakke. So ek gaan uit en hael 'n taxi en vertel die bestuurder om my te neem om hierdie plek in San Francisco. Ek gaan kry jou klere gewas, ek spring terug in die kajuit, ek kry hier terug. Ek gee jou skoon klere en sê: "Hier is jou skoon klere."

Jy het geen idee hoe ek dit gedoen het. Jy het geen kennis van die wasgoed plek. Miskien het jy Frans praat, en jy kan nie eens 'n taxi hael. Jy kan nie betaal vir een, het jy nie dollars in jou sak. Tog, ek het geweet hoe om dit alles te doen. En jy het nie enige van dit weet. Al wat kompleksiteit verborge was binnekant van my, en ons was in staat om te kommunikeer op 'n baie hoë vlak van abstraksie. Dit is wat die voorwerpe is. Hulle omsluit kompleksiteit, en die poorte na die kompleksiteit is 'n hoë vlak.

Argetipe

Die vermoë om te druk die werklike wêreld scenario's in die kode.

foreach(House house in location.Houses)
{
 foreach(Deliverable mail in new Mailbag(new Deliverable[]
              {
              GetLetters(), 
              GetPackages(), 
              GetAdvertisingJunk()
              })
 {
    if(mail.AddressedTo(house))
    {
        house.Deliver(mail);
    }
 }
}

-

foreach(Deliverable myMail in GetMail())
{
    IReadable readable = myMail as IReadable;
    if ( readable != null )
    {
        Console.WriteLine(readable.Text);
    }
}

Hoekom?

Om ons te help verstaan dit meer maklik.Dit maak beter gevoel in ons koppe en as korrek geïmplementeer maak die kode meer doeltreffende, her-bruikbare en verminder herhaling.

Om dit te bereik wat jy nodig het:

  • Wenke/Verwysings om te verseker dat hierdie == hierdie en hierdie != dat.
  • Klasse om te verwys na (bv.Arm) dat die winkel data (int hairyness) en bedrywighede (Gooi(IThrowable))
  • Polimorfisme (Erfenis-en/of Koppelvlakke) om te behandel spesifieke voorwerpe in'n generiese mode, sodat jy kan lees boeke sowel as die graffiti op die muur (beide implementeer IReadable)
  • Inkapseling omdat'n appel nie bloot'n Atome[] eiendom
Gelisensieer onder: CC-BY-SA met toeskrywing
Nie verbonde aan StackOverflow
scroll top