Quando è più adatto l'OOP?[Chiuso]

Question

Da quando ho iniziato a studiare la programmazione orientata agli oggetti, ho letto spesso articoli/blog che affermavano che le funzioni sono migliori o che non tutti i problemi dovrebbero essere modellati come oggetti.Dalle tue avventure personali di programmazione, quando pensi che un problema possa essere risolto meglio dall'OOP?

Answer 1

Non c'è una regola dura e veloce.Un problema viene risolto meglio con l'OOP quando sei più bravo a risolvere i problemi e a pensare con una mentalità OO.L'orientamento agli oggetti è solo un altro strumento che è emerso cercando di rendere l'informatica uno strumento migliore per risolvere i problemi.

Tuttavia, può consentire un migliore riutilizzo del codice e può anche portare a un codice più ordinato.Ma molto spesso queste qualità altamente lodate sono, in realtà, di scarso valore reale.L'applicazione di tecniche OO a un'applicazione funzionale esistente potrebbe davvero causare molti problemi.L'abilità sta nell'apprendere molte tecniche diverse e nell'applicare quella più appropriata al problema in questione.

L'OO viene spesso citato come una soluzione tipo Nirvana per lo sviluppo del software, tuttavia in molti casi non è appropriato applicarlo al problema in questione.Molto spesso ciò può portare a un'ingegnerizzazione eccessiva di un problema per raggiungere la soluzione perfetta, quando spesso non è realmente necessario.

In sostanza, l'OOP non è realmente programmazione orientata agli oggetti, ma mappa il pensiero orientato agli oggetti su un linguaggio di programmazione in grado di supportare le tecniche OO.Le tecniche OO possono essere supportate da linguaggi che non sono intrinsecamente OO ed esistono tecniche che è possibile utilizzare all'interno dei linguaggi funzionali per trarne vantaggio.

Ad esempio, sviluppo software OO da circa 20 anni, quindi tendo a pensare in termini OO quando risolvo i problemi, indipendentemente dalla lingua in cui scrivo.Attualmente sto implementando il polimorfismo utilizzando Perl 5.6, che non lo supporta nativamente.Ho scelto di farlo perché renderà la manutenzione e l'estensione del codice un semplice compito di configurazione, piuttosto che un problema di sviluppo.

Non sono sicuro che questo sia chiaro.Ci sono persone che sono dure nella corte OO, e ci sono persone che sono dure nella corte Funzionale.E poi ci sono persone che le hanno provate entrambe e cercano di trarre il meglio da ognuna.Nessuno dei due è perfetto, ma entrambi hanno alcune caratteristiche molto buone che puoi utilizzare indipendentemente dalla lingua.

Se stai cercando di imparare l'OOP, non concentrarti solo sull'OOP, ma prova a utilizzare l'analisi orientata agli oggetti e i principi generali dell'OO per l'intero spettro della soluzione del problema.

Answer 2

Sono un veterano, ma ho programmato anche OOP per molto tempo.Personalmente sono contrario all'uso dell'OOP solo per usarlo.Preferisco che gli oggetti abbiano ragioni specifiche per esistere, che modellino qualcosa di concreto e che abbiano un senso.

Il problema che ho con molti dei nuovi sviluppatori è che non hanno idea delle risorse che consumano con il codice che creano.Quando si ha a che fare con una grande quantità di dati e si accede ai database, il modello a oggetti "perfetto" può essere la cosa peggiore che si possa fare per prestazioni e risorse.

La mia conclusione è che se ha senso come oggetto, programmalo come oggetto, purché si consideri l'impatto su prestazioni/risorse dell'implementazione del modello a oggetti.

Answer 3

Penso che si adatti meglio quando si modella qualcosa di coeso con lo stato e le azioni associate su quegli stati.Immagino che sia un po' vago, ma non sono sicuro che ci sia una risposta perfetta qui.

L'aspetto positivo dell'OOP è che ti consente di incapsulare e astrarre dati e informazioni, il che è un vero vantaggio nella costruzione di un sistema di grandi dimensioni.Puoi fare lo stesso con altri paradigmi, ma sembra che l'OOP sia particolarmente utile in questa categoria.

Dipende anche dalla lingua che stai utilizzando.Se si tratta di un linguaggio con un ricco supporto OOP, probabilmente dovresti usarlo a tuo vantaggio.In caso contrario, potrebbe essere necessario trovare altri meccanismi per scomporre il problema in parti più piccole e facilmente verificabili.

Answer 4

Mi sono venduto a OOP.

Ogni volta che puoi definire un concetto per un problema, probabilmente puoi racchiuderlo in un oggetto.

Il problema con l'OOP è che alcune persone ne hanno abusato e hanno reso il loro codice ancora più difficile da comprendere.Se presti attenzione a ciò che inserisci negli oggetti e a ciò che inserisci nei servizi (classi statiche) trarrai vantaggio dall'utilizzo degli oggetti.

Basta non inserire qualcosa che non appartiene a un oggetto nell'oggetto perché hai bisogno che il tuo oggetto faccia qualcosa di nuovo a cui non avevi pensato inizialmente, esegui il refactoring e trova il modo migliore per aggiungere quella funzionalità.

Answer 5

Esistono 5 criteri per decidere se preferire il codice orientato agli oggetti rispetto al codice basato sugli oggetti, funzionale o procedurale.Ricorda che tutti questi stili sono disponibili in tutte le lingue stili.Tutti questi sono scritti nello stile di "Devo favorire OO in questa situazione?"

Il sistema è molto complesso e ha circa 9k LOC (solo un livello arbitrario).-- Man mano che i sistemi diventano più complessi, i vantaggi ottenuti dall'incapsulamento della complessità aumentano notevolmente.Con OO, a differenza delle altre tecniche, si tende a incapsulare sempre più complessità, il che è molto prezioso a questo livello.Il metodo basato sugli oggetti o procedurale dovrebbe essere favorito prima di questo.(Questo non sta sostenendo un linguaggio particolare, sia chiaro. OO C nella mia mente si adatta a queste caratteristiche più dell'OO C++, un linguaggio con una famigerata reputazione per le astrazioni che perdono e la capacità di mangiare negozi anche con 1 programmatore mediocre/ostinato a pranzo).

Il tuo codice non è operazioni sui dati (ad es.Basato su database o basato su matematica/analisi).Il codice basato su database è spesso rappresentato più facilmente tramite lo stile procedurale.Il codice basato sull'analisi è spesso più semplice da rappresentare in uno stile funzionale.

Il tuo modello è una simulazione di qualcosa (OO eccelle nelle simulazioni).

Stai facendo qualcosa per il quale l'invio di sottotipi basato su oggetti di OO è prezioso (ovvero, devi inviare un messaggio a tutti gli oggetti di un certo tipo e vari sottotipi e ottenere una reazione appropriata, ma diversa da tutti loro) .

La tua app non è multi-thread, soprattutto in un tipo di base di codice con metodo di attività non di lavoro.L'OO è piuttosto problematico nei programmi multithread e richiedono thread diversi per svolgere attività diverse.Se il tuo programma è strutturato con uno o due thread principali e molti thread di lavoro che fanno la stessa cosa, il flusso di controllo confuso dei programmi OO è più facile da gestire, poiché tutti i thread di lavoro saranno isolati in ciò che toccano e possono essere considerati come una sezione monolitica di codice.Considera qualsiasi altro paradigma in realtà.La funzionalità eccelle nel multithreading (la mancanza di effetti collaterali è un enorme vantaggio) e la programmazione basata su oggetti può darti vantaggi con parte dell'incapsulamento di OO, tuttavia con codice procedurale più tracciabile nelle sezioni critiche della tua base di codice.Ovviamente anche il procedurale eccelle in quest'arena.

Answer 6

Alcuni posti in cui OO non è così buono sono quelli in cui hai a che fare con "insiemi" di dati come in SQL.OO tende a rendere più difficili le operazioni basate su insiemi perché non è realmente progettato per prendere in modo ottimale l'intersezione di due insiemi o il superset di due insiemi.

Inoltre, ci sono momenti in cui un approccio funzionale avrebbe più senso, come questo esempio tratto da MSDN:

Consideriamo, ad esempio, la scrittura di un programma per convertire un documento XML in una diversa forma di dati.Anche se sarebbe certamente possibile scrivere un programma C# che analizzi il documento XML e applichi una serie di istruzioni if ​​per determinare quali azioni intraprendere in diversi punti del documento, un approccio probabilmente superiore è scrivere la trasformazione come un foglio di stile estendibile. Programma di trasformazione del linguaggio (XSLT).Non sorprende che XSLT abbia al suo interno una grande vena di funzionalismo

Answer 7

Trovo che sia utile pensare a un dato problema in termini di "cose".

Se si può pensare che il problema abbia una o più "cose", dove ciascuna "cosa" ha un numero di attributi o informazioni che si riferiscono al suo stato e un numero di operazioni che possono essere eseguite su di essa, allora OOP è probabilmente la strada da percorrere!

Answer 8

La chiave per apprendere la programmazione orientata agli oggetti è apprendere il Design Pattern.Imparando a conoscere i modelli di progettazione puoi vedere meglio quando le lezioni sono necessarie e quando non lo sono.Come qualsiasi altra cosa utilizzata nella programmazione, l'uso delle classi e di altre funzionalità dei linguaggi OOP dipende dalla progettazione e dai requisiti.Come gli algoritmi I modelli di progettazione sono un concetto di livello superiore.

Un Design Pattern svolge un ruolo simile a quello degli algoritmi per i linguaggi di programmazione tradizionali.Un modello di progettazione spiega come creare e combinare oggetti per eseguire alcune attività utili.Come i migliori algoritmi, i migliori modelli di progettazione sono sufficientemente generali da poter essere applicati a una varietà di problemi comuni.

Answer 9

Secondo me è più una questione che riguarda te come persona.Alcune persone pensano meglio in termini funzionali e altre preferiscono classi e oggetti.Direi che l'OOP è più adatto quando corrisponde al tuo modello mentale interno (soggettivo) del mondo.

Answer 10

Il codice orientato agli oggetti e il codice procedurale hanno diversi punti di estensibilità.Le soluzioni orientate agli oggetti rendono più semplice l'aggiunta di nuove classi senza modificare le funzioni esistenti (vedere il principio di apertura-chiusura), mentre il codice procedurale consente di aggiungere funzioni senza modificare le strutture dati esistenti.Molto spesso parti diverse di un sistema richiedono approcci diversi a seconda del tipo di cambiamento previsto.

Answer 11

OO consente di posizionare la logica relativa a un oggetto in un unico luogo (la classe o l'oggetto) in modo che possa essere disaccoppiato e semplificarne il debug e la manutenzione.

Quello che ho osservato è che ogni app è una combinazione di OO e codice procedurale, dove il codice procedurale è il collante che lega insieme tutti i tuoi oggetti (per lo meno, il codice nella tua funzione principale).Più puoi trasformare il tuo codice procedurale in OO, più facile sarà mantenerlo.

Answer 12

Perché l'OOP viene utilizzato per la programmazione:

1. La sua flessibilità: l'OOP è davvero flessibile in termini di implementazioni di utilizzo.
2. Può ridurre i codici sorgente di oltre il 99,9%: potrebbe sembrare un'esagerazione, ma è vero.
3. È molto più semplice implementare la sicurezza: sappiamo tutti che la sicurezza è uno dei requisiti vitali quando si tratta di sviluppo web.L'uso della programmazione orientata agli oggetti può facilitare le implementazioni di sicurezza nei tuoi progetti web.
4. Rende la codifica più organizzata: sappiamo tutti che un programma pulito è una codifica pulita.Usare l'OOP invece che procedurale rende le cose più organizzate e sistematizzate (ovviamente).
5. Aiuta il tuo team a lavorare facilmente insieme: so che alcuni di voi hanno avuto/hanno sperimentato progetti di squadra e alcuni di voi sanno che è importante avere lo stesso metodo, implementazioni, algoritmo, ecc. Ecc.

Answer 13

Dipende dal problema:il paradigma OOP è utile nella progettazione di sistemi distribuiti o framework con molte entità che vivono durante le azioni dell'utente (esempio:applicazione web).

Ma se hai un problema di matematica preferirai un linguaggio funzionale (LISP);per sistemi critici per le prestazioni utilizzerai ADA o C, ecc. Ecc.

Il linguaggio OOP è utile perché anch'esso probabilmente utilizza il garbage collector (uso automatico della memoria) nell'esecuzione del programma:tu programmi in C per molto tempo devi debuggare e correggere manualmente un problema di memoria.

Answer 14

L'OOP è utile quando hai delle cose.Una presa, un pulsante, un file.Se termini una classe con er si tratta quasi sempre di una funzione che finge di essere una classe.TestRunner molto probabilmente dovrebbe essere una funzione che esegue test (e probabilmente denominata test di esecuzione).

Answer 15

Personalmente, penso che l'OOP sia praticamente una necessità per qualsiasi applicazione di grandi dimensioni.Non riesco a immaginare di avere un programma con oltre 100.000 righe di codice senza utilizzare l'OOP, sarebbe un incubo di manutenzione e progettazione.

Answer 16

Ti dico quando l'OOP è negativo.

Quando l'architetto scrive codice OOP davvero complicato e non documentato.Lascia a metà del progetto.E molti dei pezzi di codice comuni utilizzati in vari progetti mancano di codice.Grazie a Dio per .NET Reflector.

E l'organizzazione non utilizzava Visual Source Safe o Subversion.

E mi dispiace.2 pagine di codice per accedere sono piuttosto ridicole anche se sono graziosamente OOPed....