Зачем использовать геттеры и сеттеры / аксессоры?

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

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

Простой пример; мы генерируем заголовки c ++ из xml. Заголовок содержит простое поле, не требующее проверки. Но все же, поскольку в моде аксессуар OOPS, мы генерируем их следующим образом.

const Filed& getfield() const
Field& getField() 
void setfield(const Field& field){...} 

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

struct 
{
   Field field;
};

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

Существует разница между DataStructure и Object.

Структура данных должна раскрывать свое внутреннее состояние, а не поведение.

Объект не должен открывать свои внутренности, но он должен раскрывать свое поведение, которое также известно как Закон Деметры

В основном DTO считаются структурой данных, а не объектом. Они должны раскрывать только свои данные, а не поведение. Наличие Setter / Getter в DataStructure раскрывает поведение, а не данные внутри него. Это дополнительно увеличивает вероятность нарушения Закона Деметры .

Дядя Боб в своей книге «Чистый код» объяснил Закон Деметры.

Существует хорошо известная эвристика, называемая законом Деметры, которая гласит, что модуль не должен знать о внутренностях объектов, которые он манипулирует. Как мы видели в предыдущем разделе, объекты скрывают свои данные. и выставить операции. Это означает, что объект не должен открывать свои внутренняя структура через аксессоры, потому что это означает раскрытие, а не скрывать его внутреннюю структуру.

Точнее, Закон Деметры гласит, что метод f класса C следует вызывать только следующие методы:

• С
• Объект, созданный f
• Объект, переданный в качестве аргумента функции f
• Объект, содержащийся в переменной экземпляра C

Метод не должен вызывать методы для объектов, возвращаемых какой-либо из разрешенных функций. Другими словами, разговаривайте с друзьями, а не с незнакомцами.

Итак, в соответствии с этим, пример нарушения LoD:

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

Здесь функция должна вызывать метод своего непосредственного друга, который здесь ctxt. Она не должна вызывать метод своего непосредственного друга друга. но это правило не распространяется на структуру данных. так что здесь, если ctxt, option, scratchDir являются структурой данных, тогда зачем оборачивать их внутренние данные некоторым поведением и нарушением LoD.

Вместо этого мы можем сделать что-то вроде этого.

final String outputDir = ctxt.options.scratchDir.absolutePath;

Это соответствует нашим требованиям и даже не нарушает LoD.

На основе чистого кода Роберта К. Мартина (дядя Боб)

По моему опыту, идеально установить переменные как частные и предоставить средства доступа и модификаторы для каждой переменной.

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

Реализация ниже показывает переменную только для записи.

private String foo;
public void setFoo(String foo) { this.foo = foo; }
private String getFoo() { return foo; }

Ниже показана переменная только для чтения.

private String foo;
private void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

Геттеры и сеттеры, поступающие из , скрывающие данные . Скрытие данных означает, что мы скрывают данные от посторонних или посторонний человек / объект не может получить доступ наши данные. Это полезная функция в ООП.

Например:

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

public и private - модификаторы доступа.

Итак, как мы можем получить доступ к этой переменной извне:

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

Пример (Java):

private String name;

public String getName(){
   return this.name;
}

public void setName(String name){
   this.name= name;
}

Преимущество :

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

//assume we have person1 object
//to give permission to check balance
person1.getName()

//to give permission to set balance
person1.setName()

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

Одно относительно современное преимущество геттеров / сеттеров состоит в том, что они упрощают просмотр кода в редакторах тегированного (индексированного) кода. Например. Если вы хотите увидеть, кто устанавливает член, вы можете открыть иерархию вызовов установщика.

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

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

Я провел небольшой тест производительности. Я написал класс NumberHolder, который содержит целое число. Вы можете прочитать это целое число с помощью метода получения anInstance.getNumber() или путем прямого доступа к номеру с помощью anInstance.number. Моя программа считывает число 1 000 000 000 раз в обоих направлениях. Этот процесс повторяется пять раз, и время печатается. Получился следующий результат:

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

(Время 1 - прямой путь, Время 2 - получатель)

Видите ли, геттер (почти) всегда немного быстрее. Потом попробовал с разным количеством циклов. Вместо 1 миллиона я использовал 10 миллионов и 0,1 миллиона. Результаты:

10 миллионов циклов:

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

При 10 миллионах циклов время почти такое же. Вот 100 тысяч (0,1 миллиона) циклов:

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

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

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

Геттеры и сеттеры используются для реализации двух фундаментальных аспектов объектно-ориентированного программирования, а именно:

1. Абстракция
2. Инкапсуляция

Предположим, у нас есть класс Employee:

package com.highmark.productConfig.types;

public class Employee {

    private String firstName;
    private String middleName;
    private String lastName;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
       this.firstName = firstName;
    }
    public String getMiddleName() {
        return middleName;
    }
    public void setMiddleName(String middleName) {
         this.middleName = middleName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getFullName(){
        return this.getFirstName() + this.getMiddleName() +  this.getLastName();
    }
 }

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

РЕДАКТИРОВАТЬ: Я ответил на этот вопрос, потому что множество людей, изучающих программирование, задают этот вопрос, и большинство ответов очень технически компетентны, но их не так легко понять, если вы новичок. Мы все были новичками, поэтому я решил попробовать свои силы в более дружественном для новичков ответе.

Два основных из них - полиморфизм и проверка. Даже если это просто дурацкая структура данных.

Допустим, у нас есть этот простой класс:

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

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

Что происходит, когда я делаю:

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

Ну, вы же не ожидали, что это сработает, верно? Вы хотите, чтобы была какая-то проверка на вменяемость. И что еще хуже, что, если я никогда не указывал максимальную мощность? О боже, у нас проблема.

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

В итоге мы получим что-то вроде:

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

Отлично! А теперь просто изменим Bottle на это:

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

Я оставлю определение исключения BottleOverflowException в качестве упражнения для читателя.

Теперь обратите внимание, насколько это надежнее. Теперь мы можем работать с любым типом контейнера в нашем коде, приняв LiquidContainer вместо Bottle. И то, как эти бутылки справляются с подобными вещами, может быть разным. У вас могут быть бутылки, которые записывают свое состояние на диск при его изменении, или бутылки, которые сохраняются в базах данных SQL или GNU знает что еще.

И все они могут иметь разные способы справиться с различными воплями. Бутылка просто проверяет и, если она переполняется, выдает исключение RuntimeException. Но это может быть неправильным поступком. (Есть полезное обсуждение обработки ошибок, но я намеренно сохраняю его очень простым. Люди в комментариях, скорее всего, укажут на недостатки этого упрощенного подхода.;))

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

Обратите внимание, что вы не можете изменить вместимость бутылки. Теперь он высечен в камне. Вы можете сделать это с помощью int, объявив его final. Но если бы это был список, вы могли бы очистить его, добавить в него новые элементы и так далее. Вы не можете ограничить доступ прикосновением к внутренностям.

Есть еще третья вещь, о которой не все учли: геттеры и сеттеры используют вызовы методов. Это означает, что везде они выглядят как обычные методы. Вместо того, чтобы иметь странный специфический синтаксис для DTO и прочего, у вас везде одно и то же.

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

public class foo
{
    public int f1 { get; set; }             // A classic GS
    public int f2 { get; private set; }     // A GS with public read access, the write is only on the private level
    public int f3 { private get; set; }     // A GS where "You can set, but you can't get" outside the class
    public int f4 { get; set; } = 10;       // A GS with default value, this is a NEW feature of C# 6.0 / .NET 4.6
}

В чисто объектно-ориентированном мире геттеры и сеттеры - это ужасный антипаттерн . Прочтите эту статью: Геттеры / сеттеры. Зло. Период. Короче говоря, они побуждают программистов думать об объектах как о структурах данных, и этот тип мышления является чисто процедурным (как в COBOL или C). В объектно-ориентированном языке нет структур данных, а есть только объекты, которые демонстрируют поведение (не атрибуты / свойства!)

Вы можете найти больше о них в разделе 3.5 документа Elegant Objects (моя книга об объектно-ориентированном программировании).

Вы должны использовать геттеры и сеттеры, когда:

• Вы имеете дело с чем-то, что концептуально является атрибутом, но:
  • Ваш язык не имеет свойств (или какого-либо подобного механизма, например, трассировки переменных Tcl), или
  • Поддержка свойств вашего языка недостаточна для этого варианта использования, или
  • Идиоматические соглашения вашего языка (или иногда вашего фреймворка) поощряют геттеры или сеттеры для этого варианта использования.

Так что это очень редко общий вопрос OO; это вопрос, относящийся к конкретному языку, с разными ответами для разных языков (и разными вариантами использования).

С точки зрения объектно-ориентированной теории геттеры и сеттеры бесполезны. Интерфейс вашего класса - это то, что он делает, а не его состояние. (Если нет, значит, вы написали неправильный класс.) В очень простых случаях, когда класс делает просто, например представляют точку в прямоугольных координатах, * атрибуты являются частью интерфейса; геттеры и сеттеры просто затуманивают это. Но во всех случаях, кроме очень простых, ни атрибуты, ни геттеры и сеттеры не являются частью интерфейса.

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

_{* Даже для этого простого класса вам не обязательно разрешать установку значений x и y. Если это действительно класс, разве у него не должно быть таких методов, как translate, rotate и т. Д.? Если это всего лишь класс, потому что в вашем языке нет записей / структур / именованных кортежей, тогда это действительно не вопрос OO…}

Но никто никогда не занимается общим объектно-ориентированным дизайном. Они занимаются дизайном и реализацией на определенном языке. А в некоторых языках геттеры и сеттеры далеко не бесполезны.

Если ваш язык не имеет свойств, то единственный способ представить что-то, что концептуально является атрибутом, но на самом деле вычисляется, проверяется и т. Д., - это методы получения и установки.

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

Что касается вопроса «что, если я захочу изменить свою реализацию позже?» вопрос (который повторяется несколько раз в разных формулировках как в вопросе OP, так и в принятом ответе): если это действительно чистое изменение реализации, и вы начали с атрибута, вы можете изменить его на свойство, не затрагивая интерфейс. Если, конечно, ваш язык этого не поддерживает. Так что это действительно тот же случай.

Также важно следовать идиомам языка (или фреймворка), который вы используете. Если вы напишете красивый код в стиле Ruby на C #, у любого опытного разработчика C #, кроме вас, будут проблемы с его чтением, а это плохо. Некоторые языки имеют более сильную культуру вокруг своих соглашений, чем другие. - и, возможно, не случайно, что Java и Python, которые находятся на противоположных концах спектра идиоматических геттеров, имеют две из самых сильных культур.

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

Есть веская причина рассмотреть возможность использования аксессоров, если нет наследования свойств. См. Следующий пример:

public class TestPropertyOverride {
    public static class A {
        public int i = 0;

        public void add() {
            i++;
        }

        public int getI() {
            return i;
        }
    }

    public static class B extends A {
        public int i = 2;

        @Override
        public void add() {
            i = i + 2;
        }

        @Override
        public int getI() {
            return i;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.i);
        a.add();
        System.out.println(a.i);
        System.out.println(a.getI());
    }
}

Вывод:

0
0
4

Одно относительно современное преимущество геттеров / сеттеров состоит в том, что они упрощают просмотр кода в редакторах тегированного (индексированного) кода. Например. Если вы хотите увидеть, кто устанавливает член, вы можете открыть иерархию вызовов установщика.

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

Если вам нужна переменная только для чтения, но вы не хотите, чтобы клиент менял способ доступа к ней, попробуйте этот шаблонный класс:

template<typename MemberOfWhichClass, typename primative>                                       
class ReadOnly {
    friend MemberOfWhichClass;
public:
    template<typename number> inline bool   operator==(const number& y) const { return x == y; } 
    template<typename number> inline number operator+ (const number& y) const { return x + y; } 
    template<typename number> inline number operator- (const number& y) const { return x - y; } 
    template<typename number> inline number operator* (const number& y) const { return x * y; }  
    template<typename number> inline number operator/ (const number& y) const { return x / y; } 
    template<typename number> inline number operator<<(const number& y) const { return x << y; }
    template<typename number> inline number operator^(const number& y) const  { return x^y; }
    template<typename number> inline number operator~() const                 { return ~x; }
    template<typename number> inline operator number() const                  { return x; }
protected:
    template<typename number> inline number operator= (const number& y) { return x = y; }       
    template<typename number> inline number operator+=(const number& y) { return x += y; }      
    template<typename number> inline number operator-=(const number& y) { return x -= y; }      
    template<typename number> inline number operator*=(const number& y) { return x *= y; }      
    template<typename number> inline number operator/=(const number& y) { return x /= y; }      
    primative x;                                                                                
};      

Пример использования:

class Foo {
public:
    ReadOnly<Foo, int> cantChangeMe;
};

Помните, что вам также нужно будет добавить побитовые и унарные операторы! Это просто для начала

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

Например, переменная, которую вы никогда не намеревались использовать вне класса, может быть доступна даже напрямую через доступ к цепочке переменных (например, object.item.origin.x).

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

Пусть код говорит сам за себя:

Mesh mesh = new Mesh();
BoundingVolume vol = new BoundingVolume();
mesh.boundingVolume = vol;
vol.mesh = mesh;
vol.compute(); 

Тебе это нравится? Вот с установщиками:

Mesh mesh = new Mesh();
BoundingVolume vol = new BoundingVolume();
mesh.setBoundingVolume(vol);

Мы используем геттеры и сеттеры:

• для повторного использования
• для выполнения проверки на более поздних этапах программирования

Методы получения и установки являются общедоступными интерфейсами для доступа к частным членам класса.

Мантра инкапсуляции

Мантра инкапсуляции - сделать поля приватными, а методы общедоступными.

Методы получения: Мы можем получить доступ к частным переменным.

Методы установки: Мы можем изменять частные поля.

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

• лучше;
• безопаснее; и
• быстрее.

Везде, где можно использовать значение, можно добавить метод, возвращающий это значение. Вместо:

int x = 1000 - 500

использовать

int x = 1000 - class_name.getValue();

Говоря простым языком

Предположим, нам нужно сохранить детали этого Person. Этот Person имеет поля name, age и sex. Для этого нужно создать методы для name, age и sex. Теперь, если нам нужно создать другого человека, необходимо снова создать методы для name, age, sex.

Вместо этого мы можем создать bean-компонент class(Person) с помощью методов получения и установки. Итак, завтра мы можем просто создавать объекты этого Bean class(Person class) всякий раз, когда нам нужно добавить нового человека (см. Рисунок). Таким образом, мы повторно используем поля и методы класса bean-компонента, что намного лучше.

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

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

int getVar() const { return var ; }

Итак, у вас есть:

doSomething( obj->getVar() ) ;

Вместо

doSomething( obj->var ) ;

getVar() не только визуально шумит, но и создает иллюзию того, что gettingVar() каким-то образом является более сложным процессом, чем он есть на самом деле. То, как вы (как автор класса) относитесь к святости var, особенно сбивает с толку пользователя вашего класса, если у него есть установщик passthru - тогда похоже, что вы устанавливаете эти ворота, чтобы «защитить» то, на чем вы настаиваете. ценно (святость var), но даже вы признаете, что защита var не стоит многого из-за возможности любого просто войти и set var с любой ценностью, которую они хотят, без ты даже заглядывал в то, что они делают.

Итак, я программирую следующим образом (предполагая "гибкий" подход - то есть когда я пишу код, не зная точно , что он будет делать / у меня нет времени или опыта, чтобы спланировать сложный водопад набор интерфейсов стиля):

1) Начните со всех открытых членов для основных объектов с данными и поведением. Вот почему во всем моем "примере" кода C ++ вы заметите, что я везде использую struct вместо class.

2) Когда внутреннее поведение объекта для члена данных становится достаточно сложным (например, ему нравится сохранять внутренний std::list в некотором порядке), записываются функции типа доступа. Поскольку я программирую сам, я не всегда сразу устанавливаю член private, но где-то в процессе развития класса член будет «повышен» до protected или private.

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

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

Методы получения и установки являются методами доступа, что означает, что они обычно являются общедоступным интерфейсом для изменения частных членов класса. Для определения свойства используются методы получения и установки. Вы получаете доступ к методам получения и установки как к свойствам вне класса, даже если вы определяете их внутри класса как методы. Эти свойства вне класса могут иметь имя, отличное от имени свойства в классе.

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

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

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

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

Часто упоминаемое преимущество пар геттер / сеттер - нет. Утверждается, что вы можете изменить реализацию, и ваших клиентов не нужно перекомпилировать. Предположительно, сеттеры позволяют позже добавлять такие функции, как проверка, и вашим клиентам даже не нужно об этом знать. Однако добавление валидации к сеттеру - это изменение его предварительных условий, нарушение предыдущего контракта , которое было, попросту говоря, «вы можете вставить сюда что угодно, и вы можете получить то же самое позже из получатель ".

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

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

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

Если у класса есть эти глупые геттеры и сеттеры для каждого поля, то это класс, который не имеет никаких инвариантов, без контракта . Это действительно объектно-ориентированный дизайн? Если все, что у класса есть, - это геттеры и сеттеры, это просто тупой держатель данных, а тупые держатели данных должны выглядеть как тупые держатели данных:

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

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

Клиент : «Что я могу сделать с объектом этого класса?»
Дизайнер : «Вы можете читать и записывать несколько переменных» <2938890338846352> > Клиент : «О ... круто, я думаю?»

Есть причины использовать геттеры и сеттеры, но если этих причин не существует, создание пар геттер / сеттер во имя ложных богов инкапсуляции нехорошо. К веским причинам для создания геттеров или сеттеров относятся вещи, которые часто упоминаются как потенциальные изменения, которые вы можете внести позже, например, проверка или различные внутренние представления. Или, может быть, значение должно быть доступно для чтения клиентам, но не для записи (например, для чтения размера словаря), поэтому простой метод получения - хороший выбор. Но эти причины должны присутствовать, когда вы делаете выбор, а не только как потенциальная вещь, которую вы можете захотеть позже. Это экземпляр YAGNI ( Вам это не понадобится ).

Ну, я просто хочу добавить, что даже если иногда они необходимы для инкапсуляции и безопасности ваших переменных / объектов, если мы хотим закодировать настоящую объектно-ориентированную программу, тогда нам нужно ОСТАНОВИТЬ ПЕРЕСЕЧЕНИЕ АКСЕССУАРЫ , потому что иногда мы сильно зависим от них, когда в этом нет необходимости, и это почти то же самое, как если бы мы сделали переменные общедоступными.

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

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

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

У меня есть массивная система, написанная без геттеров-сеттеров, только с модификаторами доступа и некоторыми методами для проверки выполнения бизнес-логики. Если вам абсолютно необходим файл. Используйте что угодно.

С точки зрения объектно-ориентированного дизайна обе альтернативы могут нанести ущерб сопровождению кода из-за ослабления инкапсуляции классов. Для обсуждения вы можете заглянуть в эту отличную статью: http://typicalprogrammer.com/?p=23

Спасибо, это действительно прояснило мои мысли. Вот (почти) 10 (почти) веских причин НЕ использовать геттеры и сеттеры:

1. Когда вы понимаете, что вам нужно сделать больше, чем просто установить и получить значение, вы можете просто сделать поле частным, что сразу же сообщит вам, где вы непосредственно к нему обратились.
   
2. Любая проверка, которую вы выполняете там, может быть только контекстно-свободной, что на практике встречается редко.
   
3. Вы можете изменить установленное значение - это абсолютный кошмар, когда вызывающий передает вам значение, которое они [ужас шока] хотят, чтобы вы сохранили КАК ЕСТЬ.
   
4. Вы можете скрыть внутреннее представление - фантастика, значит, вы убедитесь, что все эти операции симметричны, верно?
   
5. Вы изолировали свой общедоступный интерфейс от изменений под листами - если вы разрабатывали интерфейс и не были уверены, что прямой доступ к чему-либо в порядке, то вам следовало продолжить проектирование.
   
6. Некоторые библиотеки ожидают этого, но не многие - отражение, сериализация, фиктивные объекты прекрасно работают с общедоступными полями.
   
7. Унаследовав этот класс, вы можете переопределить функциональность по умолчанию - другими словами, вы можете ДЕЙСТВИТЕЛЬНО запутать вызывающих абонентов, не только скрывая реализацию, но и делая ее несовместимой.
   

Последние три я просто ухожу (N / A или D / C) ...

Я хотел опубликовать реальный пример, который я только что закончил:

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

package com.foo.entities.custom
class User extends com.foo.entities.User{
     public Integer getSomething(){
         return super.getSomething();             
     }
     public void setSomething(Integer something){
         something+=1;
         super.setSomething(something); 
     }
}

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

Я долго обдумывал это для случая Java, и я считаю, что настоящие причины таковы:

1. Код интерфейса, а не реализация
2. Интерфейсы определяют только методы, а не поля

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

Эти методы - печально известные методы получения и установки ....

Я просто хотел бы подбросить идею аннотации: @getter и @setter. С @getter вы должны иметь возможность obj = class.field, но не class.field = obj. С @setter наоборот. С @getter и @setter вы сможете делать и то, и другое. Это сохранит инкапсуляцию и сократит время, не вызывая тривиальные методы во время выполнения.

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

Допустим, вы просматриваете сотни строк кода и наталкиваетесь на следующее:

person.name = "Joe";

Это красиво простой фрагмент кода, пока вы не поймете, что это сеттер. Теперь вы следуете за этим установщиком и обнаруживаете, что он также устанавливает person.firstName, person.lastName, person.isHuman, person.hasReallyCommonFirstName и вызывает person.update (), который отправляет запрос в базу данных и т. Д. где произошла утечка памяти.

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

В объектно-ориентированном языке методы и их модификаторы доступа объявляют интерфейс для этого объекта. Между конструктором и методами доступа и мутатора разработчик может управлять доступом к внутреннему состоянию объекта. Если переменные просто объявлены общедоступными, то этот доступ невозможно регулировать. И когда мы используем сеттеры, мы можем ограничить пользователя для ввода, который нам нужен. Это означает, что поток для этой самой переменной будет поступать по правильному каналу, который заранее определен нами. Так что безопаснее использовать сеттеры.

Это может быть полезно для отложенной загрузки. Допустим, объект, о котором идет речь, хранится в базе данных, и вы не хотите получать его, если он вам не нужен. Если объект извлекается геттером, тогда внутренний объект может быть нулевым, пока кто-нибудь его не попросит, затем вы можете получить его при первом вызове геттера.

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

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

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

    protected YourType _yourName = null;
    public YourType YourName{
      get
      {
        if (_yourName == null)
        {
          _yourName = new YourType();
          return _yourName;
        }
      }
    }

Один аспект, который я пока упустил в ответах, это спецификация доступа:

• для членов у вас есть только одна спецификация доступа для установки и получения
• для сеттеров и геттеров вы можете точно настроить и определить его отдельно

Зависит от вашего языка. Вы отметили это «объектно-ориентированным», а не «Java», поэтому я хотел бы отметить, что ответ ChssPly76 зависит от языка. В Python, например, нет причин использовать геттеры и сеттеры. Если вам нужно изменить поведение, вы можете использовать свойство, которое обертывает геттер и сеттер вокруг доступа к базовому атрибуту. Примерно так:

 class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)

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

Есть много причин. Мне больше всего нравится, когда вам нужно изменить поведение или отрегулировать то, что вы можете установить для переменной. Например, допустим, у вас есть метод setSpeed ​​(int speed). Но вы хотите, чтобы вы могли установить максимальную скорость только 100. Сделайте что-то вроде:

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

А что, если ВЕЗДЕ в коде вы использовали публичное поле, а затем поняли, что вам нужно указанное выше требование? Получайте удовольствие от поиска каждого использования публичного поля вместо того, чтобы просто изменять свой сеттер.

Мои 2 цента :)

Кроме того, это сделано для «будущего» вашего класса. В частности, переход от поля к свойству является нарушением ABI, поэтому, если вы позже решите, что вам нужно больше логики, чем просто «установить / получить поле», тогда вам нужно сломать ABI, что, конечно, создает проблемы для чего угодно. остальное уже скомпилировано для вашего класса.

В языках, которые не поддерживают «свойства» (C ++, Java) или требуют перекомпиляции клиентов при изменении полей на свойства (C #), использование методов get / set легче изменить. Например, добавление логики проверки к методу setFoo не потребует изменения открытого интерфейса класса.

В языках, поддерживающих «реальные» свойства (Python, Ruby, может быть, Smalltalk?), Нет смысла получать / устанавливать методы.

Один из основных принципов объектно-ориентированного проектирования: Инкапсуляция !

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

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

Например, если foo был общедоступным, я мог бы легко установить его на null, а затем кто-то другой мог бы попытаться вызвать метод объекта. Но его больше нет! С помощью метода setFoo я мог гарантировать, что для foo никогда не будет установлено значение null.

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

Поскольку через 2 недели (месяцы, годы), когда вы поймете, что вашему установщику нужно сделать больше , чем просто установить значение, вы также поймете, что свойство использовалось непосредственно в 238 других классы :-)