Il limite del paradigma OOP in un sistema veramente complesso?

Question

ho fatto una domanda in precedenza su dataset vs Business Objects .NET Dataset vs Business Object : Why the debate? Why not combine the two?

e voglio generalizzare la domanda qui: dove è la prova che OOP è davvero adatto a problemi molto complessi? Prendiamo ad esempio un motore di gioco MMO. Io non sono esperto a tutti, ma come ho letto questo articolo, si distingue chiaramente che OOP è ben lungi dall'essere sufficiente:

http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-future-of-mmog-development-part-2/

E conclude: Programmazione ben con Entity Systems è molto vicino alla programmazione con un database relazionale. Non sarebbe irragionevole chiamare ES una forma di "Programmazione orientata alla relazione".

Quindi OOP non sta cercando di sbarazzarsi di qualcosa che è qui per rimanere?

OOP non lineare, relazionale lineare, entrambi necessari a seconda della parte di un sistema, quindi perché provare ad eliminare Relational solo perché non è un oggetto "puro". OOP è un fine da solo?

La mia domanda non è OOP utile. OOP è utile, la mia domanda è piuttosto perché i puristi vogliono fare "puro" OOP?

Answer 1

Come autore del post collegato, ho pensato di inserire un paio di pensieri.

FYI: Ho iniziato seriamente (vale a dire per il lavoro commerciale) utilizzando OOP/ORM/UML nel 1997, e mi ci sono voluti circa 5 anni di utilizzo quotidiano per essere veramente bravo a farlo. A quel punto stavo programmando in lingue ASM e non-OOP per circa 5 anni.

La domanda può essere formulata in modo imperfetto, ma penso che sia una buona domanda chiedersi e indagare - una volta che hai capito come esprimerlo meglio, avrai imparato molto utile su come tutto questo è insieme.

"Quindi OOP non sta cercando di sbarazzarsi di qualcosa che è qui per restare?"

In primo luogo, leggere l'articolo di Bjarne qui: http://www.stroustrup.com/oopsla.pdf

IMHO, nessuno dovrebbe essere insegnato qualsiasi OOP senza leggere che la carta (e ri-lettura dopo che hanno "imparato" OOP). Così tante persone fraintendono ciò con cui hanno a che fare.

IME, molti corsi universitari non insegnano bene OOP; insegnano alla gente come scrivere metodi, classi e come usare gli oggetti. Insegnano male perché si farebbe queste cose, da dove vengono le idee, ecc. Penso che gran parte del cattivo uso provenga da questo: quasi un caso di cieco che guida il cieco (non cieco in "come "per usare OOP, sono semplicemente ciechi nel" perché "usare OOP).

Per citare dal paragrafi finali del documento:

"come sostenete buone tecniche di programmazione e tecniche di progettazione buoni conta più di etichette e parole di ronzio L'idea fondamentale è semplicemente quello di migliorare la progettazione e la programmazione attraverso l'astrazione.. Vuoi nascondere i dettagli, vuoi sfruttare qualsiasi comunanza in un sistema e vuoi renderlo accessibile

Vorrei incoraggiarti a non rendere l'orientamento agli oggetti un termine senza senso. La nozione di oggetto -orientato '' è troppo frequentemente degradato: - equipaggiandolo con buono, - equipaggiandolo con un singolo lingua, o - accettando tutto come orientato agli oggetti.

Ho sostenuto che esistono e devono essere utili tecniche oltre alla programmazione e alla progettazione orientata agli oggetti. Tuttavia, per evitare di essere totalmente frainteso, vorrei sottolineare che non tenterei un progetto serio utilizzando un linguaggio di programmazione che non supportasse almeno la nozione classica di programmazione orientata agli oggetti. Oltre alle strutture che supportano la programmazione orientata agli oggetti, voglio e C++ offre funzionalità che vanno oltre quelle a supporto dell'espressione diretta di concetti e relazioni. "

Ora ... vorrei chiederti ... di tutti i programmatori OOP e progetti OOP che hai visto, quanti di loro può onestamente dire di aver aderito a quello che Bjarne richieste ci

IME, meno della maggioranza

Bjarne afferma che:?.

"L'idea fondamentale è semplicemente migliorare il design e la programmazione attraverso l'astrazione"

... eppure molte persone inventano per se stessi un significato diverso, qualcosa di simile:

"L'idea fondamentale è che OOP è buono, e tutto ciò, non-OOP è inferiore"

programmatori che hanno programmato sequenzialmente con ASM, poi ASM, poi pascal, poi C, poi C++, e sono stati esposti al caos che stava programmando il pre-incapsulamento, e tendono ad avere una migliore comprensione di questa roba. Sanno perché è arrivato OOP, che cosa stava cercando di risolvere.

Stranamente, OOP era non cercando di risolvere ogni problema di programmazione. Chi l'avrebbe mai detto, per dire di come si parla oggi?

Era rivolto a un piccolo numero di problemi che erano estremamente pericolosi quanto più grande è stato il tuo progetto, e che si è rivelato essere un posto tra "buono" e "molto buono" nel risolvere.

Ma anche alcuni di loro non è meglio che semplicemente "buono" nel risolvere; ci sono altri paradigmi che sono meglio ...

Tutto IMHO, ovviamente;)

Answer 2

I sistemi di qualsiasi complessità notevole non sono lineari. Anche se hai lavorato duramente per rendere un sistema un processo lineare, stai ancora facendo affidamento su cose come dischi, memoria e connessioni di rete che possono essere instabili, quindi dovrai ovviare a questo.

Non so che qualcuno pensi che l'OOP sia la risposta definitiva. È solo un modo di affrontare la complessità cercando di mantenere i vari problemi confinati nella sfera più piccola possibile in modo che il danno che fanno quando esplodano sia ridotto al minimo. Il mio problema con la tua domanda è che presuppone la perfezione è possibile. Se lo fosse, potrei essere d'accordo OOP non è necessario. È per me finché qualcuno non mi presenta un modo migliore per minimizzare il numero di errori che faccio.

Answer 3

Quello che cerchiamo di fare è mettere uno stile OO su un sistema relazionale. In C# land questo ci fornisce un sistema fortemente tipizzato in modo che tutto da capo a lato possa essere compilato e testato. Il database ha difficoltà a essere testato, refactorizzato, ecc. OOP ci consente di organizzare la nostra applicazione in strati e hi-kair che la relazionale non consente.

Answer 4

Bene, hai una domanda teorica.

Innanzitutto vorrei essere d'accordo con te sul fatto che OOP non è una soluzione risolutiva. È buono per qualcosa, non va bene per gli altri. Ma ciò non significa che non si riduca. Alcuni sistemi orribilmente complessi ed enormi sono stati progettati usando OOP.

Penso che OOP sia così popolare perché merita di essere. Risolve alcuni problemi piuttosto meravigliosamente, è facile pensare in termini di Oggetti perché possiamo farlo senza riprogrammare noi stessi.

Quindi finché non riusciremo a trovare alternative migliori che funzionino effettivamente nella vita pratica, penso che l'OOP sia una buona idea e lo siano anche i database relazionali.

Answer 5

Non c'è davvero alcun limite a ciò che può fare OOP - proprio come non esiste un limite reale a ciò che C può affrontare, o assemblatore per quella materia. Tutti sono completi di Turing, che è tutto ciò di cui hai veramente bisogno.

OOP offre semplicemente un modo di livello superiore per suddividere il programma, proprio come C è un livello superiore rispetto all'assemblatore.

L'articolo sui sistemi di entità non dice che OO non può farlo - in effetti, sembra che stiano usando OOP per implementare le loro Entità, Componenti, ecc. In qualsiasi dominio complesso ci saranno diversi modi per suddividerlo e, usando OOP, puoi scomporlo a livello dell'oggetto/classe ad un certo punto. Ciò non preclude l'esistenza di quadri concettuali di livello superiore che vengono utilizzati per progettare il sistema OOP.

Answer 6

Il problema non è l'approccio orientato agli oggetti nella maggior parte delle situazioni, il problema è rappresentato dalle prestazioni e dallo sviluppo effettivo dell'hardware sottostante.

Il paradigma OO si avvicina allo sviluppo del software fornendoci una metafora del mondo reale, dove abbiamo concetti che definiscono le proprietà e il comportamento degli oggetti reali accettati e attesi nel mondo. È il modo in cui gli esseri umani modellano le cose e siamo in grado di risolvere la maggior parte dei problemi con esso.

In teoria è possibile definire ogni aspetto di un gioco, sistema o qualsiasi altra cosa utilizzando OO. In pratica, se lo fai, il tuo programma si comporta semplicemente troppo lentamente, quindi il paradigma è incasinato da ottimizzazioni che scambiano la semplicità del modello dalle prestazioni.

In questo modo, i database relazionali non sono orientati agli oggetti, quindi costruiamo uno strato orientato agli oggetti tra il nostro codice e il database ... così facendo hai perso alcune delle prestazioni del database e parte della sua espressività perché, da il punto di vista del paradigma OO un database relazionale è una classe completa, è un oggetto molto complesso che fornisce informazioni.

Dal mio punto di vista OO è un approccio quasi perfetto nel senso teorico della parola, poiché si avvicina al modo in cui noi, gli umani, pensiamo, ma non si adatta bene alle limitate risorse del calcolo sviluppo ... quindi prendiamo scorciatoie. Al e, le prestazioni sono molto più importanti dell'organizzazione teorica o chiarezza, quindi queste scorciatoie diventano standard o pratiche usuali.

Cioè, stiamo adattando il modello teorico ai nostri limiti attuali. Nei tempi del cobol alla fine degli anni '70 l'obiettivo orientato agli oggetti era semplicemente impossibile ... avrebbe implicato molti aspetti e troppe poche prestazioni, quindi abbiamo usato un approccio semplificato, in modo che non avessi oggetti o classe, hai avuto delle variabili .. ma il concetto era, in quel momento, lo stesso. Gruppi di variabili descrivono concetti correlati, proprietà che oggi saranno piedi in un oggetto. Sequenze di controllo basate su un valore di variabile in cui viene utilizzato per sostituire le gerarchie di classi e così via.

Penso che usiamo OOP da molto tempo e continueremo a usarlo per molto tempo. Con il miglioramento delle capacità hardware, saremo in grado di semplificare il modello in modo che diventi più adattabile. Se descrivo perfettamente (quasi) il concetto di un gatto (che implica molto descrivere per molti concetti coinvolti) quel concetto sarà riusabile ovunque ... il problema qui non è, come ho detto, con il paradigma stesso ma con i nostri limiti per implementarlo.

MODIFICA: Per rispondere alla domanda sul perché utilizzare OO puro. Ogni "scienza" vuole avere un modello completo per rappresentare le cose. Abbiamo due modelli fisici per descrivere la natura, uno a livello microscopico e uno per quello macroscopico, e vogliamo averne uno solo perché semplifica le cose che ci fornisce un modo migliore per dimostrare, testare e sviluppare le cose. Con OO si applica lo stesso processo. Non è possibile testare e provare analiticamente un sistema se il sistema non segue un insieme preciso di regole. Se stai cambiando tra i paradigmi di un programma, il tuo programma non può essere analizzato correttamente, deve essere disgiunto in ognuno di essi, analizzato e poi nuovamente analizzato per vedere che le interazioni sono corrette.Diventa molto più difficile capire un sistema perché in effetti hai due o tre sistemi che interagiscono in modi diversi.

Answer 7

Potresti chiarire che cosa stai cercando di confrontare e dimostrare qui? OOP è un paradigma di programmazione, uno dei tanti. Non è perfetto Non è un proiettile d'argento.

Che cosa significa "Programmazione orientata alla relazione"? Data-centric? Bene, Microsoft si stava muovendo verso uno stile di programmazione più incentrato sui dati fino a quando non si sono arresi su Linq2Sql e si sono concentrati completamente sul loro EntityFramework O/RM.

Anche i database relazionali non sono tutto. Esistono molti tipi diversi di architetture di database: database gerarchici, database di rete, database di oggetti ecc. E quelli possono essere anche più efficienti di quelli relazionali. Le relazioni sono così popolari per quasi gli stessi motivi per cui l'OOP è così popolare: è semplice, molto facile da capire e molto spesso abbastanza efficiente.

Answer 8

Ragazzi, non è più la domanda su ORM che OOP? OOP è uno stile di programmazione: la cosa che viene effettivamente confrontata è un database relazionale mappato su oggetti.

OOP è in realtà più che l'ORM! Non è solo l'ereditarietà e il polimorfismo! È una gamma estremamente ampia di modelli di design e soprattutto è il modo in cui pensiamo alla programmazione stessa.

Jorge: è giusto che tu abbia indicato la parte di opitimizzazione: ciò che non hai aggiunto è che questo passaggio dovrebbe essere fatto per ultimo e nel 99% dei casi la parte lenta non è l'OOP.

Ora semplice e semplice: lo stile OOP con tutti i principali aggiunti (codice pulito, utilizzo di schemi di progettazione, non a strutture di ereditarietà profonde e non dimentichiamo test di unità!) È un modo per far capire a più persone cosa hai scritto. Questo a sua volta è necessario per le aziende per mantenere il loro business sicuro. Questo è anche un invito per le piccole squadre ad avere una migliore comprensione con la comunità. È come una metamorfosi comunein aggiunta al linguaggio di programmazione stesso.

Answer 9

Basta leggere l'articolo su Entity Systems, che confronta ES in OOP, ed è in modo flagrante errato su diversi aspetti di OOP. per esempio, quando ci sono 100 istanze di una classe, OOP non impone che ci siano 100 copie dei metodi delle classi caricate in memoria, solo una è necessaria. Tutto ciò che ES vuole essere in grado di fare "meglio" di OOP perché ha "Componenti" e "Sistemi", OOP supporta anche l'uso di interfacce e classi statiche (e/o Singletons).

E OOP si adatta in modo più naturale al mondo reale, come qualsiasi Dominio Problema reale o immaginario, costituito da più elementi fisici e/o non fisici e astrazioni e le relazioni tra loro, possono essere modellati con un design appropriato struttura della classe OOP hiearchical.

Answer 10

È sempre più facile parlare di concetti dal punto di vista dei puristi. Una volta che hai a che fare con un problema di vita reale le cose diventano più complicate e il mondo non è più solo in bianco e nero. Proprio come l'autore dell'articolo è molto preciso nel sottolineare che sono non facendo OOP il "purista OOP" ti dice che OOP è la solo strada da percorrere. La verità è da qualche parte nel mezzo.

Non esiste una risposta singola, purché si comprendano i diversi modi (OOP, sistemi di entità, programmazione funzionale e molti altri) di fare le cose e si può dare una buona ragione per cui si sta scegliendo l'uno sull'altro in qualsiasi data la situazione, è più probabile che tu abbia successo.

Answer 11

Informazioni su Entity Systems. È una concezione interessante ma non porta nulla di veramente nuovo.Ad esempio, si afferma:

OOP sarebbe per ogni Componente avere zero o più metodi, che qualche cosa esterna deve richiamare ad un certo punto. Lo stile ES è per ogni componente che non ha metodi, ma per il sistema in esecuzione continua per eseguire i propri metodi interni su diversi componenti uno alla volta.

Ma non è lo stesso come anti-modello di Martin Fowler chiamato "anemico Domain Model" (che è ampiamente utilizzato al giorno d'oggi, in effetti) link?

Quindi in pratica ES è una "idea sulla carta". Affinché la gente lo accetti, DEVE essere provato con esempi di codice funzionante. Non c'è una sola parola nell'articolo su come implementare questa idea sulla pratica. Nulla di ciò che riguarda i problemi di scalabilità. Nulla ha detto sulla tolleranza d'errore ...

Come per la tua domanda attuale, non vedo come i sistemi di entità descritti nell'articolo possano essere simili ai database relazionali. I database relazionali non hanno "aspetti" descritti nell'articolo. Infatti, relazionale - basato sulla struttura dei dati delle tabelle - è molto limitato quando si tratta di lavorare con dati gerarchici, ad esempio. Più limitato rispetto ad esempio ai database degli oggetti ...

Answer 12

Ironia della sorte, quando la programmazione oo arrivato ha reso molto più facile costruire sistemi più grandi, questo si rifletteva nella rampa in software per mercato .

Per quanto riguarda la scala e la complessità, con un buon design è possibile realizzare sistemi piuttosto complessi. vedi ddd Eric Evans per alcuni schemi principali sulla gestione della complessità in oo.

Tuttavia, non tutti i domini dei problemi sono più adatti a tutte le lingue, se si ha la libertà di scegliere una lingua, scegliere quella adatta al dominio del problema. o costruisci un dsl se è più appropriato.

Siamo ingegneri del software, dopo tutto, a meno che non ci sia qualcuno che ti dice come fare il tuo lavoro, basta usare gli strumenti migliori per il lavoro, o il loro :) scrivere