Come decidi gli oggetti membri?

Question

Come decidi gli oggetti membri?

#1 da (1 voti)
#2 da (0 voti)

1

Quindi OOP si occupa di abbattere le funzionalità, rendendo ogni classe responsabile di una cosa ecc. Ma prendiamo l'esempio in cui un oggetto sta usando un altro oggetto. La prima cosa che mi viene in mente "composizione, ovviamente!".

Ho 2 domande:

Domanda 1: Supponiamo che tu abbia un negozio che sta caricando prodotti da un file utilizzando un ProductsLoader, che nel termine utilizza un ProductFileReader. Si progetta l'API in modo che il codice sia semplice, leggibile e specializzato. Pertanto, puoi farlo:

    std::shared_ptr<Shop> shop = std::shared_ptr<Shop> (new Shop());
    shop->LoadProducts();
    // other code

In LoadProducts fai questo:

    m_productsLoader.LoadAllProducts();
    std::shared_ptr<Products> products = m_productsLoader.GetAllProducts();
    this->setProducts(products);

In LoadAllProducts() fai questo:

    prodFileReader.OpenProductsFile();
    prodFileReader.LoadDescriptionsFromFile();
    prodFileReader.CloseProductsFile();

    // create products from descriptions
    std::shared_ptr<Descriptions> descriptions = prodFileReader.GetProductsDescriptions();
    this->createProductsFromDescriptions(descriptions);

E ora ecco la domanda: mantieni ProductsLoader m_productsLoader come membro Shop ? Lo stesso per ProductsFileReader : dovrebbe essere un membro di ProductsLoader ? L'alternativa per questo è la creazione di questi oggetti nello stack: quando le tue funzioni usano uno di essi, devi solo dichiararli, inizializzarli ecc. Nella funzione e vengono distrutti quando la funzione termina. Questo sfugge allo scopo di OOP?

Domanda 2: Diciamo che hai deciso di tenerli come membri. Come fai a sapere se dovresti mantenere l'intero oggetto come membro, o dovresti tenere solo un puntatore ad esso (e, ovviamente, nel costruttore, istanziare il membro e assegnare il puntatore). Sia che tu acceda al membro con il punto opperator . o freccia -> , eseguirà la stessa funzionalità.

object-oriented c++ object-oriented-design

posta Hame 28.12.2014 - 06:49

fonte

2 risposte

1

L'argomento che stai chiedendo è chiamato modeling ed è tanto un'arte quanto una scienza. Ma il primo passo della modellazione OO è quello di dimenticare la meccanica del linguaggio e pensare alle proprietà delle cose che stai modellando.

Una classe chiamata ProductsLoader è sospetto per cominciare. Nomi del genere indicano che stai pensando proceduralmente anziché in modo OO. Invece, la classe Product dovrebbe avere funzioni per produrre istanze e raccolte di se stessa da file o flussi o altro.

Quindi torna alla tua domanda, ma sostituisci Product per ProductsLoader come esempio. Come decidere se Product (o una collezione di essi) dovrebbe essere un membro di Shop ? Bene, i negozi hanno prodotti in essi? Questo è il tipo di domanda che dovrebbe guidare le tue decisioni nella modellazione OO, non in che modo il particolare linguaggio che stai utilizzando alloca le cose.

risposta data 28.12.2014 - 07:02

fonte

Leggi altre domande sui tag object-oriented c++ object-oriented-design

Architettura per il monitoraggio di molti minigiochi Query su java I / O BufferedOutputStream metodo write ()

score 0 · Accepted Answer

Di solito manterrò gli oggetti collaboratore come membri del puntatore nell'oggetto che li utilizzerà. Di solito li avrei anche implementati usando una classe astratta e passare i puntatori come parametri per il costruttore di Shop piuttosto che avere Shop che li costruiva da sé. Questo disaccoppia Acquista dal dettaglio di come i prodotti sono caricati e significa che posso passare a una diversa fonte di Prodotti senza dover modificare Shop; questa è l'essenza fondamentale del principio Aperto / Chiuso, che alcune persone descrivono come il principio più importante sulla progettazione orientata agli oggetti.