La programmazione orientata agli oggetti modella realmente il mondo reale? [chiuso]

No, per niente.

Tuttavia è una metodologia che consente di creare una bella astrazione per contenere strutture dati complesse insieme ad alcuni metodi che agiscono sulle strutture dati.

I modelli, di qualsiasi tipo, non modellano il mondo reale, non del tutto.

Modellano le parti selezionate , quelle che sono rilevanti per l'applicazione a portata di mano.

Ciò di cui stai parlando (osservatori, manager, fabbriche, ecc.) è un'infrastruttura che ti aiuta a ottenere l'astrazione giusta e supporta le funzioni richieste come la persistenza.

Che cos'è un modello, comunque:
Un modello è una rappresentazione semplificata utilizzata per spiegare il funzionamento di un sistema o di un evento del mondo reale

Does object oriented programming allow you to model the real world?

Sicuramente SÌ

È quasi impossibile modellare il sistema in modo che corrisponda esattamente al mondo reale.

Do I always have to model the software exactly after the real world?

NO

Avendo detto che puoi modellare tutto ciò non significa che devi modellare tutto. In effetti, l'essenza della modellazione utile è presentare una rappresentazione semplificata. Quanta semplificazione è sufficiente per esprimere l'attuale necessità aziendale, e ciò che deve essere omesso, è un buon equilibrio tra l'utilizzo della tecnica con successo o il perdersi o non utilizzarlo affatto.

Esistono naturalmente entità che non esistono realmente, ma solo attraverso la modellazione possiamo effettivamente concettualizzare bene.

Penso che insegnare che esiste una relazione tra nomi e classi causa fastidiose abitudini di sviluppo che devono essere schiacciate in seguito da un architetto impaziente o da un ingegnere senior.

Ciò che dovrebbe essere insegnato è che le classi modellano gli oggetti astratti, proprio come fa il tuo cervello. Hai un concetto astratto di "macchina" nella tua testa che non si adatta a nessuna particolare macchina fisica, è riutilizzabile, le specifiche implementazioni della macchina possono ereditarlo. Il tuo cervello anche concetti meta-modelli per te. Hai un modello mentale di cosa è il pensiero, che concetto è.

Se insegnassimo le persone a identificare i modelli che stanno già generando nella tua testa, sarebbero molto più preparati a creare software reale.

...The world is richer than what can be expressed with object-oriented syntax.

Consider a few common concepts that people universally use to understand and describe all systems – concepts that do not fit the object mold. The 'before/after' paradigm, as well that of 'cause/effect', and the notion of the 'state of the system' are amongst the most vivid examples. Indeed, the process of 'brewing coffee', or 'assembling a vehicle', or 'landing a rover on Mars' cannot be decomposed into simple objects. Yes, they are being treated that way in OO languages, but that's contrived and counter-intuitive. The sequence of the routine itself – what comes before what under what conditions based on what causality – simply has no meaningful representation in OO, because OO has no concept of sequencing, or state, or cause.

Processes are extremely common in the real world and in programming. Elaborate mechanisms have been devised over the years to handle transactions, workflow, orchestration, threads, protocols, and other inherently 'procedural' concepts. Those mechanisms breed complexity as they try to compensate for the inherent time-invariant deficiency in OO programming. Instead, the problem should be addressed at the root by allowing process-specific constructs, such as 'before/after', 'cause/effect', and, perhaps, 'system state' to be a core part of the language...

fonte citazione: Victoria Livschitz, La prossima mossa nella programmazione

Sì, OO può essere spesso utilizzato per modellare entità del mondo reale.

Even in my business layer I've got classes like observers, managers, factories, etc. which aren't real world objects.

Non confondere lo sviluppo orientato agli oggetti con i modelli di progettazione. L'analisi e la progettazione OO è un mezzo per avvicinarsi alla programmazione del codice gestibile. Accoppiato con un linguaggio OO, i programmatori hanno il potere di creare codice riutilizzabile attraverso i pilastri di OO: incapsulamento, polimorfismo ed ereditarietà.

Per incapsulare un'entità possiamo modellare quell'entità dopo la sua controparte reale. Ad esempio, se abbiamo una chitarra, una classe di chitarra racchiude i comportamenti e le proprietà di una chitarra del mondo reale. Possiamo inoltre astrarre la chitarra come, diciamo, un IInventoryItem per sfruttare il potenziale per il riutilizzo del codice attraverso il polimorfismo e l'ereditarietà.

D'altra parte, potremmo scoprire che una fabbrica di chitarre potrebbe aiutarci a mantenere un insieme di diversi tipi di chitarre. Questo non è a causa di OO. Piuttosto, una fabbrica è un modello di progettazione che ha superato la prova del tempo come mezzo comprovato per creare con successo un codice manutenibile per tale scopo. In altre parole, i programmatori spesso risolvono problemi simili. Quindi abbiamo trovato una soluzione comune per risolverli (non reinventare la ruota).

Ciò non significa che OO debba modellare il mondo reale, né che sia sempre la soluzione ottimale per farlo. Semplicemente, che come regola generale "OO modellando il mondo reale" ha perfettamente senso.

While some objects I create are modelling real world objects, would not pre-OOP code do the same?

Direi di no. OOP lega la relazione tra le cose (proprietà / oggetti) e ciò che possono fare / può essere fatto a loro (metodi), mentre la programmazione procedurale non lo fa (a parte, in piccola parte, quando si usa una tipizzazione rigorosa). Un modello non riguarda solo la definizione di parti e processi discreti, ma definisce anche come si integrano e OOP è particolarmente bravo in questo.

Dipende da quale mondo reale stai parlando.

Jorge Luis Borges ha scritto una storia "Tlön, Uqbar, Orbis Tertius", in cui uno dei popoli residenti sembra percepire il loro mondo reale in modo molto diverso:

[...] the people of the imaginary Tlön [...] hold an extreme form of Berkeleian idealism, denying the reality of the world. Their world is understood "not as a concurrence of objects in space, but as a heterogeneous series of independent acts." One of the imagined languages of Tlön lacks nouns. Its central units are "impersonal verbs qualified by monosyllabic suffixes or prefixes which have the force of adverbs." Borges lists a Tlönic equivalent of "The moon rose above the water": hlör u fang axaxaxas mlö, meaning literally "Upward behind the onstreaming it mooned". [...] In another language of Tlön, "the basic unit is not the verb, but the monosyllabic adjective," which, in combinations of two or more, are noun-forming: "moon" becomes "round airy-light on dark" or "pale-orange-of-the-sky.

(copied from the wikipedia artice about the book)

Per me, il punto non è tanto che il mondo possa essere percepito in modo diverso da quello che facciamo, che è un po 'cliché, ma quella percezione della struttura della realtà stessa dipende dalla lingua che parliamo, sia essa naturale o linguaggio di programmazione. Il Tlönese potrebbe essere molto felice con Lisp, e potrebbe vedere Java (AKA The Kingdom Of Nouns ) come molto innaturale, mentre la maggior parte dei programmatori terran tendono a privilegiare i linguaggi funzionali orientati agli oggetti. Mi piacciono entrambi gli stili, poiché penso che sia principalmente una questione di prospettiva. Alcuni problemi vengono meglio attaccati con funzionalità, altri con tecniche di programmazione orientate agli oggetti. Un buon programmatore guarda sempre a un problema difficile da diverse angolazioni, prima di tentare una soluzione. O, come ha detto Alan Kay: Il punto di vista vale 80 punti IQ .

Quindi, la mia risposta alla tua domanda è: di quale mondo reale stai parlando? E come?

I've seen it commonly repeated the object oriented programming is based on modelling the real world, but is it?

Sì. L'enfasi qui è basata su . OOP non modella il mondo reale (se lo fa, quindi incidentalmente) e non dovrebbe. Ciò che OOP fa è consentire a noi problemi di programmazione dei modelli il modo in cui modelliamo il mondo reale: come un sistema di entità che sono definite attraverso la nostra astrazione del loro comportamento.

Il codice OO di solito non modella il mondo reale - almeno questo non è l'obiettivo, ti consente semplicemente di pensare al tuo codice in un modo che è più naturale, più come il tuo modo di pensare alle cose nel reale mondo - questo è ciò che la citazione sta cercando di dire.

Non modella il nostro mondo, ma modella l'interpretazione umana del nostro mondo. Gli umani separano naturalmente le cose come oggetti. OO è efficace perché consente agli esseri umani di programmare il loro modo di pensare.

OOP potrebbe non essere un modello perfetto del mondo reale e degli oggetti in esso contenuti, ma è una metodologia che aiuta ad affrontare la crescente complessità del software di vita reale. Aiuta anche a scrivere meglio il codice, suddividendolo in parti collegate logicamente.

Mentre i vecchi metodi orientati alle procedure forniranno certamente anche dei risultati, OOP ti aiuta ad arrivarci più velocemente e con relativa facilità, anche quando hai a che fare con grandi e amp; progetti complessi.

L'astrazione e l'incapsulamento aiutano a concentrarsi sul nocciolo del problema mentre nascondono tutti gli impianti idraulici che effettivamente fanno accadere le cose. Ereditarietà e consente di stabilire una relazione significativa e logica tra i vari aspetti del codice. Il polimorfismo promuove il riutilizzo del codice e consente di gestire facilmente le variazioni (la categoria di problemi " quasi lo stesso di un oggetto esistente" che si verifica così frequentemente) ed estendere il codice estendendo la semantica associata a un oggetto.

Ritengo che OOP sia più simile a un aiuto che ti consente di affrontare tutte le complessità di un sistema di vita reale in modo efficace. Quindi, anche se potrebbe non essere un modello molto completo del mondo reale, è abbastanza vicino e ti aiuta a fare le cose, che IMHO è tutto ciò che conta alla fine.

I've seen it commonly repeated the object oriented programming is based on modelling the real world, but is it?

It seems to me that is not true of anything outside of the business layer.

No. Come fai notare, molte delle cose "modellate" in un linguaggio OOP sono concetti astratti come code di messaggi e controller e stack.

Anche nel tuo livello aziendale, non stai ancora modellando "il mondo reale". Supponi di avere una classe di dipendenti. I dipendenti sono anche persone, che sono anche mammiferi, che sono anche animali, che sono anche ... (sbadiglio) I dipendenti hanno i colori preferiti, e indossano certi vestiti e credono certe cose. In breve, esiste una vasta gamma di complessità nel mondo reale che non tentiamo nemmeno di acquisire nella maggior parte dei programmi.

Nella modellazione, ci concentriamo solo sugli aspetti del modello che sono significativi per il compito in questione. Se stiamo progettando un sistema di inserimento orario, probabilmente vorremmo una sorta di classe Employee, ma quella classe non ha bisogno di una proprietà per esprimere il colore preferito del dipendente.

Pertanto, i modelli non dovrebbero tentare (o fingere) di rappresentare completamente il "mondo reale".

While some objects I create are modelling real world objects, would not pre-OOP code do the same? I doubt that OO was the first people to include concepts like Customer in their code bases.

Hai ragione. Se si guardano programmi di grandi dimensioni che non sono OOP, sono spesso ancora organizzati attorno a strutture di dati. Una struttura dati e tutte le funzioni che manipolano sono definite l'una vicino all'altra, per motivi di chiarezza. (Il progetto di sovversione ne è un buon esempio: le strutture e le funzioni dei dati sono precedute da nomi di moduli che è chiaro quali strutture e funzioni sono destinate all'uso tra loro.)

Non sono esperto nella storia dei linguaggi di programmazione, ma immagino che OOP sia nato dall'osservazione casuale che il codice era più chiaro e più facile da capire quando è stato organizzato in questo modo, quindi i progettisti di linguaggi hanno iniziato a progettare linguaggi in cui quel tipo dell'organizzazione è stata applicata più rigorosamente.

La più grande differenza tra OOP e non-OOP è che OOP lega il codice ai dati. Quindi piuttosto che chiamare codice come questo:

verb(noun);

lo facciamo invece:

noun->verb();

Anche se questo può sembrare una differenza grammaticale, la differenza è in realtà nella mentalità. Diamo agli oggetti cosa fare e in genere non ci interessa quale sia lo stato o il funzionamento interno dell'oggetto. Quando descriviamo un oggetto, abbiamo solo bisogno di descrivere la sua interfaccia pubblica per lavorarci sopra.

Does Object Oriented Programming Really Model The Real World?

Non completamente.

Bene, nel mondo reale, affrontiamo problemi reali. Vogliamo risolvere questo problema usando un paradigma che replica il sistema che vogliamo costruire, che diventa il modello.

Ad esempio, se l'applicazione Carrello degli acquisti era il problema, abbiamo entità diverse come

1. Prodotto che è un termine astratto che può avere più membri come libri, gadget, automobili che possono essere nuovamente suddivisi.

2. I Codice fiscale come (Imposta sulle vendite) dipenderebbe da quale posizione il software è implementato in quanto è soggetto a modifiche in base alle politiche governative.

3. Tasse viene considerato in base al fatto che il prodotto sia stato importato insieme ai criteri fiscali.

4. L'utente potrebbe avere un carrello della spesa che ha un elenco di prodotti ecc.

Quindi, come puoi vedere, ci sono problemi reali che stiamo cercando di risolvere, ma modularizzati nel paradigma OOP per renderlo il più vicino possibile al sistema reale.

Penso che tu stia leggendo troppo in ciò che si intende essere una dichiarazione molto prosaica, storica. Molte delle idee di programmazione OO, classi, polimorfismo, funzioni virtuali, ecc. Sono state introdotte nella lingua Simula, negli anni '60 (http://en.wikipedia.org/wiki/Simula). Come suggerisce il nome, Simula è stato progettato per essere un linguaggio per scrivere simulazioni. Quindi storicamente, sì, le idee OO sono state introdotte nel tentativo di modellare il "mondo reale". Se riescono più degli altri stili è una questione di dibattito.

While some objects I create are modelling real world objects, would not pre-OOP code do the same?

La più grande differenza tra OOP e codice pre-OOP è che il primo modella una situazione del mondo reale come un gruppo di entità distinte che interagiscono l'una con l'altra, ciascuna con un "potere" limitato riguardo a ciò che può fare, e anche capace di " reagendo "a eventi esterni con azioni proprie. Quest'ultima modella tutto come una grossa fetta di dati che non fa nulla da solo, mentre il calcolo rappresenta "le cose che accadono" e può influenzarne alcune o tutte.

Che sia meglio modellare il mondo reale o meno, ciò dipende in realtà da quali sfaccettature del mondo stai modellando. Una simulazione fisica, ad esempio, in cui si desidera descrivere gli effetti che, ad esempio, un incendio che si accenderebbe avrebbe negli oggetti che circondano, sarebbe meglio rappresentata da un approccio "tradizionale", poiché sia la luce che il calore sono ben processi definiti che influenzano sia lo stato esterno che quello interno di altri oggetti, e non variano in base al comportamento di ogni particolare oggetto, ma sono influenzati dalle loro proprietà.

D'altra parte, se stai modellando diversi componenti che interagiscono per produrre il comportamento desiderato, trattarli come agenti anziché come cose passive può rendere più facile farlo correttamente senza perdere nulla. Se voglio accendere la TV, premo semplicemente il pulsante, se il cavo di alimentazione è scollegato, TV.turnOn lo controllerà per me. Quindi, non c'è il rischio di trasformare un ingranaggio e dimenticare di trasformare quell'altro che lo sta toccando, dal momento che il pignone stesso (se programmato correttamente) si prenderà cura delle interazioni secondarie che vengono come conseguenza di quella primaria.

But OO is really about how to model things, and that method of modelling doesn't seem inspired by the real world to me.

Credo che abbia più a che fare con il modo in cui noi percepiamo il mondo rispetto a come il mondo sia effettivamente. Si potrebbe obiettare che tutto è solo un mucchio di atomi (o energia, o onde, qualunque cosa), ma questo non ci aiuta a gestire il compito di affrontare i problemi che affrontiamo, con la comprensione dell'ambiente che ci circonda e la previsione di eventi futuri ( o descrivere quelli passati). Quindi creiamo "modelli mentali" del mondo, e spesso questi modelli mentali trovano una corrispondenza migliore con OO rispetto ai dati + processi uno - che probabilmente modellizza "meglio" come funziona realmente il mondo reale.

È anche interessante notare che la maggior parte delle persone pensa a OOP come sinonimo di "OOP classico", in cui tassonomicamente creiamo insiemi e sottoinsiemi di cose e inseriamo senza ambiguità gli oggetti in un insieme molto specifico. È molto utile per creare nuovi tipi riutilizzabili, ma non così grandiosi quando l'entità che stai modellando è praticamente autosufficiente, e mentre avvia le interazioni con altri oggetti raramente, se non mai, è il obiettivo di un'interazione. O peggio, quando ci sono poche (forse solo una) istanza di quell'entità, o le istanze variano selvaggiamente nella composizione, nel comportamento o in entrambi.

Tuttavia, c'è anche "OOP prototipico", in cui un oggetto è descritto selezionando uno simile e elencando gli aspetti in cui differiscono. Suggerirei questo saggio per una buona e non troppo spiegazione tecnica del processo di pensiero (l'intero post è troppo grande, anche per gli standard di Steve Yegge, quindi sto indicando la sezione pertinente: P). Ancora una volta, questa è una buona corrispondenza per i nostri modelli mentali quando immaginiamo istanze sconosciute rispetto a una nota, ma non necessariamente per come il mondo reale "funziona" ... (due mucche sono entità completamente distinte, anche se le percepiamo come "uguali" in molti modi)

Penso che "Does" sia la parte importante di questa domanda. Penso che la programmazione orientata agli oggetti sia Can modello di oggetti del mondo reale, ma questa è programmazione . C'è una no metodologia che non può essere sfruttata, quindi non penso sia corretto dire "OOP non modella il mondo reale" solo perché puoi fare cose stupide con gli Oggetti. Non è più giusto dire che i puntatori non sono sicuri perché puoi fare cose stupide con i puntatori.

l'articolo di Wikipedia sull'argomento lo riassume bene:

Real-world modeling and relationships
OOP can be used to associate real-world objects and processes with digital counterparts. However, not everyone agrees that OOP facilitates direct real-world mapping (see Negative Criticism section) or that real-world mapping is even a worthy goal; Bertrand Meyer argues in Object-Oriented Software Construction[21] that a program is not a model of the world but a model of some part of the world; "Reality is a cousin twice removed".

Il fatto è che a meno che il tuo programma non sia una simulazione dell'universo, ti interessi solo su parti del mondo reale - da qui "modello". Ecco a cosa servono i modelli, ti danno la struttura e la funzionalità che devi mostrare.

Nel mondo reale abbiamo cose (Oggetti) e le cose possono compiere azioni (metodi). Possiamo quantificare aspetti delle cose (Proprietà). OOP ha tutte le potenzialità per modellare le cose del mondo reale se usato in modo riduttivo; ogni cosa complessa ha sottoclassi più piccole o più specifiche e tutte queste cose hanno interazioni naturali tramite metodi.

OOP è un metodo di astrazione, quindi la cosa pratica è se OOP veramente logicamente modelli oggetti nel Mondo Reale, è meno importante che tu non stia modellando ogni singola cosa possibile tutto potrebbe mai fare . Se hai bisogno di fare ogni singola cosa possibile, non sei veramente modeling .

Per riflettere sull'orientamento all'oggetto nel suo giusto contesto, passiamo ad un livello di astrazione e parliamo di programmazione in generale, ok?

Indipendentemente dal fatto che tu prenda OO o approcci funzionali, il tuo programma deve fare qualcosa, non è vero? L'intero punto del programma è di mostrare alcuni comportamenti dati un certo insieme di stimoli. Quindi i motivi per cui i programmi esistono sono perché fanno qualcosa. La parola chiave qui è comportamento .

Oltre a considerare quali comportamenti deve essere implementato da un programma, il tuo programma in genere deve mostrare alcune qualità. Ad esempio, non è sufficiente che un programma di monitoraggio del cuore abbia i comportamenti richiesti da esso - di solito ha anche bisogno di essere performante abbastanza velocemente da operare in tempo quasi reale. Altre "qualità" che un programma potrebbe dover esporre sono: sicurezza, flessibilità, modularità, estensibilità, leggibilità e così via. Chiamiamo questi Attributi di qualità dell'architettura . Quindi possiamo dire che il nostro programma deve soddisfare determinati obiettivi (funzionali) comportamentali e presentare alcune qualità (non funzionali).

Finora, nessuno di questi ha parlato di OO, vero? Facciamolo ora.

Una volta che un ingegnere comprende i requisiti (comportamentali, AQA, vincoli, ecc.), sorge la domanda: come organizzo il mio codice in modo che faccia tutte le cose che deve fare pur esibendo le qualità necessarie per essere utile programma? La programmazione orientata agli oggetti è una strategia per organizzare la funzionalità del tuo programma in moduli coesi di oggetti cooperativi. La programmazione funzionale è solo un'altra strategia per organizzare le funzionalità del tuo programma, e lo fa in un modo diverso. Entrambe le strategie hanno i loro punti di forza e di debolezza.

Abbiamo assistito a una recente ripresa dei concetti funzionali perché ha punti di forza molto interessanti per l'elaborazione estremamente distribuita, tra le altre ragioni.

Ma tornando a OO, puoi vedere ora che non modella necessariamente il "mondo reale"; ciò che fa è organizzare il comportamento del tuo programma in modo che il tuo programma possa esibire le qualità necessarie per soddisfare qualsiasi numero di obiettivi di business. Tecniche come TDD, DDD e BDD sono i modi in cui scopriamo il modo migliore per organizzare i nostri oggetti. Libri come Principi, modelli e pratiche , Software orientato agli oggetti in crescita guidato da test , Specifica per esempio e Domain-Driven Design espongono la teoria e la pratica dell'orientamento agli oggetti con particolare attenzione al design guidato dal comportamento .

Quando leggi cose come "osservatori, manager, fabbriche, ecc.", stai applicando i modelli OO che aiutano il tuo programma a mostrare alcune qualità che potrebbero essere necessarie perché sia utile. Sono "ricette provate" che "tendono a funzionare", dato che le tue esigenze corrispondono al problema risolto dallo schema.

Spero che questo ti aiuti a capire di cosa si tratta OO senza apparire troppo distorto tra OO e paradigmi funzionali.

OOP crea un modello piacevole dal punto di vista della programmazione, non riflette il mondo reale.

Tuttavia, ci sono approssimazioni molto migliori del mondo reale, che sono conosciute con il termine lingue specifiche del dominio ( DSL ). Ad esempio Boo ti offre la possibilità di scrivere codice leggibile in inglese quasi in chiaro (esempio dal article ).

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

Un altro esempio sarebbe un framework di test di accettazione utente automatizzato basato su Gherkin lingua.

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

Dipende da te, finalmente. Ma OOP è un modo preciso di farlo rispetto ad altre metodologie come la programmazione strutturata o orientata alla procedura. Il tatto procedurale potrebbe risolvere i tuoi problemi, ma seguendo OOP puoi renderti la vita più facile.