методы считывания и стиль методов set

Как насчет int rate(); и void setRate(int value);? Это имеет то преимущество, что две функции с одним и тем же именем не выполняют разные функции, и все же позволяет period() * rate().

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

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

• Методы в верхнем регистре (это просто красивее).
• геттеры явно и в нижнем регистре (rate).
• устанавливает явно и в нижнем регистре (setRate).

Существует несколько уровней «Получение» и «Настройка»

• Я использую «Get» и «Set» для «быстрых» операций.
• Если для выполнения чего-либо требуется больше времени, то это часто будет Calc, так как эти имена означают, что для получения результата необходимо проделать определенную работу.
• Для более длительных операций вы начинаете получать префиксы, такие как Загрузка / Сохранение, Запрос / Хранение, Чтение / Запись, Поиск / Поиск и т. Д.

Таким образом, Get / Set может быть приписан полезному значению и быть частью более крупной, последовательной стратегии именования.

Лично я думаю, что геттеры и сеттеры, найденные в парах, являются запахом кода, перенесенным из «визуальных» языков и их «свойств». В «хорошем» классе члены данных доступны только для чтения или только для чтения, но не для чтения / записи.

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

Возможно, есть исключения, но я просто ненавижу смотреть на класс и находить "getX / setX, getY / setY и т. Д. И т. Д." Просто кажется, что недостаточно было продумано, как ДОЛЖЕН использоваться класс, и, скорее, автор сделал класс ЛЕГКИМ, чтобы получить доступ к данным, чтобы ему не пришлось думать о том, как этот класс следует использовать.

Естественно, я прав.

Я применяю соглашение, согласно которому метод всегда должен быть глаголом, а класс всегда должен быть существительным (за исключением функторов по очевидным причинам). В этом случае префикс get / set должен использоваться для согласованности. Тем не менее, я также полностью согласен с Эдом Свангреном. Для меня это сводится к тому, что использование этих префиксов не составляет труда.

Если ваш получатель просто rate(), ваш компилятор будет жаловаться, что это переопределение вашего другого символа rate, при условии, что вы дали своему полю хорошее понятное имя, подобное этому. В этом случае вам нужно сделать что-то глупое, например, назвать вашего члена _rate или какой-то другой подобный подход. Я лично ненавижу видеть / печатать эти подчеркивания, поэтому склоняюсь к подходу getRate().

Это, очевидно, субъективно, и это просто мои личные предпочтения.

I have always preferred to omit the 'get' on my getters, as you do, with rate() instead of getRate(). But overloading for the setter does not seem like a very good idea to me, since the name rate doesn't convey that the object is being mutated. Consider:

total(period() * rate()); // awesome, very clear

rate(20); // Looks like it computes a rate, using '20'...but for what?  And why ignore the return value?

While Ed's comment is true, I do prefer actual properties over the setter/getter antipattern. When 1/3rd of the methods in your domain graph are dummy methods that have been generated by eclipse, there's something wrong.

Without first class properties, however, I believe the antipattern makes the most sense.

Furthermore, it makes code completion easier.

obj.set (control shift space) for setters
obj.get (control shift space) for getters

A few years ago, I would have agreed completely. More recently, a doubt began to make its way, because that makes taking the address of a getter or setter ambiguous. With tools like tr1::bind, this is really annoying.

For example:

struct A
{
   void Foo(int);
   int Foo()const;
};

std::vector<A> v = ....;
std::vector<int> foos;
// Extract Foo
std::transform(
   v.begin(), v.end(), 
   std::back_inserter(foos), 
   //Ambiguous
   // std::tr1::bind(&A::Foo)
   //must write this instead. Yuck!
   std::tr1::bind(static_cast<int(Foo::*)()>(&A::Foo));
);

Leaving aside the question of should you have them at all ;-)

Being concise is important, but not at the cost of being incomplete or misleading. For that reason, I prefer GetFoo() and SetFoo() to Foo() and Foo(int foo).

Еще одна проблема, о которой никто не упомянул, - это случай функции перегрузка. Возьмем этот (надуманный и неполный) пример:

class Employee {
    virtual int salary() { return salary_; }
    virtual void salary(int newSalary) { salary_ = newSalary; }
};

class Contractor : public Employee {
    virtual void salary(int newSalary) {
        validateSalaryCap(newSalary);
        Employee::salary(newSalary);
    }
    using Employee::salary; // Most developers will forget this
};

Без этого с использованием предложения пользователи Подрядчик не могут запросить зарплату из-за перегрузки. Недавно я добавил -Woverloaded-virtual в набор предупреждений проекта, над которым я работаю, и, о чудо, это обнаружилось повсюду.

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

могут возникнуть проблемы:

class Stuff {
  void widget( int something ); // 'special' setter
  const Widget& widget( int somethingelse ) const; // getter
}
Stuff a; 
a.widget(1); // compiler won't know which widget you mean, not enough info