Об'єктно-орієнтоване програмування: геттери / сетери або логічні назви

Зараз я думаю про інтерфейс до класу, про який пишу. Цей клас містить стилі для символу, наприклад, чи є жирний шрифт, курсив, підкреслений і т. Д. Я два дні дискутував із собою, чи слід використовувати геттери / сеттери або логічні назви для методів, які змінюють значення на ці стилі. Хоча я, як правило, віддаю перевагу логічним іменам, це означає, що написання коду не є настільки ефективним і не таким логічним. Дозвольте навести вам приклад.

У мене є клас , CharacterStylesякий має змінні член bold, italic, underline(і деякі інші, але я залишу їх для простоти). Найпростіший спосіб дозволити іншим частинам програми отримати доступ до цих змінних - написати методи getter / setter, щоб ви могли це робити styles.setBold(true)і styles.setItalic(false).

Але мені це не подобається. Не тільки тому, що багато людей кажуть, що геттери / сетери порушують інкапсуляцію (це справді так погано?), А в основному тому, що мені це не здається логічним. Я розраховую, що стилю вдасться за допомогою одного методу styles.format("bold", true)чи чогось подібного, але не через усі ці методи.

Однак є одна проблема. Оскільки ви не можете отримати доступ до змінної об'єкта-члена за вмістом рядка в C ++, мені доведеться або написати великий контейнер if-statement / switch для всіх стилів, або мені доведеться зберігати стилі в асоціативному масиві ( карта).

Я не можу зрозуміти, який найкращий спосіб. Одного моменту я думаю, що мені слід написати гетерів / сеттерів, а наступного моменту схиляюся в інший бік. Моє запитання: що б ти робив? І чому б ти це робив?

Так, геттери / сетери розбивають інкапсуляцію - вони в основному є лише додатковим шаром між прямим доступом до нижнього поля. Ви можете просто отримати доступ до нього безпосередньо.

Тепер, якщо ви хочете отримати більш складні методи доступу до поля, це дійсно, але замість того, щоб виставляти поле, вам потрібно подумати, які методи повинен запропонувати клас. тобто. замість класу банку зі значенням Money, яке піддається впливу властивості, вам потрібно подумати, які типи доступу має запропонувати об’єкт Банку (додати гроші, зняти гроші, отримати баланс) та застосувати ці замість цього. Властивість змінної Money лише синтаксично відрізняється від експонування змінної Money безпосередньо.

У DrDobbs є стаття, в якій сказано більше.

Для вашої проблеми я мав би два способи setStyle та clearStyle (або будь-які інші), які перераховують можливі стилі. Оператор переключення всередині цих методів потім застосує відповідні значення до відповідних змінних класу. Таким чином, ви можете змінити внутрішнє представлення стилів на щось інше, якщо згодом вирішите зберегти їх як рядок (наприклад, для використання в HTML) - те, що вимагатиме зміни всіх користувачів вашого класу, якщо ви використовували отримати / встановити властивості.

Ви все ще можете увімкнути рядки, якщо хочете взяти довільні значення, або мати велику операцію if-then (якщо їх декілька), або карту рядкових значень у покажчиках методів за допомогою std :: mem_fun (або std :: функція ), тому "жирний" буде зберігатися в ключі карти, його значення буде sts :: mem_fun методу, який встановлює змінну bold в true (якщо рядки такі ж, як імена змінних членів, то ви також можете використовувати stringifying макрос , щоб зменшити кількість коду , вам потрібно написати)

Одна з ідей, яку ви, можливо, не врахували, - це візерунок декораторів . Замість того, щоб встановлювати прапори в об’єкт, а потім застосовувати ці прапори до всього, що ви пишете, ви загортаєте клас, який робить написання, в «Декоратори», які, в свою чергу, застосовують стилі.

Коду виклику не потрібно знати, скільки цих обгортків ви помістили навколо тексту, ви просто зателефонуєте методу на зовнішній об'єкт, і він викличе стек.

Для прикладу псевдокоду:

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;
}

І так далі, для кожного стилю прикраси. У його найпростішому використанні ви можете сказати

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

І код, який викликає цей метод, не повинен знати деталі того, що він отримує. Поки що SOMETHING може малювати текст методом WriteString.

Я схиляюся до другого рішення. Це виглядає більш елегантно і гнучко. Хоча важко уявити інші типи, крім жирного, курсивного та підкреслення (перекреслення?), Важко буде додати нові типи за допомогою змінних членів.

Я використовував такий підхід в одному з моїх останніх проектів. У мене клас, який може мати кілька булевих атрибутів. Кількість та назви атрибутів можуть змінюватися в часі. Я зберігаю їх у словнику. Якщо атрибута немає, я припускаю, що його значення "хибне". Я також повинен зберігати список доступних імен атрибутів, але це вже інша історія.

Я думаю, ви надмірно думаєте над цим питанням.

styles.setBold(true) і styles.setItalic(false)все в порядку