Le migliori pratiche OOP per gli oggetti che accedono ai membri di "oggetti aggregati"?

-1

Esiste una best practice per qualcosa di simile?

(Esempio in C ++)

class A {
    public:
        int usefulParameter;
        std::vector<B*> bContainer;
};
class B {
    public:
        void needsUsefulParameter(int u);
};

Ci sono dei buoni modi per gli oggetti della classe B di accedere ai campi dalla classe A , anche se potrebbero non essere strettamente correlati? In questo caso, A "ha un" B , ma non necessariamente "possiede un".

Lo scopo della funzione è responsabilità di A , oppure si trova con B ?

Per utilizzare il campo di A e il campo di B , potrebbe succedere come

class A {
    public:
        int usefulParameter;
        void needsUsefulParameter(B* b);
};

dove A ha la responsabilità di realizzare l'azione richiesta. Potrebbe anche succedere sul B side

class B {
    public:
        int b_field;
        void needsUsefulParameter(A* a);
};

Esempio: un gioco ha uno stato mondiale. I giocatori interagiscono con il mondo e le loro azioni dipendono dallo stato del mondo. Ad esempio, vogliamo confrontare la valuta, ma il valore della valuta cambia con la stagione. Durante l'estate (lo stato di gioco lo terrebbe), il gelato è una valuta di alto valore. In inverno, la lana è una valuta di alto valore.

In c ++, sarebbe bello sovraccaricare gli operatori di <, > <=, >=, == .

class Currency{
    string currencyobject;
}
Currency w("wool");
Currency w("icecream");

cout << wool < icecream << endl;

Ma l'oggetto-mondo dovrebbe essere responsabile del calcolo di quel confronto, o le monete dovrebbero estrarre i campi dall'oggetto-mondo?

Scusa se non sono sicuro di quale sia il modo migliore per dirlo. Parte del mio problema è trovare le parole giuste da cercare. Qual è il nome per un super-oggetto che è un'aggregazione di sotto-oggetti? ecc. ecc. ecc.

    
posta Dillon Chan 18.07.2018 - 22:30
fonte

1 risposta

1

Are there any good ways for objects of class B to access fields from class A, even though they may not be closely related?

Se non sono strettamente correlati, B non ha il diritto di accedere ai campi da A . Se B oggetti non sono correlati logicamente a qualche A , allora le operazioni membro di B non dovrebbero accedere a A .

E se questa relazione esiste (o esiste condizionalmente), allora è meglio rendere questa relazione una parte formale degli oggetti avendo B memorizza un puntatore / riferimento / ecc effettivo alla A a cui è correlato .

But should the world-object be responsible for calculating that comparison, or should the currencies pull in fields from the world-object?

Stai facendo la domanda sbagliata, nel momento sbagliato.

La domanda prima che devi prendere in considerazione è, "al momento di decidere la valutazione della valuta, di quale stato devo tenere conto?" Quando hai una risposta completa a questa domanda, allora puoi decidere quale oggetto sarebbe responsabile del calcolo.

O se c'è un oggetto responsabile per questo; non c'è motivo per cui la funzione CalcCurrencyValuation debba essere membro di un oggetto. La valutazione valutaria è un processo , un algoritmo, non un oggetto. Usa i dati forniti dagli oggetti, ma il concetto non fa parte del "mondo". È solo una cosa che può essere fatta con un set di stato.

Nel complesso, questo tipo di design parla di un investimento eccessivo nel pensiero OOP. Il tuo progetto sembra voler mettere tutto in qualche tipo di funzione membro, anche se non ha senso farlo. Questo tipo di design porta a interfacce grasse (funzioni di bubbling fino a questa classe "mondiale") e simili. Questo porta anche a problemi se il tuo progetto richiede improvvisamente che venga preso in considerazione un altro stato al fine di calcolare la valutazione di una valuta. Ora devi assicurarti che lo stato faccia parte di questa classe "mondiale".

È una funzione; trattalo come tale.

    
risposta data 18.07.2018 - 23:11
fonte

Leggi altre domande sui tag