Почему Google называет методы доступа и мутаторы после переменных-членов?
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Function_Names#Function_Names
Регулярные функции имеют смешанный регистр; аксессоры и мутаторы соответствуют
имя переменной: MyExcitingFunction (), MyExcitingMethod (),
my_exciting_member_variable (), set_my_exciting_member_variable ().
Не в этом ли смысл инкапсуляции, чтобы скрыть детали реализации от пользователя, чтобы он не знал, возвращает ли метод доступа / мутатора / изменяет переменную-член или нет? Что, если я изменил имя переменной или изменил способ ее хранения внутри объекта?
РЕДАКТИРОВАТЬ:
Если у меня есть экземпляр переменной int foo_ это кажется простым
int foo() const { return foo_; }
но если я добавлю другой метод, который возвращает foo_ + 2Должен ли я назвать, если bar или же GetBar?
int bar() const { return foo_ + 2; }
int GetBar() const { return foo_ + 2; }
Если я выберу GetBar и позже решите кэшировать возвращаемое значение в другой переменной-члене bar_мне придется переименовать метод в bar?
Решение
На самом деле, смысл инкапсуляции в том, чтобы скрыть внутренние работы класса, не обязательно, чтобы скрыть имена вещей. Имя переменной-члена не имеет значения; это уровень косвенности что обеспечивает аксессор или мутатор.
Наличие средства доступа дает вам возможность изменять внутреннюю работу класса (включая имена переменных-членов), не нарушая интерфейс класса с внешним миром. Пользователю класса не нужно заботиться о деталях реализации, в том числе о том, какие вещи названы внутри класса, но только о поведение класса, как видно снаружи.
Другими словами, пользователи класса не следует полагаться на руководство по стилю Google, чтобы определить, изменяют ли они переменную-член.
Другие решения
Поскольку руководство по стилю Google предназначено только для сотрудников Google. Скорее — это не очень хороший гид по стилю.
Показательный пример — они явно запрещают передачу по неконстантной ссылке, потому что это может быть «запутанным».
Таким образом, вы правы, это побеждает цель инкапсуляции. Не ведите себя этим.
Рассматривая класс, он может концептуально иметь видимый
состояние, к которому может обратиться клиент. Как это состояние
Представленный внутри класса другой вопрос, и это то, что
аксессоры (геттеры и сеттеры) прячутся. Мое собственное соглашение об именах
также делает это различие: если функция концептуально
геттер или сеттер, он имеет имя атрибута, который
обычно будет существительным; в противном случае это глагол. А также
Я различаю случаи, когда функция получает или
установка чего-то, что концептуально не является частью класса
(например, который частично зависит от аргумента), которые имеют
глагол get или же set в их названии и в случае, когда
функция на самом деле модифицирует то, что концептуально
атрибут, в этом случае они этого не делают.
В остальном, как и в большинстве руководств по стилю, не все
согласие с этим. Я не уверен, что мне нравится их названия
условности, например. Они называются соглашениями об именах
потому что они просто: произвольные соглашения. Единственный
реальное жесткое правило заключается в том, что типы, макросы и другие вещи должны быть
отличаться, и что имена никогда не должны начинаться или заканчиваться
нижнее подчеркивание. (Есть также несколько более мягких правил: я бы очень
с подозрением к конвенции, которая в конечном итоге делает имена
локальные переменные длиннее, чем у глобальных.)
Возможно, я слишком далеко зашёл о здравом смысле, но я уверен, что сохранение опубликованного интерфейса имеет приоритет перед тем, как следовать руководству по именованию.
Так как ваш оригинал bar / GetBar функция не аксессор, я полагаю, он должен следовать обычному руководству по именам и называться GetBar,
Если вы позже представите bar_ так что в некотором смысле функция становится средством доступа, я уверен, что вам не следует удалять GetBar, Я полагаю, вы могли бы добавить функцию bar() а также, чтобы сделать то же самое, но я не считать Я бы интерпретировал руководство по стилю, чтобы требовать этого.
Я также почти уверен, что, как только ваш опубликованный интерфейс включает функции, которые вы (и вызывающие) воспринимаете как «средства доступа», инкапсуляция в любом случае выходит за пределы окна, потому что вы говорите о состоянии объект вместо его поведения. Тот факт, что функция возвращает значение переменной-члена в текущей реализации, не означает, что она должна быть задокументирована как средство доступа. Но если ты делать настаивайте на написании функций, которые публично признаны в качестве аксессоров, Google скажет вам, как их назвать. Классическим примером является то, что достаточно тупой объект записи данных может иметь разумные средства доступа, так как весь класс публично определен как набор полей с, возможно, небольшим поведением.
Я читал это руководство по стилю несколько раз прежде, но я никогда не работал на Google, поэтому я не знаком с тем, как их обзоры кода имеют тенденцию применять его на практике. Я должен думать, что организация такого размера не может быть полностью последовательно в каждой детали. Так что ваше предположение, вероятно, так же хорошо, как и мое.