Perché l'ereditarietà, l'incapsulamento e il polimorfismo non sono i pilastri dell'OOP? [chiuso]

16

Un giorno sono andato a una chat di Stack Overflow e ho visto una frase, che affermava che l'ereditarietà, l'incapsulamento e il polimorfismo sono i pilastri di OOP (nel senso che sono fondamentali, una suola di costruzione).

Inoltre, c'è una domanda simile, che mi è stata rivolta molto spesso agli esami universitari e ai colloqui di lavoro, e la risposta giusta è sempre stata la dichiarazione pronunciata nel titolo della domanda ("Sì, l'eredità, l'incapsulamento e il polimorfismo sono le pilastri di OOP).

Ma nella chat di Stack Overflow ero seriamente ridicolizzato, i partecipanti erano strongmente in disaccordo con tale affermazione. Allora, cosa c'è di sbagliato in questa affermazione?

I programmatori sembrano essere addestrati in cose diverse nei college post-sovietici e negli Stati Uniti?

L'ereditarietà, l'incapsulamento e il polimorfismo non sono considerati i pilastri dell'OOP dai programmatori USA / Regno Unito?

    
posta PaulD 12.08.2014 - 20:07
fonte

2 risposte

40

Are inheritance, encapsulation and polymorphism are not considered to be the pillars of OOP by US/UK programmers?

Sono considerati pilastri da molti programmatori e molte università insegnano OO in questo modo.

Purtroppo, è anche una visione miope.

  • L'ereditarietà è un meccanismo utilizzato per implementare OOP e può essere abusato per non eseguire OOP.
  • L'incapsulamento è un concetto, utile per la programmazione di tutti i tipi, OOP e non.
  • Il polimorfismo è un ... tratto (?) per descrivere come si comporta la computazione. Ci sono molti modi per ottenere il polimorfismo, non tutti sono specifici per OO.

OOP ha pochissime fondamenta, dal momento che in realtà è molto concettuale: "Avvicinati al design del tuo programma pensando alle cose come oggetti: pacchetti di dati e funzionalità coesivi."

E mentre il design moderno del programma non ha una buona idea di fare le cose in un "puro modo OO", i programmatori più abili concorderanno che il I principi SOLID (o qualche sottoinsieme) sono candidati migliori per i" pilastri della programmazione orientata agli oggetti "(anche se si applicano bene ai non-OOP). Questi non funzionano affatto con questi termini. Invece usano i concetti delle entità software (di cui, gli oggetti sono uno), le interfacce (di cui, un C # / Java / etc. interface è uno), l'astrazione e la sottotipazione (di cui l'ereditarietà è una forma) .

    
risposta data 12.08.2014 - 20:22
fonte
23

tl; dr: puoi avere ereditarietà senza OO, puoi incapsulare senza OO, puoi avere polimorfismo senza OO, puoi anche avere tutti e tre contemporaneamente senza OO. Sul rovescio della medaglia, puoi avere OO senza ereditarietà. Inoltre, ci sono diversi tipi di incapsulamento (orientato verso ADT e OO), IOW non tutto l'incapsulamento è OO.

Versione lunga:

Il termine "Programmazione orientata agli oggetti" è stato inventato da Alan Kay, quindi riesce a decidere cosa significa. E lo definisce in questo modo :

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

Per quanto riguarda l'implementazione, la messaggistica è una chiamata a procedura ritardata, e se le chiamate di procedura sono in ritardo, non puoi sapere in fase di progettazione che chiamerai, quindi non puoi qualsiasi ipotesi sulla rappresentazione concreta dello stato. Quindi, in realtà riguarda la messaggistica, l'associazione tardiva è un'implementazione della messaggistica e l'incapsulamento è una conseguenza di essa.

In seguito chiarì che " La grande idea è" messaggistica " "e si rammarica di averlo definito" orientato agli oggetti "anziché" orientato ai messaggi ", perché il termine" orientato agli oggetti "mette l'attenzione sulla cosa non importante (gli oggetti) e distrae da ciò che è veramente importante (messaggistica):

Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.

The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word -- ma -- for "that which is in between" -- perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas.

(Certo, oggi la maggior parte delle persone non si concentra sugli oggetti ma sulle classi, il che è ancora più sbagliato.)

La messaggistica è fondamentale in OO, sia come metafora che come meccanismo.

Se invii a qualcuno un messaggio, non sai cosa ne fanno. La cosa solo che puoi osservare è la loro risposta. Non si sa se hanno elaborato il messaggio da soli (vale a dire se l'oggetto ha un metodo), se hanno inoltrato il messaggio a qualcun altro (delega / proxy), se addirittura lo hanno capito. Ecco di che cosa tratta l'incapsulamento, ecco di cosa si tratta OO. Non puoi nemmeno distinguere un proxy dalla cosa reale, a patto che risponda a come te lo aspetti.

Un termine più "moderno" per "messaggistica" è "dispacciamento metodo dinamico" o "chiamata metodo virtuale", ma perde la metafora e si concentra sul meccanismo.

Anche punti simili sono riportati in Informazioni sull'astrazione dei dati, rivisitato di William R. Cook e anche il suo Proposal per definizioni semplificate e moderne di "Object" e "Object Oriented" .

Dynamic dispatch of operations is the essential characteristic of objects. It means that the operation to be invoked is a dynamic property of the object itself. Operations cannot be identified statically, and there is no way in general to exactly what operation will executed in response to a given request, except by running it. This is exactly the same as with first-class functions, which are always dynamically dispatched.

In Smalltalk-72, non c'erano nemmeno oggetti! C'erano solo flussi di messaggi che sono stati analizzati, riscritti e reindirizzati. I primi metodi sono arrivati (modi standard per analizzare e reindirizzare i flussi di messaggi), successivamente sono arrivati oggetti (raggruppamenti di metodi che condividono alcuni stati privati). L'ereditarietà è arrivata molto più tardi e le classi sono state introdotte solo come un modo per supportare l'ereditarietà. Se il gruppo di ricerca di Kay avesse già conosciuto i prototipi, probabilmente non avrebbero mai introdotto le classi in primo luogo.

Ogni programmatore dovrebbe leggere Informazioni sull'astrazione dei dati, rivisitato . Spiega in dettaglio qual è esattamente la differenza tra Oggetti e Tipi di dati astratti. Fornisce esempi con Java, ed è estremamente rilevante per questa domanda, perché in entrambi gli esempi ADT e degli esempi di oggetti usa ereditarietà, incapsulamento e polimorfismo, ma solo < em> one degli esempi è orientato agli oggetti! In altre parole: puoi avere ereditarietà, incapsulamento e polimorfismo, puoi persino averli tutti e tre contemporaneamente e ancora non avere OO.

D'altra parte, puoi avere OO senza ereditarietà. Come ho accennato sopra: le versioni originali di Smalltalk (il linguaggio progettato da Alan Kay, l'inventore del termine "Programmazione orientata agli oggetti") non aveva ereditarietà.

Ultimo, ma certamente non meno importante, Il trattato di Orlando discute delegazione come alternativa all'ereditarietà e in che modo le diverse forme di delega e eredità conducono a punti di progettazione diversi all'interno dello spazio di progettazione di linguaggi object-oiented. (Si noti che in realtà anche nelle lingue che supportano l'ereditarietà, come Java, alle persone viene effettivamente insegnato a evitarlo, indicando nuovamente che non è necessario per OO.)

    
risposta data 13.08.2014 - 01:51
fonte

Leggi altre domande sui tag