Come progettare l'accesso dei membri per una classe di tipo Articolo? [duplicare]

Question

Come progettare l'accesso dei membri per una classe di tipo Articolo? [duplicare]

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

1

Sto facendo un progetto finale in una classe C ++ scrivendo un client / server semplice simile a usenet molto . Immagino che poiché è usenet-like avrò una classe NewsGroup e una classe Article , ora sto lavorando sulla mia classe Article . Non posso davvero decidere un buon design, anche se (questa classe non riguarda i modelli di design e non ne ho presi nessuno).

Questo è quello che ho:

class Article {
public:
    const std::string author;
    std::string title;
    std::string text;
    const uint32_t id;
    system_clock::time_point timestamp;

    Article(const std::string auth&,
            const std::string tit&,
            const std::string txt&,
            const system_clock::time_point&);

private:
    Article(const Article&);
    void operator=(const Article&);
    static uint32_t id_pool;
};

La mia motivazione è questa:

author non dovrebbe mai cambiare - > const

title potrebbe cambiare se modificato - > non-const

text potrebbe cambiare se modificato - > non-const

id non dovrebbe mai cambiare - > const

timestamp potrebbe cambiare ma probabilmente non dovrebbe, non sono ancora sicuro di cosa farne.

id_pool è solo da dove ottengo gli ID. Una specifica è che gli ID non dovrebbero mai essere riutilizzati quindi ho solo incrementato id_pool nel costruttore dell'articolo.

Venendo da Java con tutti i getter e setter che davvero non mi piacciono, e poi alcuni Python con "Tutto pubblico" e proprietà, che mi piacciono, qui mi sto confondendo un po '.

Voglio dire, potrei rendere i membri privati e avere getter e setter (non riesco a pensare a nessun "verbo-metodo" naturale che un articolo possa "fare"), ma mi sembra che guadagnerei molto poco.

Sarei grato per alcuni suggerimenti su un buon design in questo caso.

object-oriented c++ design-patterns object-oriented-design

posta evading 11.03.2013 - 22:39

fonte

2 risposte

0

Per iniziare, sarebbe logico rendere le variabili dei membri private e esporre le funzioni pubbliche get / set dove necessario. Il vantaggio che questo offre è che è possibile modificare le variabili dei membri interni, se necessario (refactoring futuro, ad esempio) senza dover modificare i contesti di chiamata perché gli interni sono nascosti dietro l'interfaccia di classe esterna.

In generale, questo dovrebbe essere considerato buon design estensibile e incapsulato in qualsiasi lingua quando si lavora su un progetto orientato agli oggetti che si intende mantenere.

risposta data 12.03.2013 - 11:14

fonte

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

Strutture dati del database per RESTful api Un'architettura di dati multi-tenant

score 1 · Accepted Answer

Inizia con l'interfaccia che la classe deve esporre ai suoi utenti. Non pensare immediatamente all'implementazione, ad es. Se usare std::string per il titolo, ecc. Mi verrebbe in mente qualcosa di seguito:

class Article {
public:
    typedef implementation_defined Id;

    Article(const char* author, const char* title);
    ~Article();

    Id GetId() const;
    const char* GetAuthor() const;
    const char* GetTitle() const;
    const char* GetText() const;
    system_clock::time_point GetTime() const;

    void SetTitle(const char* text);
    void SetText(const char* text);
    void SetTime(system_clock::time_point timestamp);
};

L'intenzione è che il chiamante utilizzi il tipo Article::Id invece di qualcosa come int . Presumo che l'Id sia generato in modo univoco durante la creazione, il testo può essere vuoto e il timestamp predefinito è l'ora corrente.

Dato che non stai esponendo l'implementazione al chiamante, sei libero di cambiare l'implementazione più tardi. Ad esempio, forse l'interfaccia detta la codifica UTF-8, ma l'implementazione reale utilizza UTF-16 ( wchar_t ) su Windows (solo per mostrare, non che sia qualcosa che si dovrebbe / voler fare). Puoi anche eseguire alcuni controlli nei metodi Set... .

Questo potrebbe essere banale, ma penso che il principio sia che devi: 1) pensare all'utente della classe; 2) rendilo flessibile e riduci la dipendenza.