Le cose orientate agli oggetti sono davvero così importanti? [chiuso]

La programmazione orientata agli oggetti è veramente brava a nascondere le tue complesse faccende di math dietro a parole facili da capire e rendendo più facile per i lesser tra voi usare effettivamente le cose che hai scritto. Non sostituisce la programmazione funzionale ... ti dà solo un modo davvero semplice per cambiare le implementazioni o aggiungere comportamenti.

Nel tuo esempio di alberi di ricerca binaria randomizzati sopra, cosa succede se ti è stato dato il requisito che in April Fools Day, il Randomizer è stato sostituito con un ordine per distanza dai tre tirapiedi. È molto utile creare StoogeBinaryTree : RandomBinaryTree e sovrascrivere il metodo protected int GetSortOrder (Tree a, Tree b) , quindi il 2 aprile è possibile riportare l'implementazione su RandomBinaryTree senza dover modificare alcun codice.

In un semplice esempio, ho mostrato sia l'aggiunta di piccoli frammenti di comportamento sia la commutazione dell'implementazione ...

Se hai intenzione di fare FP ancora con linguaggi come Haskell ed Erlang che lo fanno bene, non c'è bisogno di bere il refrigerante OOP. FP è molto potente e può fare molto anche nel mondo reale

Detto questo, imparare una lingua OOP non sarebbe una brutta cosa. Comprendere diversi modi di programmare e diverse metodologie funzionerà a tuo favore. Inoltre, se ti sposti da Haskell o Erlang a Java, puoi chiedertelo come mai nel mondo chiunque può lavorare senza un REPL e lambda.

Sembra che tu ti sia concentrato solo sulla soluzione di un singolo problema alla volta, cioè sugli algoritmi di scrittura. Ma considera come scrivere un'applicazione GUI, ad esempio, o qualche altra enorme applicazione che ti richiede di usare molto del tuo algoritmo. In tal caso, conoscere OO sarà essenziale, poiché ti aiuterà a semplificare il codice per renderlo più leggibile e più semplice da utilizzare per altri sviluppatori, ad es. creando una libreria che potrebbe essere caricata come oggetto.

Uno dei modelli di progettazione più importanti nella programmazione orientata agli oggetti è il Pattern di strategia , che nello scenario sopra indicato aiutarti molto. Considera un esempio in cui l'utente ti presenta un input su cui consentire all'utente di eseguire un algoritmo. Questo potrebbe facilmente essere un disordinato se / else o la costruzione di switch / case. Creando un'interfaccia comune per il tuo algoritmo e utilizzando Strategy Pattern, il tuo codice sarebbe molto più flessibile, leggibile, più facile da estendere e quindi più facile da mantenere.

L'approccio orientato agli oggetti ha avuto successo a causa di un aspetto cruciale: ti consente di affrontare sistemi di significativa complessità essenziale senza introdurre troppa complessità accidentale . Questo può essere quasi ignorato quando lavori su sistemi homegrown, ma diventa molto importante quando costruisci sistemi su larga scala.

Gli elementi chiave dell'approccio orientato agli oggetti possono essere spiegati a un programmatore con ampia esposizione alla programmazione procedurale nel giro di pochi giorni, il che ha aiutato la tecnica ad acquisire rapidamente popolarità (questo non vuol dire che tu possa diventare un esperto in un paio di giorni: è simile all'apprendimento degli scacchi: puoi imparare a spostare i tuoi pezzi in meno di dieci minuti, ma ci vogliono anni per padroneggiare il gioco).

Le tecniche di programmazione funzionale stanno acquisendo maggiore importanza con l'introduzione del supporto linguistico per loro nelle lingue tradizionali (lambda e delegati anonimi di C #, lambda di C ++ e persino classi anonimi di Java, in una certa misura). È molto utile comprendere queste tecniche, ma sono progettate per affrontare problemi più localizzati sulla scala tattica . Le tecniche orientate agli oggetti, d'altro canto, rimangono rilevanti nella scala strategica , specialmente nel contesto di team più grandi.

Programmazione funzionale, sarà un'esperienza molto positiva per te, anche se decidi di non continuare. Come puoi leggere da alcune delle risposte qui, molte persone non sanno nemmeno di cosa si tratta.

I concetti di linguaggi funzionali, ad esempio la valutazione pigra e la trasparenza referenziale, sono una cosa molto buona da imparare. Soprattutto se ti piace la ricorsione.

ad esempio:

lenth :: [a] -> Integer
length (x:xs) = 1+length(xs)
length [] = 0

è una funzione haskell molto semplice che ricorre attraverso un elenco e calcola la lunghezza. Se sei interessato a numeri più lunghi di quelli lunghi e vuoi usare liste infinite e altre cose fantasiose, prova la programmazione funzionale.

Come altri hanno già detto, l'orientamento all'oggetto è il paradigma dominante nell'industria. Hai detto che hai lavorato principalmente con programmi che possono essere indirizzati da una manciata di classi, ma in un'applicazione industriale ci sono centinaia o migliaia di casi d'uso che devono essere affrontati e l'orientamento agli oggetti si è dimostrato molto affidabile e modo ampiamente comprensibile per strutturare basi di codice così grandi.

Parli di programmazione funzionale, che è un contendente solido per The Next Big Paradigm, ma FP non è ancora familiare nell'industria. Tanto più che sei un programmatore C ++, dovresti sapere che l'industria può essere conservatrice e il mondo C / C ++, con la sua enfasi sulle prestazioni, è un luogo in cui la natura imperativa dell'hardware è vista come una considerazione molto reale. In generale, i programmatori di sistemi embedded sono estremamente scettici nei confronti di FP, secondo la mia esperienza.

Anche se FP fa diventa un paradigma più dominante nell'industria, è certamente il caso che avrà successo sotto forma di linguaggi ibridi object-functional come F # e Scala e non nella forma di linguaggi FP "puri" come Haskell.

Tutto ciò è dire che, sì, la "roba" orientata agli oggetti è importante per le codebase professionali e la tua carriera.

OO ha guadagnato la trazione perché è stato un grande miglioramento per la gestione della complessità, come prima era anche la programmazione strutturata / procedurale.

I vantaggi dell'utilizzo di OO aumentano all'aumentare delle dimensioni del progetto. Per un programma 1KLOC, non importa molto quale paradigma tu usi, tutti funzioneranno bene. Ma per un programma di 200KLOC +, non c'è semplicemente competizione praticabile per OO. Ciò non significa che non puoi scrivere un programma 200KLOC in C, solo che dovrai essere molto più disciplinato per evitare di finire con un casino che nessuno (nemmeno tu stesso) può capire. Ciò non significa che OO impedirà tale disordine, ma solo che ti semplificherà la vita per impedirlo.

La programmazione funzionale è un paradigma che in qualche modo devia dal modello precedente, perché non è servito a gestire una complessità ancora maggiore di quella di OO, ma ad affrontare un diverso tipo di problemi: la programmazione parallela. Quella fu anche la prima volta che un paradigma di programmazione tentò di farlo: tutti i meccanismi che esistevano prima in OO e / o SP / PP non erano parte del paradigma, ma solo delle entità OS (thread, mutex, ecc.) incapsulato secondo le regole del paradigma.

A questo proposito, FP è molto più naturale delle altre, ma ciò ha il costo di invertire il modo in cui normalmente pensiamo ai problemi. E a causa di ciò, ha una capacità limitata di gestire la stessa complessità alla stessa scala di OO.

La mia ipotesi è che ciò limiterà l'adozione di FP nel prossimo futuro a sistemi molto specializzati, in genere non molto grandi, o sezioni specializzate di sistemi più grandi. E il resto sarà ancora realizzato usando OO. Quale di quelli che hai intenzione di sviluppare (o di conoscere lo sviluppo) determinerà quale dovrebbe essere il tuo obiettivo di apprendimento, IMO.

Though I have heavily used Generic Programming, Templates and so on.

Probabilmente, i modelli sono semplicemente una forma diversa di OOP. Le funzioni virtuali e l'ereditarietà esplicita hanno un caso d'uso specifico, l'intercambiabilità binaria. I modelli sono intercambiabili in fase di compilazione. Tuttavia, al livello più elementare, offrono la stessa funzionalità-astrazione su qualsiasi tipo che offre l'interfaccia corretta. L'uso eccessivo dell'eredità in fase di esecuzione è un odore significativo del codice e, in questo caso, sono d'accordo con te: semplicemente non è necessario per la maggior parte del tempo.

template<typename T> void func(T t) { t(5); }
void func(std::function<void(int)> t) { t(5); }

Questi due frammenti sono effettivamente identici, anche se uno utilizza esclusivamente i modelli e l'altro utilizza l'ereditarietà e le classi di runtime durante l'implementazione. Entrambi si astraggono sulla funzione che stai chiamando. Questo è banalmente ovvio quando si sostituisce T per std::function<void(int)> , ad esempio. L'unica differenza è il momento in cui viene effettuata l'astrazione. La versione template eccelle per le funzioni e std::function è generalmente meglio come variabili membro. Non vuoi dover creare una nuova classe ogni volta che vuoi una nuova richiamata.

OOP non è particolarmente adatto per gli algoritmi. È più destinato a costrutti su larga scala, abbattendo i pezzi del programma. Se stai scrivendo un algoritmo specifico che funziona su dati specifici, è improbabile che tu abbia bisogno di classi.

È facile, ed è grandioso, comporre algoritmi di funzioni. Tuttavia, non appena si arriva oltre, le classi emergono come metodo dominante.

Sì, è importante, per questa singola ragione: capire OOP ti rende un programmatore migliore. Come regola generale: la comprensione ti rende sempre un programmatore migliore.

Va notato che né is-a, né le classi, tanto meno l'ereditarietà ha nulla a che fare con OOP. L'OOP è in realtà il disaccoppiamento attraverso l'indirezione, come formulato dal principio di inversione delle dipendenze . Si può sostenere che questo è anche un aspetto importante della FP. Se studi sia OOP che FP, diventerai sempre più consapevole di essere in realtà due lati di un continuum. Più ampia e profonda è la tua comprensione, meglio diventerai.

Per ottenere una comprensione di OOP, prova Io e forse Smalltalk e Ruby.

Nel mondo dello sviluppo, le lingue sono strumenti, i paradigmi di programmazione sono strumenti e le librerie sono strumenti. Più strumenti hai, più sarai in grado di selezionare lo strumento giusto per il lavoro. In tal modo, sosterrai che impari OO, AOP e la programmazione funzionale, a seconda del tempo.

Il mondo dello sviluppo continua a crescere sempre più grande (in termini di lingue, strutture, ecc.), quindi non puoi aspettarti di imparare tutto. Tuttavia, l'obiettivo di tutte queste innovazioni è quello di aiutare gli sviluppatori a diventare più produttivi (velocità di sviluppo e riusabilità) e di rendere il codice più gestibile (facilità di comprensione, facilità di estensione e modifica).

La cosa migliore che puoi fare è fare un apprendimento mirato e continuo, nella speranza che qualcosa di nuovo che hai appena appreso ti abbia aiutato a completare qualcosa di meglio e più veloce in un modo che non ti saresti mai aspettato.

Ho letto il libro di Steve Jobs e c'è una storia su come Steve ha visto SmallTalk nei laboratori Xerox PARC. Quello era uno dei primi linguaggi OO. Senza OO sarebbe stato orrendo sviluppare qualcosa come una GUI (Graphical User Interface). Con tutti gli input asincroni e la possibilità di passare da un'attività all'altra mentre si lavora con un "oggetto" o un altro.

Quindi, mentre puoi fare molto con un linguaggio funzionale e sicuramente ha i suoi casi d'uso. Quando inizi a gestire sistemi più complessi che interagiscono maggiormente con i problemi del mondo reale, troverai OO come un design superiore.