Quando non è accettabile modellare gli oggetti del mondo fisico con le classi?

Question

Quando non è accettabile modellare gli oggetti del mondo fisico con le classi?

#1 da (5 voti)
#2 da (5 voti)
#3 da (3 voti)
#4 da (3 voti)

2

Does Object Oriented Programming Really Model The Real World? [closed]

anche

"Firstly, A represents an object in the physical world, which is a strong argument for not splitting the class up." I was, unfortunately, told this when I started programming. It took me years to realize that it's a bunch of horse hockey. It's a terrible reason to group things. I can't articulate what are good reasons to group things (at least to my satisfaction), but that one is one you should discard right now. The end all, be all of "good code" is that it works right, is relatively easy to understand, and is relatively easy to change (i.e., changes don't have weird side effects). – jpmc26 8 hours ago

"Firstly, A represents an object in the physical world, which is a strong argument for not splitting the class up." I disagree with this. For example, if I had a class that represents a car, I would definitely want to split it up, because I surely want a smaller class to represent the tires. - jpmc26 11 hours ago

source

Fino ad ora, ho considerato il seguente un buon design, perché enfatizza la gerarchia fisica tra gli oggetti. Mi aspetto che sia più facile da capire, rispetto ad alcune astrazioni, ad esempio class ViewManager , class WheelsFascade .

class Car
{
public:
    void start() {assert(!m_fuel_tank.empty()); m_engine.start();};
private:
    std::vector<Wheel> m_wheels;
    Engine m_engine;
    FuelTank m_fuel_tank;
}

Sto capendo correttamente la critica di cui sopra che questo non è un buon design? Se sì, quali sono i problemi attuali? In caso contrario, quale viene criticato?

object-oriented

posta Vorac 28.01.2015 - 09:32

fonte

4 risposte

5

Supponiamo che tu abbia una società di software in cui hai scritto software per qualsiasi e tutte le cose relative alle automobili. Dovresti avere un Car oggetto che viene riutilizzato in tutto il tuo software? Certo che no:

Su un piano vendite, un Car ha valori al dettaglio e all'ingrosso.
Per un meccanico, un Car è costituito da un gruppo di parti sostituibili.
A un computer del motore, un Car è costituito da un gruppo di sensori e controlli.
Per un sistema di navigazione, un Car è un piccolo triangolo con una posizione, una direzione e una velocità.
Per un circuito, un Car ha un autista, un orario e un luogo (primo posto, secondo posto, ecc.)

A volte gli sviluppatori rimangono bloccati nella definizione del mondo reale e creano in modo inappropriato un oggetto di grandi dimensioni invece di suddividerlo in contesti appropriati. Questo succede anche con le gerarchie di ereditarietà, forse l'esempio più famoso è che un quadrato è considerato un tipo speciale di rettangolo nel mondo reale, ma un oggetto rettangolo di solito è meglio modellato come un tipo speciale di oggetto quadrato.

In ogni caso, inizia modellando le tue classi dopo gli oggetti del mondo reale. È un valore predefinito molto ragionevole. Basta non rimanere bloccati lì e lasciare che ti accechi a alternative migliori.

risposta data 28.01.2015 - 14:57

fonte

3

Per rispondere alla domanda nel titolo, non è accettabile modellare gli oggetti del mondo reale con le classi se quegli oggetti del mondo reale non hanno un ruolo nel dominio del problema.
Per dare un esempio estremo, non è opportuno avere una classe House quando si modella una rete ferroviaria.

La critica nella domanda a cui ti sei collegato era che il richiedente affermava (parafrasato): " Car è un oggetto del mondo reale e quindi non dovrei dividerlo ulteriormente".
Come ti mostri nella domanda, gli oggetti del mondo reale possono essere composti da altri oggetti del mondo reale, come un'auto con ruote, un motore e un serbatoio di carburante, e quella composizione può riflettersi nel design della classe.

risposta data 28.01.2015 - 10:11

fonte

3

Il primo problema nel cercare di essere fedeli al mondo reale è che non lo capiamo completamente. Ci sono ancora molti problemi aperti in fisica . Per risolvere un problema legato al mondo reale devi prima scegliere un modello di esso, e qualsiasi scelta sarà incompleta e in una certa misura imprecisa.

Il secondo problema è che anche se hai capito il mondo reale, non hai le risorse per simularlo.

Il terzo problema è che, con ogni probabilità, in realtà non lo si desidera. Diciamo che vuoi scoprire quanto tempo impiegheranno due macchine per scontrarsi; ti interessa davvero modellare ogni interazione atomica coinvolta e ottenere una risposta ad un livello infinito di precisione? No; probabilmente tratterai entrambe le macchine come punti, utilizzerai misurazioni di velocità e distanza che sono accurate solo con una manciata di cifre decimali, e trascurerai o utilizzerai modelli di attrito e resistenza al vento molto semplificati. E probabilmente sarà abbastanza preciso.

Dici che ti piace il tuo design perché "enfatizza la gerarchia fisica tra gli oggetti", ma è una gerarchia fisica anche rilevante per il tuo problema? Ci sono molte altre relazioni tra entità del mondo reale che non sono fisiche. Se è rilevante, la quale gerarchia fisica hai enfatizzato, è sufficientemente accurata, ed è abbastanza semplice?

risposta data 28.01.2015 - 14:23

fonte

Leggi altre domande sui tag object-oriented

È possibile sfuggire alla GPL derivando la stessa opera da più fonti? Che cosa guadagnano i linguaggi OOP dall'avere costruttori che restituiscono sempre un oggetto?

score 5 · Accepted Answer

È impossibile rispondere alla domanda se il codice che si presenta sia un buon design senza una buona comprensione di cosa e per chi è il codice. Perché, esattamente, hai una tale classe nella tua applicazione? Quali sono i suoi clienti? Chi ha specificato i comportamenti che sono implementati da esso? Quanto sono probabili queste specifiche da cambiare in futuro? Quali aspetti delle specifiche sono suscettibili di cambiare insieme e che probabilmente cambieranno in momenti diversi?

Il software reale raramente fa qualcosa di identico a un oggetto del mondo reale, quindi suddividerlo in divisioni simili non è necessariamente l'approccio migliore. Anche se ciò che stiamo facendo è simulare un sistema reale, potrebbe essere meglio unire componenti che sono concettualmente distinti nel mondo reale in un'unica astrazione (forse perché non abbiamo bisogno di modellare le interazioni tra allora, ma solo il risultato finale di tali interazioni: il tuo modello ha 4 oggetti ruota separati, ma potrebbe avere più senso considerare due ruote e un asse come una singola unità, ad esempio) o dividere un singolo componente reale in più ruoli (perché quel componente ha più le cose e abbiamo bisogno di modellarle in modi diversi: le ruote di una macchina guidano l'auto e impartiscono il movimento in avanti, che possiamo decidere sia più facile da gestire separatamente che insieme).

Ciò che possiamo dire con certezza è che il dogma secondo cui gli oggetti di modellazione dovrebbero essere basati rigorosamente sulla divisione dei componenti negli oggetti del mondo reale è chiaramente sbagliato. Dovremmo dividere il nostro codice in oggetti per ragioni pragmatiche, piuttosto che conformarci a ideali privi di base pratica, il che è ciò che questo suggerimento sembra essere.