С моей точки зрения, поскольку я сижу с 4 миллионами строк кода C ++ (и это всего лишь один проект), с точки зрения обслуживания я бы сказал:

• Можно не использовать геттеры / сеттеры, если члены неизменяемы (т.е. const) или простые без зависимостей (например, класс точки с членами X и Y).

• Если член private, можно также пропустить геттеры / сеттеры. Я также считаю членов внутренних pimpl -классов как private, если модуль .cpp небольшой.

• Если член public или protected (protected так же плохо, как public) и не const, непростой или имеет зависимости, тогда используйте геттеры / сеттеры.

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

Я предпочитаю вариант 2, так как он более доступен для поиска (ключевой компонент при написании поддерживаемого кода).

2) - лучший вариант ИМО, потому что он наиболее четко проясняет ваши намерения. set_amount(10) имеет большее значение, чем amount(10), и в качестве приятного побочного эффекта позволяет члену с именем amount.

Открытые переменные обычно - плохая идея, потому что нет инкапсуляции. Предположим, вам нужно обновить кеш или обновить окно при обновлении переменной? Жаль, если ваши переменные общедоступны. Если у вас есть метод set, вы можете добавить его туда.

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

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

2. Это мой стиль по умолчанию, когда я использую методы доступа.

3. Мне этот стиль кажется слишком «умным». Я использую его в редких случаях, но только в тех случаях, когда я действительно хочу, чтобы средство доступа выглядело как переменная, насколько это возможно.

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

1. Это хороший стиль, если мы просто хотим представить pure данные.

2. Мне это не нравится :) потому что get_/set_ действительно не нужны, когда мы можем перегрузить их на C ++.

3. STL использует этот стиль, например std::streamString::str и std::ios_base::flags, за исключением тех случаев, когда его следует избегать! когда? Когда имя метода конфликтует с именем другого типа, используется стиль get_/set_, например std::string::get_allocator из-за std::allocator.

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

При этом, если такой дизайн нуждается в рефакторинге и доступен исходный код, я бы предпочел использовать шаблон Visitor Design. Причина:

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

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

c. Он четко документирует такой внешний доступ через понятный интерфейс класса.

Основная идея:

а) Редизайн, если возможно, иначе,

б) Рефакторинг так, чтобы

1. Весь доступ к состоянию класса осуществляется через хорошо известный индивидуальный интерфейс.

2. Должна быть возможность настроить какие-то действия и запреты для каждого такого интерфейса, например весь доступ из внешнего объекта ХОРОШО должен быть разрешен, весь доступ из внешнего объекта ПЛОХО должен быть запрещен, а внешнему объекту ОК должно быть разрешено получить но не установлен (например)

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

2. Соглашение об именах не имеет значения, если вы единообразны в своем коде. Если вы используете несколько сторонних библиотек, они в любом случае могут использовать разные соглашения об именах. Так что дело вкуса.

Я видел идеализацию классов вместо интегральных типов для обозначения значимых данных.

Что-то вроде этого ниже обычно не позволяет эффективно использовать свойства C ++:

struct particle {
    float mass;
    float acceleration;
    float velocity;
} p;

Почему? Потому что результатом p.mass * p.acceleration является float, а не форсировка, как ожидалось.

Определение классов для обозначения цели (даже если это значение, например amount, упомянутое ранее) имеет больше смысла и позволяет нам делать что-то вроде:

struct amount
{
    int value;

    amount() : value( 0 ) {}
    amount( int value0 ) : value( value0 ) {}
    operator int()& { return value; }
    operator int()const& { return value; }
    amount& operator = ( int const newvalue )
    {
        value = newvalue;
        return *this;
    }
};

Вы можете получить доступ к значению суммы неявно с помощью оператора int. Более того:

struct wage
{
    amount balance;

    operator amount()& { return balance; }
    operator amount()const& { return balance; }
    wage& operator = ( amount const&  newbalance )
    {
        balance = newbalance;
        return *this;
    }
};

Использование Getter / Setter:

void wage_test()
{
    wage worker;
    (amount&)worker = 100; // if you like this, can remove = operator
    worker = amount(105);  // an alternative if the first one is too weird
    int value = (amount)worker; // getting amount is more clear
}

Это другой подход, не значит, что он хороший или плохой, это другой подход.

Дополнительная возможность может быть:

int& amount();

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

str.length() = 5; // Ok string is a very bad example :)

Иногда это может быть просто хороший выбор:

image(point) = 255;  

Еще одна возможность - использовать функциональную нотацию для изменения объекта.

edit::change_amount(obj, val)

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

Позвольте мне рассказать вам об одной дополнительной возможности, которая кажется наиболее осознанной.

Необходимо прочитать и изменить

Просто объявите эту переменную общедоступной:

class Worker {
public:
    int wage = 5000;
}

worker.wage = 8000;
cout << worker.wage << endl;

Нужно просто прочитать

class Worker {
    int _wage = 5000;
public:
    inline int wage() {
        return _wage;
    }
}

worker.wage = 8000; // error !!
cout << worker.wage() << endl;

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

вариант №3, мне сказали, что это может быть «беглый» стиль

class foo {
  private: int bar;
  private: int narf;
  public: foo & bar(int);
  public: int bar();
  public: foo & narf(int);
  public: int narf();
};

//multi set (get is as expected)
foo f; f.bar(2).narf(3);