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

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

Голуб не верит, что вы знаете разницу. Я думаю, что знание разницы - вот что делает вас профессионалом.

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

Мыслительный процесс должен быть последовательным; Что этот объект делает? Каковы его обязанности? Каково его поведение? Что он знает? Долгое и упорное размышление над этими вопросами естественным образом приводит вас к разработке классов, которые предоставляют максимально возможный интерфейс самого высокого уровня.

Автомобиль - хороший тому пример. Он предоставляет четко определенный стандартизированный высокоуровневый интерфейс. Я не забочусь о _1 _... это миль / ч или км / ч? Я просто ускоряюсь, круизу, замедляю. Мне не нужно думать о деталях в setSteeringWheelAngle(getSteeringWheelAngle()+Math.rad(-1.5)), я просто turn(-1.5), а детали заботятся под капотом.

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

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

Это тот менталитет, который он продвигает. Геттеры и сеттеры - это ловушка, в которую легко попасть.

Да, для bean-компонентов в основном требуются геттеры и сеттеры, но для меня bean-компонент - это особый случай. Бобы представляют собой существительные, вещи, материальные идентифицируемые (если не физические) объекты. На самом деле не многие объекты обладают автоматическим поведением; в большинстве случаев вещами манипулируют внешние силы, в том числе люди, чтобы сделать их продуктивными.

daisy.setColor(Color.PINK) имеет смысл. Что еще можно сделать? Может быть, вулканское слияние разумов заставило цветок захотеть стать розовым? Хм?

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

Я думаю, что Аллен Голуб попытался перефразировать в этой статье следующее.

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

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

(обратите внимание, я прихожу к этому с точки зрения .NET "свойства")

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

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

Аксессоры не являются деталью реализации; они являются публичным API / контрактом. Ага, если вы нарушите договор, у вас будут проблемы. Когда это стало неожиданностью? Точно так же методы доступа нередко бывают нетривиальными, т. Е. Они делают больше, чем просто обертывают поля; они выполняют вычисления, логические проверки, уведомления и т. д. И они позволяют абстракции состояния на основе интерфейса. Да, и полиморфизм - и т. Д.

Что касается подробного характера средств доступа (p3? 4?) - в C #: public int Foo {get; private set;} - работа выполнена.

В конечном итоге весь код - это средство выражения нашего намерения компилятору. Свойства позволяют мне делать это типобезопасным, контрактным, проверяемым, расширяемым и полиморфным способом - спасибо. Зачем мне это «исправлять»?

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

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

Я дополнительно погуглил по Аллену Холубу, похоже, у него есть свои противники в сообществе Java.

• Аллен Холуб - зло
• Злой судья
• Holub снова за дело

Последний особенно отмечен. Текст комментатора выделен курсивом.

Хотя getIdentity начинается с get, это не метод доступа, потому что он не просто возвращает поле. Он возвращает сложный объект с разумным поведением.

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

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

Имейте в виду, что я на самом деле не вставлял UI-код в бизнес-логику. Я написал уровень пользовательского интерфейса в терминах AWT (Abstract Window Toolkit) или Swing, которые являются слоями абстракции.

Хороший. Что делать, если вы пишете свое приложение на SWT? Насколько абстрактно в таком случае AWT? Посмотрим правде в глаза: этот совет просто побуждает вас писать код пользовательского интерфейса в своей бизнес-логике. Какой отличный принцип. В конце концов, прошло не менее десяти лет с тех пор, как мы определили эту практику как одно из худших дизайнерских решений, которые вы можете принять в проекте.

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

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

Например, хотя некоторые не согласятся, мне нравится стандартный API Java. Мне также нравится Spring Framework. Глядя на классы в этих библиотеках, вы заметите, что очень редко есть сеттеры и геттеры, которые существуют только для того, чтобы предоставить некоторую внутреннюю переменную. Существуют методы с именем getX, но это не означает, что это метод получения в обычном смысле.

Итак, я думаю, что он прав, и вот что: каждый раз, когда вы нажимаете «Создать геттеры / сеттеры» в Eclipse (или в вашей IDE по выбору), вы должны сделать шаг назад и задуматься о том, что вы делаете. Действительно ли уместно раскрывать это внутреннее представление, или я на каком-то этапе испортил свой дизайн?

Я не верю, что он говорит, что никогда не используйте get / set, но скорее, использование get / set для поля не лучше, чем просто сделать поле общедоступным (например, общедоступная строка Name vs. общедоступная строка Name {get; set;}).

Если используется get / set, он ограничивает скрытие информации OO, что потенциально может заблокировать вас в плохом интерфейсе.

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

Однако, если вместо использования get / set у вас изначально был такой метод, как Add (имя строки), внутри вы могли бы обрабатывать имя по отдельности или добавлять в список или что-то еще и извне вызывать метод Add столько раз, сколько хотите добавить больше имен.

Цель объектно-ориентированного проектирования - проектировать с уровнем абстракции; не раскрывайте больше деталей, чем это необходимо.

Скорее всего, если вы только что обернули примитивный тип с помощью get / set, вы нарушили этот принцип.

Конечно, это если вы верите в цели OO; Я считаю, что в большинстве случаев это не так, они просто используют объекты как удобный способ группировки функционального кода.

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

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

У геттеров и сеттеров есть некоторые преимущества перед общедоступными переменными. Они обеспечивают некоторое разделение интерфейса и реализации. Тот факт, что точка имеет функцию .getX(), не означает, что должен быть x, поскольку .getX() и .setX() могут нормально работать с радиальными координатами. Другой заключается в том, что можно поддерживать инварианты классов, делая все необходимое для сохранения согласованности класса в установщике. Во-вторых, можно иметь функциональные возможности, запускаемые по набору, такие как ведение журнала баланса банковского счета.

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

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

То, что геттеры и сеттеры часто используются чрезмерно, не означает, что они бесполезны.

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

Это нарушает инкапсуляцию, потому что, когда вы вызываете метод get / set, вам сначала нужно знать имя (или иметь хорошее представление) о поле, которое вы хотите изменить, а во-вторых, вы должны знать его тип, например. ты не мог позвонить

setPositionX("some string");

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

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

public void tryPositionX(int x) throws InvalidParameterException{
    if (x >= 0)
        this.x = x;
    else
        throw new InvalidParameterException("Holy Negatives Batman!");
}

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

tryPositionXAndLog(int x) throws InvalidParameterException{
    tryPositionX(x);
    numChanges++;
}

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

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

Публичные геттеры / сеттеры плохи, если они предоставляют доступ к деталям реализации. Тем не менее, разумно предоставить доступ к свойствам объекта и использовать для этого геттеры / сеттеры. Например, если Car имеет свойство color, можно позволить клиентам «наблюдать» за ним с помощью геттера. Если какому-то клиенту нужна возможность перекрашивать автомобиль, класс может предоставить установщик (хотя «перекрасить» - более понятное название). Важно не сообщать клиентам, как свойства хранятся в объектах, как они поддерживаются и т. Д.

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

На всякий случай, если кто-то не совсем понимает концепцию инкапсуляции, прочтите об этом здесь:

Инкапсуляция (информатика)

... и если они действительно злые, сможет ли .NET встроить в язык концепцию Property? (Методы Getter и Setter, которые выглядят немного красивее)

ИЗМЕНИТЬ

В статье упоминается инкапсуляция:

«Геттеры и сеттеры могут быть полезны для переменных, которые вы конкретно хотите инкапсулировать, но вам необязательно использовать их для всех переменных. Фактически, использование их для всех переменных - неприятный запах кода.»

Использование этого метода приведет к тому, что в долгосрочной перспективе будет чрезвычайно сложно поддерживать код. Если на полпути к проекту, рассчитанному на несколько лет, вы обнаружите, что поле необходимо инкапсулировать, вам придется обновить КАЖДУЮ ССЫЛКУ этого поля повсюду в вашем программном обеспечении, чтобы получить выгоду. Намного разумнее использовать правильную инкапсуляцию заранее и избавить себя от головной боли позже.

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