Стиль кодирования геттеров / сеттеров C ++

Делать неконстантные поля общедоступными, как правило, является плохой идеей, потому что тогда становится трудно принудительно установить ограничения проверки ошибок и / или добавить побочные эффекты к изменениям значений в будущем.

В вашем случае у вас есть поле const, поэтому вышеуказанные проблемы не являются проблемой. Основным недостатком публичного поля является то, что вы блокируете базовую реализацию. Например, если в будущем вы захотите изменить внутреннее представление на C-строку, строку Unicode или что-то еще, тогда вы сломаете весь клиентский код. С помощью получателя вы можете преобразовать существующие клиенты в устаревшее представление, одновременно предоставляя новые функции новым пользователям с помощью нового получателя.

Я по-прежнему предлагаю использовать метод получения, подобный тому, который вы разместили выше. Это максимизирует вашу гибкость в будущем.

Использование метода получения - лучший выбор для долгоживущего класса, поскольку он позволяет в будущем заменить метод получения чем-то более сложным. Хотя это кажется менее вероятным для постоянного значения, стоимость невысока, а возможные преимущества велики.

Кстати, в C ++ особенно хорошей идеей является присвоение геттеру и сеттеру элемента одинакового имени, поскольку в будущем вы можете фактически изменить пару методов:

class Foo {
public:
    std::string const& name() const;          // Getter
    void name(std::string const& newName);    // Setter
    ...
};

В единую общедоступную переменную-член, которая определяет operator()() для каждого:

// This class encapsulates a fancier type of name
class fancy_name {
public:
    // Getter
    std::string const& operator()() const {
        return _compute_fancy_name();    // Does some internal work
    }

    // Setter
    void operator()(std::string const& newName) {
        _set_fancy_name(newName);        // Does some internal work
    }
    ...
};

class Foo {
public:
    fancy_name name;
    ...
};

Конечно, клиентский код нужно будет перекомпилировать, но никаких изменений синтаксиса не требуется! Очевидно, это преобразование работает так же хорошо для значений const, в которых требуется только геттер.

Кстати, в C ++ несколько странно иметь константный ссылочный член. Вы должны назначить его в списке конструкторов. Кому принадлежит фактическая память об этом объекте и какова его продолжительность жизни?

Что касается стиля, я согласен с другими, что вы не хотите обнажать свои интимные места. :-) Мне нравится этот паттерн для сеттеров / геттеров

class Foo
{
public:
  const string& FirstName() const;
  Foo& FirstName(const string& newFirstName);

  const string& LastName() const;
  Foo& LastName(const string& newLastName);

  const string& Title() const;
  Foo& Title(const string& newTitle);
};

Таким образом вы можете сделать что-то вроде:

Foo f;
f.FirstName("Jim").LastName("Bob").Title("Programmer");

Я думаю, что подход C ++ 11 сейчас был бы больше похож на этот.

#include <string>
#include <iostream>
#include <functional>

template<typename T>
class LambdaSetter {
public:
    LambdaSetter() :
        getter([&]() -> T { return m_value; }),
        setter([&](T value) { m_value = value; }),
        m_value()
    {}

    T operator()() { return getter(); }
    void operator()(T value) { setter(value); }

    LambdaSetter operator=(T rhs)
    {
        setter(rhs);
        return *this;
    }

    T operator=(LambdaSetter rhs)
    {
        return rhs.getter();
    }

    operator T()
    { 
        return getter();
    }


    void SetGetter(std::function<T()> func) { getter = func; }
    void SetSetter(std::function<void(T)> func) { setter = func; }

    T& GetRawData() { return m_value; }

private:
    T m_value;
    std::function<const T()> getter;
    std::function<void(T)> setter;

    template <typename TT>
    friend std::ostream & operator<<(std::ostream &os, const LambdaSetter<TT>& p);

    template <typename TT>
    friend std::istream & operator>>(std::istream &is, const LambdaSetter<TT>& p);
};

template <typename T>
std::ostream & operator<<(std::ostream &os, const LambdaSetter<T>& p)
{
    os << p.getter();
    return os;
}

template <typename TT>
std::istream & operator>>(std::istream &is, const LambdaSetter<TT>& p)
{
    TT value;
    is >> value;
    p.setter(value);
    return is;
}


class foo {
public:
    foo()
    {
        myString.SetGetter([&]() -> std::string { 
            myString.GetRawData() = "Hello";
            return myString.GetRawData();
        });
        myString2.SetSetter([&](std::string value) -> void { 
            myString2.GetRawData() = (value + "!"); 
        });
    }


    LambdaSetter<std::string> myString;
    LambdaSetter<std::string> myString2;
};

int _tmain(int argc, _TCHAR* argv[])
{
    foo f;
    std::string hi = f.myString;

    f.myString2 = "world";

    std::cout << hi << " " << f.myString2 << std::endl;

    std::cin >> f.myString2;

    std::cout << hi << " " << f.myString2 << std::endl;

    return 0;
}

Я тестировал это в Visual Studio 2013. К сожалению, чтобы использовать базовое хранилище внутри LambdaSetter, мне потребовалось предоставить общедоступный аксессор GetRawData, который может привести к нарушению инкапсуляции, но вы можете либо оставить его, либо предоставить свой собственный контейнер для хранения для T или просто убедитесь, что вы используете "GetRawData" только тогда, когда пишете собственный метод получения / установки.

Несмотря на то, что имя неизменяемо, вы все равно можете захотеть вычислить его, а не сохранять в поле. (Я понимаю, что это маловероятно для "name", но давайте нацелимся на общий случай.) По этой причине даже константные поля лучше всего заключать в геттеры:

class Foo {
    public:
        const std::string& getName() const {return name_;}
    private:
        const std::string& name_;
};

Обратите внимание, что если вы измените getName() для возврата вычисленного значения, он не сможет вернуть const ref. Это нормально, потому что это не потребует никаких изменений в вызывающих (по модулю перекомпиляции).

Избегайте общедоступных переменных, за исключением классов, которые по сути являются структурами в стиле C. Это просто не лучшая практика.

После того, как вы определили интерфейс класса, вы, возможно, никогда не сможете его изменить (кроме добавления к нему), потому что люди будут строить на нем и полагаться на него. Сделать переменную общедоступной означает, что вам нужна эта переменная, и вы должны убедиться, что в ней есть то, что нужно пользователю.

Теперь, если вы используете геттер, вы обещаете предоставить некоторую информацию, которая в настоящее время хранится в этой переменной. Если ситуация изменится, и вы не хотите постоянно поддерживать эту переменную, вы можете изменить доступ. Если требования меняются (а я видел некоторые довольно странные изменения требований), и вам в основном нужно имя, которое находится в этой переменной, но иногда имя в этой переменной, вы можете просто изменить геттер. Если бы вы сделали переменную общедоступной, вы бы застряли на ней.

Это не всегда будет происходить, но мне гораздо проще написать быстрый метод получения, чем анализировать ситуацию, чтобы увидеть, не пожалею ли я о том, что переменная стала общедоступной (и рискну ошибиться позже).

Сделать переменные-члены приватными - это хорошая привычка. Любой магазин, в котором есть стандарты кода, вероятно, запретит делать случайные переменные-члены общедоступными, и любой магазин с обзорами кода, вероятно, будет критиковать вас за это.

Когда это действительно не имеет значения для простоты письма, возьмите более безопасную привычку.

Собрал идеи из нескольких источников C ++ и воплотил их в красивый, но довольно простой пример для геттеров / сеттеров на C ++:

class Canvas { public:
    void resize() {
        cout << "resize to " << width << " " << height << endl;
    }

    Canvas(int w, int h) : width(*this), height(*this) {
        cout << "new canvas " << w << " " << h << endl;
        width.value = w;
        height.value = h;
    }

    class Width { public:
        Canvas& canvas;
        int value;
        Width(Canvas& canvas): canvas(canvas) {}
        int & operator = (const int &i) {
            value = i;
            canvas.resize();
            return value;
        }
        operator int () const {
            return value;
        }
    } width;

    class Height { public:
        Canvas& canvas;
        int value;
        Height(Canvas& canvas): canvas(canvas) {}
        int & operator = (const int &i) {
            value = i;
            canvas.resize();
            return value;
        }
        operator int () const {
            return value;
        }
    } height;
};

int main() {
    Canvas canvas(256, 256);
    canvas.width = 128;
    canvas.height = 64;
}

Вывод:

new canvas 256 256
resize to 128 256
resize to 128 64

Вы можете протестировать его онлайн здесь: http://codepad.org/zosxqjTX

PS: FO Yvette ‹3

Из теории паттернов дизайна; «инкапсулируйте то, что меняется». Определение «геттера» означает хорошее соблюдение вышеуказанного принципа. Итак, если реализация-представление члена изменится в будущем, член может быть «массирован» перед возвратом из «получателя»; подразумевая отсутствие рефакторинга кода на стороне клиента, где выполняется вызов getter.

С уважением,