Qual è il punto di OOP?

Per quanto ne so, nonostante gli innumerevoli milioni o miliardi spesi in istruzione, lingue e strumenti OOP, OOP non ha migliorato la produttività degli sviluppatori o l'affidabilità del software, né ha ridotto i costi di sviluppo. Poche persone usano OOP in qualsiasi senso rigoroso (poche persone aderiscono o comprendono principi come LSP); sembra esserci poca uniformità o coerenza negli approcci che le persone adottano per modellare i domini problematici. Troppo spesso, la classe viene utilizzata semplicemente per il suo zucchero sintattico; mette le funzioni per un tipo di record nel loro piccolo spazio dei nomi.

Ho scritto una grande quantità di codice per un'ampia varietà di applicazioni. Sebbene ci siano stati luoghi in cui il vero sottotitolo sostituibile ha svolto un ruolo prezioso nell'applicazione, questi sono stati piuttosto eccezionali. In generale, anche se viene dato molto servizio labiale per parlare di "riutilizzo", la realtà è che a meno che un pezzo di codice non faccia esattamente quello che si desidera che faccia, c'è un "riutilizzo" molto conveniente. È estremamente difficile progettare le classi per essere estensibili nel modo giusto , e quindi il costo dell'estensione è normalmente così grande che il "riutilizzo" semplicemente non vale la pena.

Per molti aspetti, questo non mi sorprende. Il mondo reale non è "OO" e l'idea implicita in OO - che possiamo modellare le cose con una certa tassonomia di classe - mi sembra fondamentalmente imperfetta (posso sedermi su un tavolo, un tronco d'albero, un cofano di un'auto , il grembo di qualcuno - ma non uno di quelli è una sedia). Anche se ci spostiamo su domini più astratti, la modellazione OO è spesso difficile, controintuitiva e, in definitiva, non utile (considera gli esempi classici di cerchi / ellissi o quadrati / rettangoli).

Quindi cosa mi sto perdendo qui? Dov'è il valore di OOP e perché tempo e denaro non sono riusciti a migliorare il software?

Non ci sono prove empiriche che suggeriscono che l'orientamento agli oggetti sia un modo più naturale per le persone di pensare al mondo. C'è qualche lavoro nel campo della psicologia della programmazione che mostra che OO non è in qualche modo più adatto di altri approcci.

Le rappresentazioni orientate agli oggetti non sembrano essere universalmente più utilizzabili o meno utilizzabili.

Non è sufficiente semplicemente adottare metodi OO e richiedere agli sviluppatori di utilizzare tali metodi, poiché ciò potrebbe avere un impatto negativo sulla produttività degli sviluppatori, nonché sulla qualità dei sistemi sviluppati.

Che proviene da "On the Usability of OO Representations" di Communications of the ACM October 2000. Gli articoli confronta principalmente OO con l'approccio orientato al processo. C'è molto studio su come le persone che lavorano con il metodo OO "pensano" (Int. J. di Human-Computer Studies 2001, numero 54, o Human-Computer Interaction 1995, vol. 10 ha un intero tema sugli studi OO), e da quello che ho letto, non c'è nulla che indichi una sorta di naturalezza all'approccio OO che lo rende più adatto di un approccio procedurale più tradizionale.

Il mondo reale non è "OO" e l'idea implicita in OO - che possiamo modellare le cose con una certa tassonomia di classe - mi sembra fondamentalmente imperfetta

Mentre questo è vero ed è stato osservato da altre persone (prendi Stepanov, inventore della STL), il resto non ha senso. OOP può essere difettoso e certamente non è un proiettile d'argento ma rende le applicazioni su larga scala molto più semplici perché è un ottimo modo per ridurre le dipendenze. Naturalmente, questo è vero solo per il "buon" design OOP. Il design sciatto non darà alcun vantaggio. Ma un buon design disaccoppiato può essere modellato molto bene usando OOP e non usando altre tecniche.

Esistono modelli molto migliori e più universali (mi viene in mente il modello di tipo Haskell ) ma spesso sono anche più complicati e / o difficili da implementare in modo efficiente. OOP è un buon compromesso tra estremi.

OOP non riguarda la creazione di classi riutilizzabili, ma la creazione di classi utilizzabili.

Troppo spesso, la classe viene utilizzata semplicemente per il suo zucchero sintattico; mette le funzioni per un tipo di record nel loro piccolo spazio dei nomi.

Sì, trovo che anche questo sia troppo diffuso. Questa non è una programmazione orientata agli oggetti. Si tratta di programmazione basata su oggetti e programmazione incentrata sui dati. Nei miei 10 anni di lavoro con OO Languages, vedo persone che si occupano principalmente di programmazione basata su oggetti. OBP si interrompe molto rapidamente IMHO poiché in sostanza si sta ottenendo il peggio di entrambe le parole: 1) Programmazione procedurale senza aderire alla metodologia di programmazione strutturata comprovata e 2) OOP senza aderire alla metodologia OOP comprovata.

OOP fatto bene è una cosa bellissima. Rende i problemi molto difficili facili da risolvere, e per i non iniziati (non cercando di sembrare pomposo lì), può quasi sembrare magia. Detto questo, OOP è solo uno strumento nella cassetta degli attrezzi delle metodologie di programmazione. Non è la fine tutta la metodologia. Capita solo di adattarsi bene alle grandi applicazioni aziendali.

La maggior parte degli sviluppatori che lavorano nei linguaggi OOP utilizzano esempi di OOP eseguiti proprio nei framework e nei tipi che utilizzano quotidianamente, ma non ne sono consapevoli. Ecco alcuni esempi molto semplici: ADO.NET, Hibernate / NHibernate, Logging Frameworks, vari tipi di raccolte di lingue, lo stack ASP.NET, lo stack JSP ecc ... Queste sono tutte cose che dipendono fortemente da OOP nelle loro basi di codice.

Il riutilizzo non dovrebbe essere un obiettivo di OOP - o qualsiasi altro paradigma per quella materia.

Il riutilizzo è un effetto collaterale di un buon design e un adeguato livello di astrazione. Il codice ottiene il riutilizzo facendo qualcosa di utile, ma non facendo così tanto da renderlo inflessibile. Non importa se il codice è OO o meno: riutilizziamo ciò che funziona e non è banale fare noi stessi. Questo è pragmatismo.

Il pensiero di OO come un nuovo modo di riutilizzare l'eredità è fondamentalmente imperfetto. Come notate le violazioni di LSP abbondano. Invece, OO è correttamente considerato come un metodo per gestire la complessità di un dominio problematico. L'obiettivo è la manutenibilità di un sistema nel tempo. Lo strumento principale per raggiungere questo obiettivo è la separazione dell'interfaccia pubblica da un'implementazione privata. Questo ci permette di avere regole come "Questo dovrebbe essere modificato solo usando ..." imposto dal compilatore, piuttosto che revisione del codice.

Usando questo, sono sicuro che sarai d'accordo, ci consente di creare e mantenere sistemi estremamente complessi. C'è molto valore in questo, e non è facile farlo in altri paradigmi.

Vergognando sui religiosi, ma direi che stai dipingendo un quadro troppo cupo dello stato della moderna OOP. Direi che in realtà ha ridotto i costi, fatta di grandi progetti software gestibile, e così via. Ciò non significa che abbia risolto il problema fondamentale della confusione del software e non significa che lo sviluppatore medio sia un esperto di OOP. Ma la modularizzazione della funzione in componenti-oggetto ha certamente ridotto la quantità di codice spaghetti presente nel mondo.

Riesco a pensare a decine di librerie dalla parte superiore della mia testa che sono meravigliosamente riutilizzabili e che hanno risparmiato tempo e denaro che non possono mai essere calcolati.

Ma nella misura in cui OOP è stata una perdita di tempo, direi che è a causa della mancanza di formazione del programmatore, aggravata dalla ripida curva di apprendimento dell'apprendimento di una mappatura OOP specifica della lingua. Alcune persone "ottengono" OOP e altre non lo faranno mai.

Penso che l'uso di oggetti di contesto opachi (HANDLEs in Win32, FILE * s in C, per nominare due esempi ben noti: l'inferno, HANDLE vive dall'altra parte della barriera in modalità kernel, e in realtà non si ottiene molto più incapsulato di quello) si trova anche nel codice procedurale; Faccio fatica a vedere come questo sia qualcosa di particolare per OOP.

HANDLEs (e il resto di WinAPI) è OOP! C non supporta OOP molto bene, quindi non esiste una sintassi speciale ma ciò non significa che non usi gli stessi concetti. WinAPI è in ogni senso della parola un framework orientato agli oggetti.

Vedi, questo è il problema di ogni singola discussione che coinvolge OOP o tecniche alternative: nessuno è chiaro sulla definizione, tutti parlano di qualcos'altro e quindi non è possibile raggiungere un consenso. Mi sembra una perdita di tempo.

È un paradigma di programmazione. Progettato per rendere più semplice per noi semplici mortali suddividere un problema in pezzi più piccoli e lavorabili.

Se non lo trovi utile .. Non usarlo, non pagare per l'allenamento ed essere felice.

D'altra parte lo trovo utile, quindi lo farò :)

Relativamente alla semplice programmazione procedurale, il primo principio fondamentale di OOP è la nozione di occultamento e incapsulamento delle informazioni. Questa idea porta alla nozione della classe che separa l'interfaccia dall'implementazione. Questi sono concetti estremamente importanti e la base per mettere in atto un framework per pensare alla progettazione del programma in un modo diverso e migliore (penso). Non si può davvero discutere contro quelle proprietà: non c'è alcun compromesso ed è sempre un modo più pulito di modulare le cose.

Anche altri aspetti della OOP, tra cui eredità e polimorfismo, sono importanti, ma come altri hanno accennato, quelli sono comunemente usati troppo. cioè: a volte le persone usano l'eredità e / o il polimorfismo perché possono, non perché dovrebbero avere. Sono concetti potenti e molto utili, ma devono essere usati con saggezza e non sono vantaggi automatici vincenti di OOP.

Relativo al riutilizzo. Accetto che il riutilizzo sia esaurito per OOP. È un possibile effetto collaterale di oggetti ben definiti, in genere di classi più primitive / generiche ed è un risultato diretto dei concetti di incapsulamento e occultamento delle informazioni. È potenzialmente più facile da riutilizzare perché le interfacce di classi ben definite sono semplicemente più chiare e in qualche modo auto-documentate.

Il problema con OOP è che è stato ipervenduto.

Come originariamente concepito da Alan Kay, era un'ottima alternativa alla pratica precedente di disporre di dati non elaborati e routine globali.

Quindi alcuni tipi di consulenti di gestione si sono aggrappati a esso e lo hanno venduto come il messia del software, e dopo che lemming-like, il mondo accademico e l'industria sono crollati.

Ora stanno cadendo come lemming dopo che altre buone idee sono state vendute, come la programmazione funzionale.

Quindi cosa farei diversamente? Un sacco, e ho scritto un libro su questo. (È esaurito - Non ottengo un centesimo, ma puoi ancora ottenere copie.) Amazon

La mia risposta costruttiva è guardare alla programmazione non come un modo per modellare le cose nel mondo reale, ma come un modo per codificare i requisiti.

È molto diverso e si basa sulla teoria dell'informazione (a un livello che chiunque può capire). Dice che la programmazione può essere vista come un processo di definizione delle lingue, e l'abilità nel farlo è essenziale per una buona programmazione.

Aumenta il concetto di linguaggi specifici di dominio (DSL). È perfettamente d'accordo con DRY (non ripeterti). Dà un grande pollice in su alla generazione del codice. Ne risulta un software con una struttura di dati enormemente inferiore a quella tipica delle applicazioni moderne.

Cerca di rinvigorire l'idea che la via da percorrere sia nell'inventiva e che anche le idee ben accettate debbano essere messe in discussione.

HANDLEs (e il resto di WinAPI) è OOP!

Ma lo sono? Non sono ereditabili, non sono certamente sostituibili, mancano di classi ben definite ... Penso che non siano molto "OOP".

Hai mai creato una finestra usando WinAPI? Quindi dovresti sapere che definisci una classe ( RegisterClass), ne crei un'istanza ( CreateWindow), chiami metodi virtuali ( WndProc) e metodi di classe base ( DefWindowProc) e così via. WinAPI prende anche la nomenclatura da SmallTalk OOP, chiamando i metodi "messaggi" (Window Window).

I manici potrebbero non essere ereditabili, ma poi c'è finalin Java. A loro non manca una classe, sono un segnaposto per la classe: ecco cosa significa la parola "maneggiare". Guardando architetture come MFC o .NET WinForms è immediatamente ovvio che, tranne per la sintassi, nulla è molto diverso da WinAPI.

Sì, OOP non ha risolto tutti i nostri problemi, mi dispiace per quello. Stiamo comunque lavorando a SOA che risolverà tutti questi problemi.

OOP si presta bene alla programmazione di strutture informatiche interne come "widget" della GUI, dove ad esempio SelectList e TextBox possono essere sottotipi di Item, che ha metodi comuni come "sposta" e "ridimensiona".

Il problema è che il 90% di noi lavora nel mondo degli affari in cui stiamo lavorando con concetti di business come fattura, dipendente, lavoro, ordine. Questi non si prestano così bene a OOP perché gli "oggetti" sono più nebulosi, soggetti a modifiche in base alla reingegnerizzazione aziendale e così via.

Il caso peggiore è quando OO viene applicato con entusiasmo ai database, compresi i grandiosi "miglioramenti" di OO ai database SQL, che sono giustamente ignorati, tranne dai nomi dei database che ritengono che debbano essere il modo giusto di fare le cose perché sono più recenti.

Nella mia esperienza di revisione del codice e progettazione di progetti che ho passato, il valore di OOP non è pienamente realizzato perché molti sviluppatori non hanno correttamente concettualizzato il modello orientato agli oggetti nelle loro menti. Quindi non programmano con il design OO, molto spesso continuano a scrivere un codice procedurale top-down che rende le classi un design piuttosto piatto . (se puoi persino chiamare quel "design" in primo luogo)

È piuttosto spaventoso osservare come i piccoli colleghi sappiano cosa siano una classe o un'interfaccia astratte, per non parlare della corretta progettazione di una gerarchia ereditaria per soddisfare le esigenze aziendali.

Tuttavia, quando è presente un buon design OO, è solo pura gioia leggere il codice e vederlo naturalmente inserirsi in componenti / classi intuitivi. Ho sempre percepito l'architettura e il design del sistema come progettare i vari reparti e lavori del personale in un'azienda - tutti sono lì per compiere un certo lavoro nel grande schema delle cose, emettendo la sinergia necessaria per spingere l'organizzazione / sistema in avanti.

Questo, ovviamente, è abbastanza raro purtroppo. Come il rapporto tra oggetti fisici meravigliosamente progettati e oggetti orribilmente progettati nel mondo, lo stesso si può dire praticamente dell'ingegneria e della progettazione del software. Avere a disposizione i buoni strumenti non conferisce necessariamente buone pratiche e risultati.

Forse un cofano, un grembo o un albero non è una sedia ma sono tutti ISTABILI.

Penso che quelle cose del mondo reale siano oggetti

Tu fai?

Quali metodi ha una fattura? Oh aspetta. Non può pagare se stesso, non può inviare se stesso, non può confrontarsi con gli articoli che il venditore ha effettivamente consegnato. Non ha alcun metodo; è totalmente inerte e non funzionale. È un tipo di record (una struttura, se preferisci), non un oggetto.

Allo stesso modo le altre cose che menzioni.

Solo perché qualcosa è reale non lo rende un oggetto nel senso OO della parola. Gli oggetti OO sono un peculiare accoppiamento di stato e comportamento che possono agire da soli. Non è qualcosa che è abbondante nel mondo reale.

Ho scritto il codice OO negli ultimi 9 anni circa. Oltre a usare la messaggistica, è difficile per me immaginare un altro approccio. Il vantaggio principale che vedo è totalmente in linea con quanto affermato da CodingTheWheel: modularizzazione. OO mi porta naturalmente a costruire le mie applicazioni da componenti modulari che hanno interfacce pulite e responsabilità chiare (cioè codice liberamente accoppiato, altamente coeso con una chiara separazione delle preoccupazioni).

Penso che il punto in cui si rompe OO sia quando le persone creano erirarchie di classe profondamente annidate. Questo può portare a complessità. Tuttavia, incorporare la fictionalità comune in una classe base, quindi riutilizzare che in altre classi discendenti è una cosa profondamente elegante, IMHO!

In primo luogo, le osservazioni sono piuttosto sciatte. Non ho dati sulla produttività del software e non ho buone ragioni per credere che non stia aumentando. Inoltre, poiché ci sono molte persone che abusano di OO, un buon uso di OO non causerebbe necessariamente un miglioramento della produttività anche se OO fosse la cosa più grande dal burro di arachidi. Dopotutto, un chirurgo cerebrale incompetente è probabilmente peggio di niente, ma uno competente può essere prezioso.

Detto questo, OO è un modo diverso di organizzare le cose, allegando codice procedurale ai dati piuttosto che far funzionare il codice procedurale sui dati. Questa dovrebbe essere almeno una piccola vittoria da sola, poiché ci sono casi in cui l'approccio OO è più naturale. Dopotutto, nulla impedisce a nessuno di scrivere un'API procedurale in C ++, quindi l'opzione di fornire oggetti rende il linguaggio più versatile.

Inoltre, c'è qualcosa che OO fa molto bene: consente al vecchio codice di chiamare automaticamente il nuovo codice, senza modifiche. Se ho un codice che gestisce le cose proceduralmente e aggiungo un nuovo tipo di cose simili ma non identiche a una precedente, devo cambiare il codice procedurale. In un sistema OO, eredito la funzionalità, cambio ciò che mi piace e il nuovo codice viene automaticamente utilizzato a causa del polimorfismo. Ciò aumenta la località dei cambiamenti e questa è una buona cosa.

Il rovescio della medaglia è che un buon OO non è gratuito: richiede tempo e sforzi per impararlo correttamente. Dal momento che è una parola d'ordine importante, ci sono molte persone e prodotti che lo fanno male, solo per il gusto di farlo. Progettare un'interfaccia di buona classe non è più semplice di una buona API procedurale, e ci sono tutti i tipi di errori facili da fare (come le gerarchie di classi profonde).

Pensalo come un diverso tipo di strumento, non necessariamente generalmente migliore. Un martello oltre a un cacciavite, per esempio. Forse alla fine usciremo dalla pratica dell'ingegneria del software sapendo quale chiave usare per martellare la vite.

@Sean

Tuttavia, incorporare la fictionalità comune in una classe base, quindi riutilizzare che in altre classi discendenti è una cosa profondamente elegante, IMHO!

Ma gli sviluppatori "procedurali" lo fanno da decenni comunque. La sintassi e la terminologia potrebbero differire, ma l'effetto è identico. C'è di più in OOP oltre a "riutilizzare funzionalità comuni in una classe base", e potrei persino spingermi fino al punto di dire che è difficile da descrivere come OOP; chiamare la stessa funzione da diversi bit di codice è una tecnica vecchia quanto la sottoprocedura stessa.

@Konrad

OOP può essere imperfetto e certamente non è un proiettile d'argento ma rende le applicazioni su larga scala molto più semplici perché è un ottimo modo per ridurre le dipendenze

Questo è il dogma. Non vedo ciò che rende OOP significativamente migliore in questo senso rispetto alla programmazione procedurale del vecchio. Ogni volta che faccio una chiamata di procedura mi sto isolando dalle specifiche dell'implementazione.

Per me, c'è molto valore nella sintassi OOP stessa. L'uso di oggetti che tentano di rappresentare cose reali o strutture di dati è spesso molto più utile del tentativo di usare un gruppo di diverse funzioni piatte (o "fluttuanti") per fare la stessa cosa con gli stessi dati. C'è un certo "flusso" naturale verso le cose con una buona OOP che ha più senso leggere, scrivere e mantenere a lungo termine.

Non importa che una fattura non sia in realtà un "oggetto" con funzioni che può svolgere da sola: l'istanza dell'oggetto può esistere solo per eseguire funzioni sui dati senza dover sapere quale tipo di dati è effettivamente presente. La funzione "invoice.toJson ()" può essere chiamata con successo senza dover sapere che tipo di dati è "fattura" - il risultato sarà Json, non importa se proviene da un database, XML, CSV o anche un altro oggetto JSON . Con le funzioni procedurali, all'improvviso devi saperne di più sui tuoi dati e finire con funzioni come "xmlToJson ()", "csvToJson ()", "dbToJson ()", ecc. Alla fine diventa un casino completo e un ENORME mal di testa se si modifica il tipo di dati sottostante.

Il punto di OOP è nascondere l'implementazione effettiva sottraendola. Per raggiungere questo obiettivo, è necessario creare un'interfaccia pubblica. Per semplificare il tuo lavoro durante la creazione di tale interfaccia pubblica e mantenere le cose ASCIUTTE, devi utilizzare concetti come classi astratte, eredità, polimorfismo e modelli di progettazione.

Quindi, per me, il vero obiettivo prioritario di OOP è semplificare la manutenzione e le modifiche future del codice. Ma anche oltre, può davvero semplificare molto le cose se fatto correttamente in modi che il codice procedurale non potrebbe mai. Non importa se non corrisponde al "mondo reale" - la programmazione con il codice non interagisce comunque con gli oggetti del mondo reale. OOP è solo uno strumento che semplifica e velocizza il mio lavoro: ci proverò ogni giorno.

@CodingTheWheel

Ma nella misura in cui OOP è stata una perdita di tempo, direi che è a causa della mancanza di formazione del programmatore, aggravata dalla ripida curva di apprendimento dell'apprendimento di una mappatura OOP specifica della lingua. Alcune persone "ottengono" OOP e altre non lo faranno mai.

Non so se è davvero sorprendente, però. Penso che approcci tecnicamente validi (LSP sia la cosa ovvia) rendano difficile da usare , ma se non utilizziamo tali approcci rende comunque il codice fragile e inestensibile (perché non possiamo più ragionare su di esso). E penso che i risultati controintuitivi che OOP ci portano a rendere sorprendente il fatto che le persone non lo raccolgano.

Più significativamente, dal momento che il software è già fondamentalmente troppo difficile da scrivere in modo affidabile e accurato per gli esseri umani normali, dovremmo davvero esaltare una tecnica che viene costantemente insegnata male e sembra difficile da imparare? Se i benefici fossero chiari, potrebbe valere la pena perseverare nonostante la difficoltà, ma questo non sembra essere il caso.

@Jeff

Relativamente alla semplice programmazione procedurale, il primo principio fondamentale di OOP è la nozione di occultamento e incapsulamento delle informazioni. Questa idea porta alla nozione della classe che separa l'interfaccia dall'implementazione.

Qual è l'implementazione più nascosta: gli iostreams di C ++ o FILE * di C?

Penso che l'uso di oggetti di contesto opachi (HANDLEs in Win32, FILE * s in C, per nominare due esempi ben noti: l'inferno, HANDLE vive dall'altra parte della barriera in modalità kernel, e in realtà non si ottiene molto più incapsulato di quello) si trova anche nel codice procedurale; Faccio fatica a vedere come questo sia qualcosa di particolare per OOP.

Suppongo che possa essere una parte del motivo per cui sto lottando per vedere i benefici: le parti che sono ovviamente buone non sono specifiche per OOP, mentre le parti che sono specifiche per OOP non sono ovviamente buone! (questo non vuol dire che sono necessariamente cattivi, ma piuttosto che non ho visto le prove che sono ampiamente applicabili e costantemente vantaggiosi).

Nell'unico blog di sviluppo che ho letto, da quel ragazzo Joel-On-Software-Founder-of-SO, ho letto molto tempo fa che OO non porta ad aumenti di produttività. La gestione automatica della memoria lo fa. Freddo. Chi può negare i dati?

Credo ancora che OO sia non-OO come programmare con le funzioni è programmare tutto in linea.

(E dovrei sapere, come ho iniziato con GWBasic.) Quando si refactoring il codice per usare le funzioni, variable2654diventa variable3il metodo in cui ci si trova. O, meglio ancora, ha un nome che si può capire e se la funzione è breve , si chiama value ed è sufficiente per la piena comprensione.

Quando il codice senza funzioni diventa codice con metodi, puoi eliminare miglia di codice.

Quando si refactoring del codice per essere veramente OO, b, c, q, e Zdiventare this, this, thise this. E poiché non credo nell'uso della thisparola chiave, puoi eliminare miglia di codice. In realtà, puoi farlo anche se lo usi this.

Non penso che OO sia una metafora naturale.

Non penso che il linguaggio sia una metafora naturale, né penso che gli "odori" di Fowler siano meglio di dire "questo codice ha un cattivo sapore". Detto questo, penso che OO non riguardi metafore naturali e le persone che pensano che gli oggetti appena spuntati su di te non abbiano sostanzialmente ragione. Definisci l'universo degli oggetti, e gli universi degli oggetti migliori danno come risultato un codice più breve, più facile da capire, che funziona meglio o tutti questi (e alcuni criteri che sto dimenticando). Penso che le persone che usano gli oggetti naturali del cliente / dominio come oggetti di programmazione non abbiano il potere di ridefinire l'universo.

Ad esempio, quando si esegue un sistema di prenotazione di una compagnia aerea, ciò che si chiama una prenotazione potrebbe non corrispondere affatto a una prenotazione legale / commerciale.

Alcuni dei concetti di base sono strumenti davvero interessanti

Penso che la maggior parte della gente esageri con quella cosa "quando hai un martello, sono tutti chiodi". Penso che l'altro lato della medaglia / specchio sia altrettanto vero: quando hai un gadget come il polimorfismo / eredità, inizi a trovare usi dove si adatta come un guanto / calzino / lenti a contatto. Gli strumenti di OO sono molto potenti. Penso che l'ereditarietà singola sia assolutamente necessaria affinché le persone non si lascino trasportare, nonostante il mio software multi-ereditarietà.

Qual è il punto di OOP?

Penso che sia un ottimo modo per gestire una base di codice assolutamente enorme. Penso che ti permetta di organizzare e riorganizzare il tuo codice e ti dia un linguaggio per farlo (oltre al linguaggio di programmazione in cui stai lavorando), e modularizza il codice in un modo abbastanza naturale e di facile comprensione.

OOP è destinato a essere frainteso dalla maggior parte degli sviluppatori

Questo perché è un processo che apre gli occhi come la vita: capisci OO sempre di più con l'esperienza e inizi a evitare determinati schemi e ad impiegarne altri man mano che diventi più saggio. Uno dei migliori esempi è che smetti di usare l'ereditarietà per le classi che non controlli e preferisci invece il modello Facciata .

Per quanto riguarda il tuo mini-saggio / domanda

Volevo menzionare che hai ragione. La riusabilità è un sogno irrealizzabile, per la maggior parte. Ecco una citazione di Anders Hejilsberg sull'argomento (geniale) da qui :

Se chiedi ai programmatori principianti di scrivere un controllo calendario, spesso pensano a se stessi: "Oh, scriverò il miglior controllo calendario del mondo! Sarà polimorfico rispetto al tipo di calendario. Avrà displayer, e munger, e questo, quello e l'altro. " Devono spedire un'applicazione di calendario tra due mesi. Hanno messo tutta questa infrastruttura nel controllo e poi hanno trascorso due giorni a scrivere un'applicazione scadente del calendario su di essa. Penseranno: "Nella prossima versione dell'applicazione, farò molto di più".

Una volta che iniziano a pensare a come implementeranno effettivamente tutte queste altre concretizzazioni del loro disegno astratto, tuttavia, si scopre che il loro disegno è completamente sbagliato. E ora si sono dipinti in un angolo e devono buttare via tutto. L'ho visto ancora e ancora. Sono fermamente convinto di essere minimalista. A meno che tu non risolva effettivamente il problema generale, non provare a creare un framework per risolverne uno specifico, perché non sai come dovrebbe apparire quel framework.

Hai mai creato una finestra usando WinAPI?

Più volte di quanto mi importi di ricordare.

Quindi dovresti sapere che definisci una classe (RegisterClass), ne crei un'istanza (CreateWindow), chiami metodi virtuali (WndProc) e metodi di classe base (DefWindowProc) e così via. WinAPI prende anche la nomenclatura da SmallTalk OOP, chiamando i metodi "messaggi" (Window Window).

Quindi saprai anche che non invia messaggi per conto suo, il che è un grande vuoto. Ha anche una sottoclasse scadente.

I manici potrebbero non essere ereditabili, ma poi c'è un finale in Java. A loro non manca una classe, sono un segnaposto per la classe: ecco cosa significa la parola "maneggiare". Guardando architetture come MFC o .NET WinForms è immediatamente ovvio che, fatta eccezione per la sintassi, nulla è molto diverso da WinAPI.

Non sono ereditabili né nell'interfaccia né nell'implementazione, sono minimamente sostituibili e non sono sostanzialmente diversi da ciò che i programmatori procedurali hanno fatto da sempre.

È davvero così? I pezzi migliori di OOP sono solo ... codice procedurale tradizionale? Questo è il grosso problema?

Sono completamente d'accordo con la risposta di InSciTek Jeff , aggiungerò solo i seguenti perfezionamenti:

• Nascondimento e incapsulamento delle informazioni: critico per qualsiasi codice gestibile. Può essere fatto facendo attenzione in qualsiasi linguaggio di programmazione, non richiede funzionalità OO, ma farlo renderà il tuo codice leggermente simile a OO.
• Ereditarietà: esiste un dominio di applicazione importante per il quale tutte quelle relazioni OO sono un tipo e contengono una corrispondenza perfetta: le interfacce utente grafiche. Se provi a creare GUI senza il supporto del linguaggio OO, finirai comunque per creare funzionalità simili a OO, ed è più difficile e più soggetto a errori senza supporto del linguaggio. Glade (recentemente) e X11 Xt (storicamente) per esempio.

L'uso di funzionalità OO (in particolare gerarchie astratte profondamente annidate), quando non ha senso, è inutile. Ma per alcuni domini applicativi, c'è davvero un punto.

Credo che la qualità più vantaggiosa di OOP sia il nascondimento / gestione dei dati. Tuttavia, ci sono MOLTI esempi in cui OOP viene utilizzato in modo improprio e penso che sia qui che entra in gioco la confusione.

Solo perché puoi trasformare qualcosa in un oggetto non significa che dovresti. Tuttavia, se ciò renderà il tuo codice più organizzato / più facile da leggere, allora dovresti assolutamente farlo.

Un ottimo esempio pratico in cui OOP è molto utile è con una classe di "prodotto" e oggetti che utilizzo sul nostro sito Web. Poiché ogni pagina è un prodotto e ogni prodotto ha riferimenti ad altri prodotti, può diventare molto confuso su quale prodotto si riferiscono ai dati che hai. Questa variabile "strURL" è il collegamento alla pagina corrente o alla home page o alla pagina delle statistiche? Sicuramente potresti creare tutti i tipi di variabili diverse che fanno riferimento alle stesse informazioni, ma proCurrentPage-> strURL, è molto più facile da capire (per uno sviluppatore).

Inoltre, allegare funzioni a quelle pagine è molto più pulito. Posso fare proCurrentPage-> CleanCache (); Seguito da proDisplayItem-> RenderPromo (); Se avessi appena chiamato quelle funzioni e supponessi che i dati attuali fossero disponibili, chissà che tipo di male si sarebbe verificato. Inoltre, se dovessi trasferire le variabili corrette in tali funzioni, tornerò al problema di disporre di tutti i tipi di variabili per i diversi prodotti.

Invece, usando gli oggetti, tutti i dati e le funzioni dei miei prodotti sono belli, puliti e facili da capire.

Però. Il grosso problema con OOP è quando qualcuno crede che TUTTO dovrebbe essere OOP. Questo crea molti problemi. Ho 88 tabelle nel mio database. Ho solo circa 6 lezioni e forse dovrei averne circa 10. Sicuramente non ho bisogno di 88 lezioni. La maggior parte delle volte l'accesso diretto a tali tabelle è perfettamente comprensibile nelle circostanze in cui lo uso e OOP renderebbe effettivamente più difficile / noioso arrivare alla funzionalità principale di ciò che sta accadendo.

Credo che un modello ibrido di oggetti sia utile e procedurale in cui la pratica sia il metodo di codifica più efficace. È un peccato che abbiamo tutte queste guerre di religione in cui le persone sostengono di usare un metodo a spese degli altri. Sono entrambi bravi ed entrambi hanno il loro posto. Il più delle volte, ci sono usi per entrambi i metodi in ogni progetto più grande (in alcuni progetti più piccoli, un singolo oggetto o alcune procedure potrebbero essere tutto ciò di cui hai bisogno).

Non mi interessa il riutilizzo tanto quanto la leggibilità. Quest'ultimo significa che il codice è più facile da modificare. Questo vale da solo in oro nell'arte di costruire software.

E OO è un modo dannatamente efficace per rendere leggibili i tuoi programmi. Riutilizzo o nessun riutilizzo.

"Il mondo reale non è" OO ","

Veramente? Il mio mondo è pieno di oggetti. Ne sto usando uno adesso. Penso che avere un modello di "oggetti" software, gli oggetti reali potrebbe non essere una cosa così brutta.

I progetti OO per cose concettuali (come Windows, non le finestre del mondo reale, ma i pannelli di visualizzazione sul monitor del mio computer) spesso lasciano molto a desiderare. Ma per cose del mondo reale come fatture, ordini di spedizione, richieste di risarcimento assicurativo e quant'altro, penso che quelle cose del mondo reale siano oggetti. Ho una pila sulla mia scrivania, quindi devono essere reali.

Il punto di OOP è dare al programmatore un altro mezzo per descrivere e comunicare una soluzione a un problema nel codice a macchine e persone. La parte più importante di ciò è la comunicazione alle persone. OOP consente al programmatore di dichiarare cosa significano nel codice attraverso regole applicate nel linguaggio OO.

Contrariamente a molti argomenti su questo argomento, i concetti OOP e OO sono diffusi in tutto il codice, incluso il codice in linguaggi non OOP come C. Molti programmatori avanzati non OO approssimano le caratteristiche degli oggetti anche in linguaggi non OO.

Avere OO integrato nel linguaggio offre semplicemente al programmatore un altro mezzo di espressione.

La maggior parte della scrittura del codice non è la comunicazione con la macchina, quella parte è facile, la maggior parte è la comunicazione con i programmatori umani.