Sfidanti significativi per OOP

Question

Da quello che ho capito, è il paradigma OOP più comunemente usato per progetti su larga scala. So anche che alcuni sottoinsiemi più piccoli di grandi sistemi utilizzano altri paradigmi (ad esempio SQL, che è dichiarativa), e mi rendo anche conto che a livelli più bassi di calcolo OOP non è realmente fattibile. Ma mi sembra che di solito i pezzi di soluzioni di livello superiore sono quasi sempre messi insieme in modo OOP.

Ci sono scenari in cui un non-OOP paradigma veramente è in realtà un più scelta per una soluzione di larga scala? O è inaudito di questi giorni?

Mi sono chiesto questo sin da quando ho iniziato a studiare CS; è facile avere la sensazione che la programmazione orientata agli oggetti è un po 'il nirvana di programmazione che non sarà mai superato.

Answer 1

A mio parere, la ragione OOP è usato così ampiamente non è tanto che è lo strumento giusto per il lavoro. Penso che sia più che una soluzione può essere descritto al cliente in modo che possano capire.

Una macchina è un veicolo che ha un motore. Ecco la programmazione e mondo reale tutto in uno!

E 'difficile comprendere tutto ciò che può andare bene il mondo della programmazione e reale abbastanza così elegantemente.

Answer 2

Linux è un progetto su larga scala che non è molto OOP. E non avrebbe molto da guadagnare da esso sia.

Credo OOP ha un buon anello ad esso, perché si è associato con le buone pratiche di programmazione come l'incapsulamento, nascondere i dati, il riutilizzo del codice, la modularità et.c. Ma queste virtù non sono affatto unica di OOP.

Answer 3

Si potrebbe avere uno sguardo a Erlang, scritto da Joe Armstrong.

Wikipedia:

  

"Erlang è un general-purpose   concomitante linguaggio di programmazione e   sistema di runtime. Il sottoinsieme sequenziale   di Erlang è un linguaggio funzionale,   con la massima valutazione, singolo   assegnazione e la tipizzazione dinamica ".

Joe Armstrong:

  

“Perché il problema con   linguaggi orientati agli oggetti è essi hanno   ottenuto tutto questo ambiente implicita che   portano in giro con loro. voi   voleva una banana, ma quello che hai è stato un   gorilla tenendo la banana e la   intera giungla “.

Answer 4

La promessa di programmazione orientata agli oggetti è il riutilizzo del codice e una più facile manutenzione. Non sono sicuro consegnato. Vedo le cose come dot net come più o meno come le librerie C che abbiamo usato per ottenere fro vari fornitori. È possibile chiamare il riutilizzo del codice che, se si desidera. Per quanto riguarda la manutenzione codice cattivo è cattivo codice. OOP non ha aiutato.

Answer 5

Sono il più grande fan di OOP, e mi alleno tutti i giorni OOP. E 'il modo più naturale di scrivere codice, perché assomiglia alla vita reale.

Anche se, mi rendo conto che la virtualizzazione della programmazione orientata agli oggetti potrebbe causare problemi di prestazioni. Naturalmente questo dipende dal vostro disegno, la lingua e la piattaforma si è scelto (sistemi scritti in linguaggi basati raccolta di immondizia come Java o C # potrebbe prestazioni peggiori rispetto ai sistemi che sono state scritte in C ++, per esempio).

Credo che in sistemi in tempo reale, programmazione procedurale può essere più appropriato.

Answer 6

Si noti che non tutti i progetti che sostengono di essere OOP sono infatti OOP. A volte la maggior parte del codice è di procedura, o il modello di dati è anemica, e così via. ..

Answer 7

Zyx, è scritto, "La maggior parte dei sistemi di utilizzare i database relazionali ..."

Ho paura che non c'è nulla di simile. Il modello relazionale sarà 40 anni il prossimo anno ed è ancora mai stato attuato. Penso che vuoi dire, "database SQL." Si consiglia di leggere nulla da Fabian Pascal per capire la differenza tra un DBMS relazionale e un DBMS SQL.

"... il modello relazionale è di solito scelto per la sua popolarità,"

È vero, è popolare.

"... la disponibilità di strumenti,"

Purtroppo, senza lo strumento principale necessaria:. Un'implementazione del modello relazionale

"sostegno"

Yup, il modello relazionale è il supporto bene, sono sicuro, ma è del tutto supportato da un'implementazione DBMS.

"e il fatto che il modello relazionale è in realtà un concetto matematico,"

Sì, è un concetto matematico, ma non in corso di attuazione, è in gran parte limitata alle torri d'avorio. La teoria delle stringhe è anche un concetto matematico, ma non vorrei implementare un sistema con esso.

In realtà, nonostante è di essere un concetto methematical, non è certo una scienza (come in informatica) perché manca il primo requisito di ogni scienza: che è falsificabile: non c'è alcuna implementazione di un DBMS relazionale contro il quale abbiamo può controllare le sue pretese.

E 'olio di serpente puro.

"... contrariamente a OOP".

E contrariamente a OOP, il modello relazionale non è mai stata attuata.

Compra un libro su SQL e ottenere produttivo.

Lascia il modello relazionale per i teorici improduttivi.

Answer 8

questo e questo . A quanto pare è possibile utilizzare C # con cinque diversi paradigmi di programmazione, C ++ con tre, ecc.

costruzione del software non è simile alla fisica fondamentale. Fisica si sforzano di descrivere la realtà utilizzando paradigmi che possono essere impugnate da nuovi dati e / o teorie sperimentali. La fisica è una scienza che cerca una "verità", in modo che la costruzione del software non è così.

costruzione del software è un attività . Hai bisogno di essere produttiva , vale a dire per raggiungere alcuni obiettivi per cui qualcuno pagherà i soldi. I paradigmi sono usati perché sono utili per software prodotti in modo efficace . Non è necessario a tutti di essere d'accordo. Se lo faccio OOP e sta funzionando bene per me, non mi importa se un paradigma "nuovo" potrebbe potenzialmente essere del 20% più utile a me se ho avuto il tempo e denaro per imparare e poi ripensare l'intera struttura del software I' m lavorando in e riprogettare da zero.

Inoltre, si può utilizzare un altro paradigma e sarò ancora felice, allo stesso modo in cui posso fare soldi in esecuzione di un ristorante cibo giapponese e si possono fare soldi con un cibo messicano ristorante accanto. Non ho bisogno di discutere con voi se il cibo giapponese è meglio di cibo messicano.

Answer 9

Dubito OOP sta andando via in qualunque momento presto, appena si inserisce nostri problemi e modelli mentali fin troppo bene.

Quello che stiamo iniziando a vedere se è approcci multi-paradigma, con idee dichiarative e funzionali incorporati nella progettazione orientata agli oggetti. La maggior parte delle lingue JVM più recenti sono un buon esempio di questo (JavaFX, Scala, Clojure, ecc), così come LINQ e F # su piattaforma .net.

E 'importante notare che non sto parlando di sostituire OO qui, ma di suo completamento.

• JavaFX ha dimostrato che una dichiarativa soluzione va al di là di SQL e XSLT, e può essere utilizzato anche per il legame proprietà ed eventi tra visiva componenti in una GUI

• Per fault tolerant e altamente sistemi concorrenti, funzionale ed è un molto buona misura, come dimostrato dalla Ericsson AXD301 (programmato con Erlang)

Quindi ... come la concorrenza diventa sempre più importante e FP diventa sempre più popolare, immagino che i linguaggi che non supportano questo paradigma soffrirà. Questo include molti che sono attualmente popolari come C ++, Java e Ruby, anche se deve far fronte molto bene JavaScript.

Answer 10

Utilizzando OOP rende il codice più facile da gestire (come in Modifica / aggiornamento / aggiungere nuove funzionalità) e capire. Questo è vero soprattutto con i progetti più grandi. Perché moduli / oggetti incapsulano i loro dati e le operazioni su tali dati è più facile comprendere la funzionalità e il quadro generale.

Il vantaggio di programmazione orientata agli oggetti è che è più facile da discutere (con altri sviluppatori / gestione / cliente) un LogManager o OrderManager, ognuno dei quali comprendono funzionalità specifiche, poi descrivendo 'un gruppo di metodi che scaricano i dati nel file' e 'i metodi che tengono traccia dei dettagli dell'ordine.

Quindi credo che OOP è utile soprattutto con grandi progetti, ma ci sono sempre nuovi concetti di alzare in modo da continuare a ricerca di nuove cose in futuro, valutare e tenere ciò che è utile.

Answer 11

Alla gente piace pensare di varie cose come "oggetti" e classificarle, in modo senza dubbio che la programmazione orientata agli oggetti è così popolare. Tuttavia, ci sono alcune aree in cui OOP non ha acquisito una popolarità più grande. La maggior parte dei sistemi di utilizzare i database relazionali, piuttosto che oggettiva. Anche se i secondi tengono alcuni record importanti e sono migliori per alcuni tipi di attività, il modello relazionale è unsually scelto per la sua popolarità, la disponibilità di strumenti, il supporto e il fatto che il modello relazionale è in realtà un concetto matematico, contrariamente a OOP.

Un altro settore in cui non ho mai visto OOP è il processo di costruzione del software. Tutta la configurazione e rendere gli script sono procedurali, in parte a causa della mancanza del supporto per la programmazione orientata agli oggetti in lingue shell, in parte perché OOP è troppo complesso per tali compiti.

Answer 12

Un po 'controversa opinione da me, ma non trovo OOP, almeno di un genere che è comunemente applicato ora, di essere che utile nella produzione di software più grande scala nel mio settore particolare (VFX , che è in qualche modo simile nell'organizzazione scena e lo stato dell'applicazione come i giochi). Lo trovo molto utile su un mezzo a scala ridotta. Devo essere un po 'attenti qui da quando ho invitato alcuni mob in passato, ma dovrei qualifico che questa è la mia esperienza stretto nel mio particolare tipo di dominio.

La difficoltà che ho spesso trovato è che se si dispone di tutti questi piccoli oggetti concreti incapsulamento dei dati, che ora vogliono tutti parlare gli uni agli altri. Le interazioni tra loro può diventare estremamente complessa, in questo modo (ad eccezione di molto, molto più complesso in un'applicazione reale che abbraccia migliaia di oggetti):

E questo non è un grafico di dipendenza diretta di accoppiamento tanto come "grafico interazione". Ci potrebbe essere astrazioni di dissociare questi oggetti concreti gli uni dagli altri. Foo potrebbe non parlare Bar direttamente. Potrebbe invece comunicare con esso tramite IBar o qualcosa del genere. Questo grafico sarebbe ancora collegarsi al Foo Bar dal momento che, anche se in fase di disaccoppiamento, che ancora parlano tra loro.

E tutto questo la comunicazione tra le piccole e medie oggetti che compongono il loro proprio piccolo ecosistema, se applicato a tutta la scala di una grande base di codice nel mio dominio, può diventare estremamente difficile da mantenere. E diventa così difficile da mantenere, perché è difficile ragionare su ciò che accade con tutte queste interazioni tra gli oggetti rispetto a cose come effetti collaterali.

Invece quello che ho trovato utile è quello di organizzare il codice di base complessiva in sottosistemi, pesanti completamente indipendenti che accedono a un "database" centrale. Ogni sottosistema ingressi e poi trasmette dati. Alcuni altri sottosistemi possono accedere agli stessi dati, ma senza un sistema direttamente parlare tra di loro.

... o questo:

... e ogni singolo sistema non tenta più di incapsulare lo stato. Essa non cerca di diventare il suo ecosistema. Si legge, invece, e scrive i dati nella banca dati centrale.

Naturalmente nella realizzazione di ogni sottosistema, si potrebbe utilizzare una serie di oggetti per aiutare la loro attuazione. Ed è qui che trovo molto utile OOP è nella realizzazione di questi sottosistemi. Ma ciascuno di questi sottosistemi costituisce un relativamente medio progetti su piccola scala, non troppo grande, ed è in quel mezzo a scala ridotta che trovo molto utile OOP.

"catena di montaggio di programmazione" con la conoscenza minima

Questo permette ad ogni sottosistema di concentrarsi solo sul fare la sua cosa con quasi nessuna conoscenza di quello che sta succedendo nel mondo esterno. Uno sviluppatore concentrandosi sulla fisica può semplicemente sedersi con il sottosistema fisica e sanno poco su come il software funziona, tranne che c'è un database centrale da cui può recuperare le cose come componenti in movimento (solo dati) e trasformarli applicando la fisica a tali dati. E che fa il suo lavoro molto semplice e lo rende, così da poter fare quello che sa fare meglio con la conoscenza minima di come funziona tutto il resto. Ingresso centrale di dati e l'uscita dei dati centrale: Questo è tutto ogni sottosistema ha a che fare correttamente per tutto il resto al lavoro. E 'la cosa più vicina che ho trovato nel mio campo a "assemblaggio di programmazione line"dove ogni sviluppatore può fare la sua cosa con conoscenza minima di come funziona il sistema nel suo complesso.

Il test è ancora anche abbastanza semplice a causa della ristretta di ogni sottosistema. Non stiamo più scherno oggetti concreti con iniezione di dipendenza tanto da generare una quantità minima di dati relativi ad un particolare sistema e verificando se il particolare sistema fornisce l'uscita corretta per un dato ingresso. Con così pochi sistemi di prova (solo decine possono costituire un software complesso), si riduce anche il numero di test richiesti sostanzialmente.

rottura incapsulamento

Il sistema si trasforma poi in una conduttura piuttosto piatto trasformare lo stato dell'applicazione centrale attraverso sottosistemi indipendenti che sono praticamente ignari dell'esistenza l'uno dell'altro. Si potrebbe a volte spingere un evento centrale per la banca dati che altri processi di sistema, ma che altro sistema è ancora ignaro di dove l'evento è venuto da. Ho trovato questa è la chiave per affrontare la complessità, almeno nel mio dominio, ed è efficace attraverso un sistema di un'entità componenti.

Ancora assomiglia qualcosa di più vicino alla programmazione procedurale o funzionale alla scala ampia di separare tutti questi sottosistemi e lasciarli lavorare con una minima conoscenza del mondo esterno visto che stiamo rompendo l'incapsulamento, al fine di raggiungere questo obiettivo ed evitare che richiedono sistemi a parlare tra di loro. Quando si esegue lo zoom in, allora si potrebbe trovare la vostra quota di oggetti viene utilizzato per implementare uno di questi sottosistemi, ma su scala più ampia, i sistemi assomiglia qualcosa di diverso da OOP.

Dati globali

Devo ammettere che ero molto titubante circa l'applicazione di ECS in un primo momento ad un progetto architettonico nel mio dominio dal momento che, prima, non era stato fatto prima per le mie conoscenze in concorrenti commerciali popolari (3DS Max, Softimage, ecc) , e in secondo luogo, si presenta come un insieme di dati a livello globale a rotelle.

Ho trovato, tuttavia, che questo non è un grosso problema. Possiamo ancora mantenere in modo molto efficace invarianti, forse anche meglio di prima. Il motivo è dovuto al modo in cui l'ECS organizza tutto in sistemi e componenti. Potete essere certi che un sistema audio non tenterà di mutare una componente di moto, per esempio, nemmeno sotto il hackiest di situazioni. Anche con una squadra mal coordinato, è molto improbabile che l'ECS si degradano in qualcosa in cui è possibile alcuna ragione più su quale accesso sistemi che componente, dal momento che è piuttosto evidente sulla carta e non ci sono praticamente senza ragioni di sorta per un certo sistema per l'accesso un componente non appropriata.

Al contrario spesso rimosso molti degli ex tentazioni per le cose hacky con i dati aperti dal momento che un sacco di cose hacky fatto nel nostro ex base di codice sotto il coordinamento e scricchiolio di perdere tempo è stato fatto nel tentativo affrettate ad astrazioni x-ray e tentare di accedere alle parti interne degli ecosistemi di oggetti. Le astrazioni iniziato a diventare permeabile a causa di persone che, in fretta, cercando di ottenere solo e fare le cose con i dati che volevano l'accesso. Erano fondamentalmente i salti mortali cercando di dati di accesso che portano solo per interfacciarsi disegni degradare rapidamente.

C'è qualcosa di vagamente somigliante incapsulamento ancora solo a causa del modo in cui il sistema è organizzato dal momento che c'è spesso un solo sistema di modifica di un particolare tipo di componenti (due in alcuni casi eccezionali). Ma essi non possiedono tali dati, non forniscono funzioni per recuperare i dati. I sistemi non parlano tra loro. Tutti operano attraverso la banca dati centrale ECS (che è l'unica dipendenza che deve essere iniettato in tutti questi sistemi).

flessibilità e l'estensibilità

Questa è già ampiamente discusso in risorse esterne sui sistemi di entità componenti, ma sono estremamente flessibile ad adattarsi a radicalmente nuove idee di design in hindsight, anche il concetto di rottura quelli come un suggerimento per una creatura che è un mammifero, insetto, e la pianta che germoglia foglie sotto la luce del sole tutto in una volta.

Uno dei motivi è perché non ci sono astrazioni centrali per rompere. Si introducono alcune nuove componenti, se avete bisogno di più dati per questo o semplicemente creare un organismo che stringhe insieme i componenti necessari per una pianta, mammifero, e insetti. I sistemi progettati per processare insetti, mammiferi, e componenti di impianto, allora prendere automaticamente in su e si potrebbe ottenere il comportamento desiderato senza cambiare nulla oltre ad aggiungere una riga di codice per creare un'istanza di un'entità con una nuova combinazione di componenti. Quando avete bisogno di tutta la nuova funzionalità, basta aggiungere un nuovo sistema o modificarne uno esistente.

Quello che non ho trovato così tanto discusso altrove è quanto questo facilita la manutenzione anche in scenari quando non ci sono modifiche di progettazione concetto di rottura che non siamo riusciti ad anticipare. Anche ignorando la flessibilità della ECS, si può davvero semplificare le cose quando il codebase raggiunge una certa scala.

Attivazione oggetti in dati

In una precedente codebase OOP pesanti dove ho visto la difficoltà di mantenere una base di codice più vicino al primo grafico sopra, la quantità di codice necessario esplosa perché il Car analogico in questo schema:

... doveva essere costruito come un sottotipo completamente separato (classe) implementare più interfacce. Così abbiamo avuto un numero esplosiva di oggetti nel sistema: un oggetto separato per le luci puntiformi da luci direzionali, un oggetto separato per una macchina fotografica occhio di pesce da un altro, ecc avuto migliaia di oggetti che implementano poche decine di interfacce astratte in infinite combinazioni.

Quando ho confrontato a ECS, che ha richiesto solo centinaia e siamo stati in grado di fare le stesse cose esatte prima di utilizzare una piccola frazione del codice, perché che ha trasformato l'entità Car analogica in qualcosa che non ha più bisogno della sua classe. Si trasforma in una semplice raccolta di dati dei componenti come un'istanza generalizzata di un solo tipo Entity.

OOP Alternative

Quindi ci sono casi come questo in cui OOP applicato in eccesso a livello più ampio del progetto può iniziare a degradarsi davvero manutenibilità. Al più ampia veduta panoramica del vostro sistema, può aiutare ad appiattirla e non cercare di modellare in modo "profonda" con gli oggetti che interagiscono con gli oggetti che interagiscono con gli oggetti, però astrattamente.

Confrontando i due sistemi ho lavorato in passato e ora, quello nuovo ha più funzioni ma prende centinaia di migliaia di LOC. L'ex richiesto oltre 20 milioni LOC. Naturalmente non è il confronto più equo in quanto la prima aveva un patrimonio enorme, ma se si prende una fetta dei due sistemi che sono funzionalmente del tutto uguali senza il bagaglio legacy (almeno quanto di più vicino alla parità come si potrebbe ottenere), il ECS prende una piccola frazione del codice per fare la stessa cosa, e in parte perché riduce drasticamente il numero di classi esistono nel sistema trasformandole in collezioni (entità) dei dati grezzi (componenti) con sistemi pesanti ad elaborarli invece di una barca di piccole / medie oggetti.

  

Ci sono situazioni in cui un paradigma veramente non-OOP è in realtà una   scelta migliore per una soluzione larga scala? O è inaudito di questi   giorni?

E 'lontano dal inaudito. Il sistema che sto descrivendo sopra, per esempio, è ampiamente utilizzato nei giochi. E 'abbastanza raro nel mio campo (la maggior parte delle architetture nel mio campo sono COM-come con le interfacce puri, e questo è il tipo di architettura ho lavorato in passato), ma ho trovato che scruta sopra a quello che i giocatori stanno facendo quando progettare un'architettura fatta awondo di differenza di essere in grado di creare qualcosa che rimane ancora molto comprensibile a cresce e cresce.

Detto questo, alcune persone considerano ECS per essere un tipo di programmazione orientata agli oggetti per conto suo. Se è così, non assomiglia OOP di un genere la maggior parte di noi potrebbe pensare di, poiché i dati (componenti ed entità per comporre loro) e funzionalità (sistemi) sono separati. Richiede abbandonando incapsulamento a livello di sistema ampio che è spesso considerato uno degli aspetti fondamentali della programmazione orientata agli oggetti.

ad alto livello di codifica

  

Ma mi sembra che di solito i pezzi di soluzioni di livello superiore   sono quasi sempre messo insieme in modo OOP.

Se si riesce a mettere insieme un programma con molto codice di alto livello, allora tende ad essere piuttosto piccole o medie dimensioni per quanto riguarda il codice tua squadra deve mantenere e probabilmente può essere montato in modo molto efficace utilizzando OOP.

Nel mio campo in VFX, spesso siamo costretti a fare cose che sono relativamente di basso livello come il raytracing, elaborazione delle immagini, l'elaborazione in rete, la dinamica dei fluidi, ecc, e non possiamo semplicemente piece questi insieme da prodotti di terze parti dal momento che' re in realtà in competizione più in termini di ciò che possiamo fare al basso livello (gli utenti ottengono più entusiasti di avanguardia, i miglioramenti di rendering di produzione competitivi rispetto, ad esempio, un'interfaccia grafica più bello). Quindi non ci può essere un sacco di codice che vanno dal livello molto basso rimescolamento di bit e byte di codice molto di alto livello che scripters scrivere attraverso linguaggi di scripting embedded.

Interweb della Comunicazione

Ma arriva un punto con una scala abbastanza grande con qualsiasi tipo di applicazione, di alto livello o di basso livello o una combo, che ruota intorno a uno stato di applicazione centrale molto complesso in cui ho trovato che non è più utile per provare per incapsulare tutto in oggetti. In questo modo tende a moltiplicare la complessità e la difficoltà di ragionare su ciò che accade a causa della quantità moltiplicato di interazione che va avanti tra tutto. Non è più diventa così facile da ragionare su migliaia di ecosistemi che parlano tra loro se non c'è un punto di rottura in una scala abbastanza grande dove ci fermiamo modellazione cosa come ecosistemi incapsulati che devono parlare tra loro. Anche se ognuno è singolarmente semplice, tutto preso in nel suo complesso può iniziare a più di sopraffare la mente, e spesso prendere un bel po 'di quello di apportare modifiche e aggiungere nuove funzionalità e le cose di debug e così via, se si provare a girare la progettazione di un intero sistema su larga scala solo intorno principi OOP. Può aiutare a liberarsi di incapsulamento in qualche scala per almeno alcuni domini.

A quel punto non è necessariamente così utile più, per esempio, hanno un sistema di fisica incapsulare i propri dati (altrimenti molte cose potrebbero voler parlare con esso e recuperare i dati così come l'inizializzazione con i dati di input appropriati), ed è lì che ho trovato questa alternativa attraverso ECS in modo utile, dal momento che trasforma il sistema di fisica analogica, e tutti questi sistemi pesanti, in un "trasformatore di database centrale" o un "lettore di database centrale che emette qualcosa di nuovo", che può ora essere ignaro su l'un l'altro. Ogni sistema poi inizia ad assomigliare più come un processo in una pipeline piatta che un oggetto che forma un nodo in un grafico molto complesso di comunicazione.