Присвоение значения переменной в классе [duplicate]

Ну, я просто хочу добавить, что даже если они иногда необходимы для инкапсуляции и безопасности ваших переменных / объектов, если мы хотим закодировать реальную объектно-ориентированную программу, тогда нам нужно STOP OVERUSING ACCESSORS , потому что иногда мы сильно зависим от них, когда это действительно не нужно, и это почти то же самое, что и мы ставим переменные public.

Один из основных принципов дизайна OO: Encapsulation!

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

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

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

person.name = "Joe";

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)