Ho letto da qualche parte in una delle risposte a una domanda (non ricordo quale) che il C ++ non è adatto per la programmazione orientata agli oggetti. C'è stato un accenno al fatto che potevi usare la sua caratteristica o qualcosa del genere, ma non in senso puramente OOP (in realtà non capivo veramente cosa intendesse la persona).
C'è del vero in questo; se sì, perché?
Come descritto in Quindi cosa * ha * Alan Kay significava veramente con il termine "orientato agli oggetti"? , Alan Kay pensava che il passaggio dei messaggi fosse l'importante bit di OOP, ma è un po 'quel "C con le classi" (che più tardi è diventato C ++) manca. C ++ è solo struct con un po 'di comportamento, mentre gli oggetti in Smalltalk o Objective-C sono "intelligenti" in quanto possono decidere cosa fanno con i messaggi che vengono inviati. Se un oggetto Smalltalk-sque riceve un messaggio per il quale non ha un'implementazione, potrebbe pigramente aggiungerne uno, inoltrare il messaggio a un altro oggetto, o fare qualsiasi cosa arbitraria.
Ciò che offre C ++ in termini di orientamento agli oggetti è rappresentato da metodi e polimorfismo virtual che riguardano il modo in cui questi metodi vengono invocati. Quando il compilatore vede un tipo di dati (o class ) con metodi virtuali, costruisce un vtable con uno slot per ogni metodo virtuale. Le sottoclassi che implementano i metodi virtuali inseriranno le loro implementazioni negli slot corretti, quindi il codice del client deve semplicemente sapere in quale punto della tabella virtuale cercare il codice da eseguire anziché risolverlo fino alla funzione specifica. Ciò significa che C ++ effettivamente ha una forma di invio multiplo, sebbene sia implementato nel compilatore e non sia capace come un sistema Smalltalk-esque.
Se consideri il passaggio dei messaggi come fondamentale per OOP, allora mentre puoi farlo con C ++ è tutt'altro che facile. OTOH se si considera OOP come associazione di dati con funzioni che agiscono su tali dati, C ++ va bene.
Questo tipo di discussione mi infastidisce perché suona come l'esegesi, le persone che discutono sul significato di Holy Scriptute, o sulla Costituzione americana, e cosa intendevano gli autori originali, come se quello che noi pensano non importa.
Guarda, Alan Kay era / è un ragazzo intelligente, e ha avuto una buona idea, che si è confrontato con un sacco di altre buone idee, e ha trovato la sua realizzazione in Smalltalk e in altre lingue.
Non è il Messia, e OOP non è l'unico vero paradigma di programmazione.
È una buona idea, tra molte. C ++ ha buone idee in esso, provenienti dalla mentalità OOP? Certo che lo fa.
C ++ supporta OOP, se si definisce OOP per significare incapsulamento, ereditarietà e polimorfismo.
Tuttavia, C ++ non è eccellente in OOP. Una ragione è che il polimorfismo spesso dipende da oggetti allocati nell'heap, che, nonostante l'uso di puntatori intelligenti, sono più naturali con cui lavorare in un linguaggio raccolto.
Dove eccelle C ++, tuttavia, è nella programmazione generica. C ++ consente di creare facilmente codice generico altamente efficiente attraverso tecniche di programmazione funzionale basate su template.
C ++ ha preso in prestito funzionalità OOP da Simula. Uno o più sviluppatori di Simula IIRC hanno commentato che C ++ non era quello che avevano in mente.
C ++ ha buoni strumenti per l'astrazione, ma è più un linguaggio a paradigmi misti che un linguaggio orientato agli oggetti. Le funzionalità orientate agli oggetti ci sono, ma hai scelte che non sono "OOP rigorose".
Uno dei cattivi "opt-out" che si ottiene in C ++ è quello di utilizzare l'associazione anticipata piuttosto che quella tardiva per i metodi. Non solo è possibile, è l'impostazione predefinita. In Java, "final" è correlato, ma in qualche modo più pulito (specifica l'intento in un modo che non riguarda solo l'evitare un sovraccarico di prestazioni insignificante), ed è non l'impostazione predefinita.
In qualche modo, il C ++ mostra segni di essere un primo esperimento che è ancora qui. Anche così, è ancora un buon strumento, con molti vantaggi che non si trovano in altre lingue OOP.
Costringere tutto ciò che fa parte di una classe non produce necessariamente un ottimo codice OO.
Chiedi a un programmatore povero di programmare di programmare in Java e probabilmente prenderà una classe da qualche parte, dargli un metodo principale statico e inserire 1000 righe di codice. So di averlo visto.
Java ha un'istruzione switch. Ho visto switch( type ) { case typeA: bundles_of_code; break; case typeB: bundles_of_other_code; break } ecc. Sia in C ++ che in codice Java.
C ++ supporta molti concetti OO ma il suo standard non è definito da esso, tuttavia credo che molto dipenda da quale sia il tuo obiettivo.
La semantica "povera" principale in C ++ sta permettendo la costruzione di copie di classi in cui un oggetto si trasmuta in un altro. È possibile disabilitare questo ma non è possibile restituire uno da una funzione. Fortunatamente questo è indirizzato in C ++ 0x.
OOP non significa solo assicurarsi che tutto sia o sia in una classe. È perfettamente possibile scrivere codice non OO in un linguaggio "puramente OO". Ad esempio, "main" viene spesso indicato come una funzione globale, ma inventare una classe unicamente per contenere un metodo main statico è proprio come non-OO.
C ++ funziona meglio con un mix di varie cose; questo non dovrebbe sorprendere, in quanto è così che la maggior parte delle cose buone funziona meglio. Spesso OOP è uno di quegli strumenti molto utili.
C ++ può essere usato per OOP ma non è così "puro" come qualcosa come Smalltalk. Il C ++ ti consente anche di fare non-OOP, di cui le persone potrebbero parlare.
Sebbene non sia d'accordo con il sentimento, è vero che il sistema di tipo di C ++ non è puro OOP - non "tutto è un oggetto". I numeri (in particolare) non possono essere estesi come possono, ad esempio, Smalltalk. Non è possibile ridefinire il significato di "2 + 2" ad esempio (sebbene sia possibile ridefinire il significato di "due + due").
Ma ciò che la maggior parte delle persone probabilmente significa è che molte persone scrivono codice non orientato agli oggetti in C ++ ma credono che, poiché usano un linguaggio "OOP", sono orientate agli oggetti. Non è vero. Ma secondo me, puoi scrivere un orribile codice imperativo in Smalltalk e non essere superiore a un decente design OOP in C ++.
L'obiezione perfettamente valida di Alan Kay al C ++ era che si trattava di un linguaggio macro sopra C.
La nozione di "passaggio di messaggi" è semplicemente l'idea che le istanze di classi sono conservate in memoria e che espongono metodi che possono essere chiamati. Il passaggio dei messaggi è * simulato "in C ++ usando vtables che tengono puntatori alle funzioni.
Dire che il passaggio dei messaggi non esiste in C ++ è impreciso, ciò che è più preciso da dire è che il passaggio dei messaggi è parte integrante di altre lingue come smalltalk e Java perché il linguaggio non sta eseguendo il preprocessing di un costrutto straniero e lo innesta su C direttamente.
Questo è un argomento di progettazione linguistica altamente semantico che sospetto sia un po 'al di là del livello di esperienza dell'interrogante.
Detto questo ci sono mille motivi per odiare il C ++ e pochissimi motivi per amarlo.
Piuttosto che cercare il martello perfetto e l'unghia perfetta, trova la casa perfetta da costruire e poi trova gli strumenti giusti ... che richiede esperienza.
È anche importante ricordare che nella programmazione di sistemi ciò che Alan Kay teme non è "puro OOP" è in realtà un punto di forza del C ++. A ciascuno il suo ...
A mio avviso, non è tanto un problema di definizione quanto un problema di usabilità.
Gli oggetti sono un'astrazione pensata per rendere più facile la lettura, la scrittura e la motivazione di programmi complessi. Per un programmatore pratico, se una lingua soddisfa tutti i criteri di una particolare definizione formale di "orientato agli oggetti" (sembra che ci siano molti concorrenti!) Non è tanto importante quanto se gli strumenti che offre siano adatti a pensare il tuo programma in termini di detti oggetti - cioè, in realtà miete i supposti benefici di produttività di OOP.
In C ++, gli oggetti sono un'astrazione terribilmente leaky , costringendo spesso i programmatori a confrontarsi con problemi sgradevoli legati al modo in cui questi oggetti sono strutturati in memoria - problemi che ricordano più la codifica in modo C che altre lingue OOP. Ad esempio, Domande frequenti su C ++ offre questa critica (tra le altre):
It is very beneficial for a practitioner to gain familiarity with OO systems other than C++, and with OO definitions other than the "encapsulation, inheritance, polymorphism" trinity interpreted in special ways allowing C++ to be considered "OO". For example, a claim that an environment lacking boundary checking or garbage collection is not an OO environment sounds outrageous to people accustomed to C++. But from many perspectives, it makes a lot of sense. If anyone can overwrite an object, where's the "encapsulation"? If disposing an object can lead to dangling references or memory leaks, how is the system "object-oriented"? What about the ability to tell what kind of object is located at a given place and time? You say the software works with objects - where are they? And if one can't find out, how is one supposed to debug the software?
C ++ è orientato agli oggetti, ma spiacevolmente e in modo incompleto: i suoi utenti devono dedicare molto impegno per assicurarsi che i loro dati si comportino come oggetti "reali" piuttosto che come bit erranti. Detto questo, un sacco di codice è stato scritto in C ++ per tutta la sua durata, la maggior parte di esso fa uso di classi e dispatch dinamici, quindi è evidentemente qualcosa che puoi usare per OOP pratico .
C'è una ragione per cui Graham Lee ha avuto il maggior numero di uptotes qui. Per reiterare, sembra che una classe C ++ non sia realmente un oggetto nel senso che non esegue il passaggio dei messaggi. Penso che questo sia ciò che spinge le persone a fare un sacco di cose quando stanno imparando C ++ o oop. Alle persone viene detto che l'orientamento agli oggetti è "questo" e poi viene detto che C ++ lo fa diversamente. Beh, C ++ non ha mai fatto OOP in modo diverso. Se pensate in questo modo non apprezzerete mai le classi C ++ per quello a cui sono destinate e cioè che sono semplicemente un miglioramento del paradigma procedurale incorporando l'astrazione e il comportamento dinamico. Quindi le classi C ++ sono procedurali per via procedurale, semplicemente migliorano il paradigma procedurale, o meglio sono una versione più avanzata di una struttura C.
Steve Yegge l'ha detto meglio :
C++ is the dumbest language on earth, in the very real sense of being the least sentient. It doesn't know about itself.
Il sistema di oggetti in C ++ è così cablato e fissato al momento della compilazione, che è molto distante dalla nozione originale di OOP che implica il passaggio di messaggi, l'introspezione, la riflessione, la spedizione dinamica e rilegatura tardiva, tra le altre cose. L'unica cosa in comune con C ++ e Smalltalk è un po 'di vocabolario.
Leggi altre domande sui tag object-oriented c++