Programmazione orientata agli oggetti: getter / setter o nomi logici

Attualmente sto pensando a un'interfaccia per una classe che sto scrivendo. Questa classe contiene stili per un personaggio, ad esempio se il carattere è grassetto, corsivo, sottolineato, ecc. Ho discusso con me stesso per due giorni se dovrei usare getter / setter o nomi logici per i metodi che cambiano i valori in questi stili. Mentre tendo a preferire i nomi logici, significa scrivere codice che non sia così efficiente e non così logico. Lasciate che vi faccia un esempio.

Ho una classe CharacterStylesche ha variabili membro bold, italic, underline(e alcuni altri, ma io li lascio fuori per mantenere le cose semplici). Il modo più semplice per consentire ad altre parti del programma di accedere a queste variabili sarebbe quello di scrivere metodi getter / setter, in modo che tu possa fare styles.setBold(true)e styles.setItalic(false).

Ma questo non mi piace. Non solo perché molte persone dicono che i getter / setter rompono l'incapsulamento (è davvero così male?), Ma soprattutto perché non mi sembra logico. Mi aspetto di modellare un personaggio con un metodo styles.format("bold", true)o qualcosa del genere, ma non con tutti questi metodi.

C'è un problema però. Dal momento che non è possibile accedere a una variabile membro oggetto dal contenuto di una stringa in C ++, dovrei o scrivere un grande contenitore if-statement / switch per tutti gli stili, oppure dovrei memorizzare gli stili in un array associativo ( carta geografica).

Non riesco a capire quale sia il modo migliore. Un momento penso che dovrei scrivere i getter / setter, e il momento successivo mi sposto verso l'altro modo. La mia domanda è: cosa faresti? E perché dovresti farlo?

Sì, i getter / setter interrompono l'incapsulamento - in pratica sono solo un ulteriore livello tra l'accesso diretto al campo sottostante. Potresti anche accedervi direttamente.

Ora, se vuoi che metodi più complessi accedano al campo, questo è valido, ma invece di esporre il campo, devi pensare a quali metodi dovrebbe offrire la classe. vale a dire. invece di una classe Bank con un valore di Money che viene esposto usando una proprietà, è necessario pensare a quali tipi di accesso dovrebbe offrire un oggetto Bank (aggiungere denaro, prelevare, ottenere saldo) e implementare invece quelli. Una proprietà sulla variabile Money è solo sintatticamente diversa dall'esporre direttamente la variabile Money.

DrDobbs ha un articolo che dice di più.

Per il tuo problema, avrei 2 metodi setStyle e clearStyle (o qualsiasi altra cosa) che prendono in considerazione i possibili stili. Un'istruzione switch all'interno di questi metodi applicherebbe quindi i valori rilevanti alle variabili di classe appropriate. In questo modo, puoi cambiare la rappresentazione interna degli stili in qualcos'altro se in seguito decidi di memorizzarli come una stringa (ad esempio per l'uso in HTML), qualcosa che richiederebbe di cambiare anche tutti gli utenti della tua classe se lo usassi get / set properties.

Puoi ancora attivare le stringhe se vuoi prendere valori arbitrari, avere una grande istruzione if-then (se ce ne sono alcune) o una mappa di valori di stringa per puntare i metodi usando std :: mem_fun (o std :: funzione ) in modo che "grassetto" venga archiviato in una chiave della mappa con il valore che è sts :: mem_fun in un metodo che imposta la variabile in grassetto su true (se le stringhe sono uguali ai nomi delle variabili dei membri, è possibile utilizzare anche la macro stringificante per ridurre la quantità di codice che devi scrivere)

Un'idea che potresti non aver preso in considerazione è il motivo decorativo . Invece di impostare le bandiere in un oggetto e quindi applicare quelle bandiere a qualsiasi cosa tu stia scrivendo, avvolgi la classe che esegue la scrittura in Decoratori, che a loro volta applicano gli stili.

Il codice chiamante non ha bisogno di sapere quanti di questi wrapper hai messo attorno al tuo testo, devi solo chiamare un metodo sull'oggetto esterno e chiama lo stack.

Per un esempio di pseudocodice:

class TextWriter : TextDrawingInterface {
    public:
        void WriteString(string x) {
            // write some text somewhere somehow
        }
}

class BoldDecorator : TextDrawingInterface {
    public:
        void WriteString(string x) {
            // bold application on
            m_textWriter.WriteString(x);
            // bold application off
        }

        ctor (TextDrawingInterface textWriter) {
            m_textWriter = textWriter;
        }

    private:
        TextWriter m_TextWriter;
}

E così via, per ogni stile decorativo. Nel suo utilizzo più semplice, puoi quindi dire

TextDrawingInterface GetDecoratedTextWriter() {
    return new BoldDecorator(new ItalicDecorator(new TextWriter()));
}

E il codice che chiama questo metodo non ha bisogno di conoscere i dettagli di ciò che sta ricevendo. Finché è QUALCOSA che può disegnare il testo attraverso un metodo WriteString.

Mi spingerei verso la seconda soluzione. Sembra più elegante e flessibile. Sebbene sia difficile immaginare tipi diversi da grassetto, corsivo e sottolineato (sottolineato?), Sarebbe difficile aggiungere nuovi tipi utilizzando le variabili membro.

Ho usato questo approccio in uno dei miei ultimi progetti. Ho una classe che può avere più attributi booleani. Il numero e i nomi degli attributi possono cambiare nel tempo. Li conservo in un dizionario. Se un attributo non è presente, suppongo che il suo valore sia "falso". Devo anche memorizzare un elenco di nomi di attributi disponibili, ma questa è un'altra storia.

Penso che tu stia pensando troppo al problema.

styles.setBold(true) e va styles.setItalic(false)bene