Имеет ли смысл предоставлять неконстантную ссылку getter

Question

Иногда мне нужно выставить некоторые из членов класса. Например, в следующем примере class Mechanic может потребоваться прямой доступ к компоненту Engine. Я много раз читал, что все поля должны быть доступны с помощью методов mutator (accessor) по нескольким причинам. Но есть ли какое-либо преимущество при предоставлении неконстантного ссылочного поглотителя:

class Car 
{ 
    public: 
     Engine & engine() 
     { 
      return m_engine; 
     } 

     //as a consequence you will also need to provide const version 
     const Engine & engine() const 
     { 
      return m_engine; 
     } 

    private: 
     Engine m_engine; 
} 

более просто делают компонент двигателя общественности:

class Car 
{ 
    public: 
     Engine engine; 
} 

Вы также можете заменить public с protected, если вам не нравится этот пример. В реальной жизни у вас есть что-то simillar на Java, когда дело доходит до System.in или System.out. Похоже, чтобы быть полностью совместимым с тем, что говорят некоторые люди, вам нужно будет выполнить такие вызовы, как System.getInstance().getOut().println("hello world"). В таких случаях я не вижу никакой пользы, кроме большого количества бюрократического кода.

Answer 1

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

Answer 2

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

template<class T> class Singleton 
{ 
private: 
    static T* m_pSingleton; 

public: 
    T& getSingleton() { assert(m_pSingleton); return(*m_pSingleton); }; 

}; // eo class Singleton 

Answer 3

Для меня это имеет смысл здесь:

image(i,j) = 234; 

Answer 4

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

Answer 5

Явные геттеры и сеттеры могут быть чрезмерно бюрократическими; это зависит от вашей ситуации.

Основная причина использования функций getter и setter заключается в том, что он изолирует клиентов вашего класса от потенциальных изменений в реализации в будущем (например, рассмотрите, что произойдет, если вы решите создать объект Engine по запросу (а не использовать переменную-член) или решить скрыть ее за умным указателем или другим контейнером).

Если ваш класс, если он очень простой (например, близкий к POD) и вряд ли изменится, то, возможно, не стоит того, чтобы внедрять геттеры и сеттеры.

Однако, чтобы ответить на ваш вопрос, неконстантный геттер, вероятно, не имеет большого смысла. Ваш прототип геттера должен быть Engine & engine() const; иначе вы не сможете позвонить по телефону constCar объектов.

Answer 6

Вместо того, чтобы думать о том, чтобы подвергать частные члены класса, подумайте больше о методах вызова на этих классах. Я прочитал интересную статью Java, Why Getter and Setter Methods are Evil, которая так же применима к C++, как и к Java.

Answer 7

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

Answer 8

Да, это имеет смысл - для удобства обслуживания, проверки и согласованности.

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

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

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

Answer 9

В этом случае вы бы скорее нужен Car.fix(const Mechanic&) функцию, которая затем дает двигатель к Mechanic, сказать: Engine.fix(const Mechanic&), как я полагаю, что состояние Engine будет изменен.

Первоначальная идея использования классов состояла в том, чтобы связать данные с его функциями доступа. Если вы используете setter или getter, который просто возвращает внутренние данные, это означает, что ваши данные не связаны вместе со своими функциями доступа: ваш класс не завершен.

Вы хотите только показать новые данные, которые класс испускает. Скажите Car.get_exhaust() и Car не имеет выхлопных газов, производит только его, когда вы спрашиваете об этом. ;)

Или Fire Riefle.fire() в то время как нет доступа к Riefle::Trigger не будет зафиксирован механиком, как так: Trigger.fix_by(Mechanic), а затем fix_by позвонит сказать Mechanic.add_working_hour(0.5). XD