Вкратце прочитав вышеприведенную статью, я обнаружил, что геттеры и сеттеры плохо работают с OO, и их следует избегать, поскольку они идут против инкапсуляции и скрытия данных. Поскольку это так, как его можно избежать при создании объектов и как можно моделировать объекты модели.
В случаях, когда требуется геттер или сеттер, какие другие альтернативы могут быть использованы?
Спасибо.
Получатели или сеттеры сами по себе не плохой дизайн OO.
Плохая практика кодирования, которая включает в себя getter AND setter для КАЖДОГО отдельного элемента автоматически, нужен или нет этот getter/setter (в сочетании с тем, чтобы публиковать члены, которые не должны быть общедоступными), поскольку это в основном предоставляет реализацию класса внешнему миру, нарушающему скрытие/абстрагирование информации. Иногда это делается автоматически с помощью IDE, что означает, что такая практика значительно более распространена, чем она надеялась.
Вы пропустили точку. Действительный важный бит этой статьи:
Не запрашивайте необходимую информацию выполнять работу; спросите объект, что имеет информацию для работы вы.
Расширение гейтера и сеттера в стиле Java - это симптомы игнорирования этого совета.
Я верю в включение сеттеров в API только в том случае, если они действительно являются частью спецификации класса (т.е. его контракта с вызывающим абонентом).
Любой другой элемент данных, связанный с внутренним представлением, должен быть скрыт, и я вижу по крайней мере две основные причины этого:
1) Если внутреннее представление открыто, изменения в дизайне в будущем будут более проблематичными, а также потребуются изменения API.
2) Предоставление пользователям данных с сеттерами/геттерами без осторожности позволяет абонентам очень легко разрушать инвариант класса. Объекты с несогласованным состоянием могут вызывать ошибки, которые очень трудно анализировать.
К сожалению, есть некоторые рамки, которые поощряют (иногда требуют) добавление сеттеров/геттеров для всего.
Геттеры и сеттеры не плохи сами по себе. Плохое - это практика, заключающаяся в том, чтобы сделать любое поле частным и предоставлять получателям/сеттерам для всех, независимо от того, что.
Да, getters и seters - это анти-шаблон в ООП: http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html. В двух словах они не вписываются в объектно-ориентированную парадигму, потому что они поощряют вас рассматривать объект как структуру данных. Это серьезное заблуждение.
Как я его читаю, автор утверждает, что слепое размещение геттеров и сеттеров вокруг полей не лучше, чем просто публикация поля.
Я считаю, что автор утверждает, что геттеры и сеттеры должны быть размещены редко и с осторожностью, потому что идея OO заключается в том, что объекты должны ограничивать их воздействие только тем, что необходимо.
Я пойду немного дальше и скажу, что только типы значений должны иметь геттеры. Каждый тип значения должен быть неизменным и иметь конструктор, который изменен и имеет сеттеры.
Если у вашего типа значений есть сеттеры, они должны возвращать новый экземпляр после копирования других значений.
Url.setAnchor(...)
Вернул бы новый Url, копирующий хост-порт и т.д., но перезаписывая якорь.
В классах типа обслуживания не нужны сеттеры (задайте их в ctor) и определенно нужны шрифты. Ваш Mailer должен взять статический файл host/port/etc в нем ctor. Если я хочу отправить электронное письмо, то я его отправлю(), нет причин, по которым мой код должен знать или требовать или требовать значения хоста и других параметров конфигурации. При этом было бы целесообразно создать класс MailServer, например, следующий // тип значения MsilServer { Строковый хост int port Имя пользователя String Зашифрованный пароль//все приходят рут-геттеры } // factory Mailer create (MailServer)
Я предлагаю вам внимательно прочитать всю статью, поскольку она представляет собой продуманные аргументы и альтернативы. Вопрос сам по себе слишком открытый, и ответы, которые вы получите здесь, будут просто более точными.
Getters и seters - это просто методы. Что они делают? Они меняют поле в свойство, и это важное различие.
Поле - это бит данных, состояния, объекта. Свойство является внешне наблюдаемой характеристикой, частью договора объекта. Разбрызгивание кистей предмета повсюду, будь то напрямую или через геттеры/сеттеры, всегда является плохими идеями. Плохой дизайн. Но поднимать это до такой степени, что говорить, что геттеры и сеттеры всегда плохи? Это просто какой-то плохой программист без ощущения хорошего вкуса, утверждая, что неопределенное эмпирическое правило (которое они действительно не понимают в первую очередь) - это закон чугуна.
Лично я склонен стараться сохранить свойства как вещи, которые неожиданно не изменяются под ногами клиентов. (Клиенты класса, который есть.) Единственные свойства, которые я буду менять динамически, - это те, которые они не могут писать, и даже тогда я постараюсь избежать этого. Я чувствую, что свойства во многом представляют собой ценности, которые управляют поведением экземпляра, заданного клиентом, а не произвольными элементами, находящимися под контролем класса. (Это нормальное поле для...)
Из статьи:
Когда аксессор в порядке? Во-первых, поскольку я обсуждалось ранее, это хорошо для метод возврата объекта в терминах интерфейс, который объект реализует, потому что этот интерфейс изолирует вас от изменений в реализующий класс. Этот вид метод (который возвращает интерфейс ссылка) на самом деле не является "геттером" в смысл метода, который просто обеспечивает доступ к полю. если ты изменить внутренний провайдер реализации, вы просто меняете определение возвращаемого объекта учитывать изменения. Ты все еще защищать внешний код, который использует объект через его интерфейс.
Другими словами, используйте интерфейсы для методов getter и setter, когда они необходимы, чтобы поддерживать инкапсуляцию. В общем случае хорошей практикой является указание интерфейса для типа возврата или формального параметра.
Есть и другие статьи, которые говорят, что они хороший дизайн. Но ответ таков: getXXX и setXXX являются хорошими или плохими на основе использования. эти матоды делают многое проще. Поэтому, если какая-то статья говорит, что это плохой дизайн, я думаю; это просто пытается быть слишком сложным в этой идее.
Одно из самых больших применений этих методов находится во многих рамках и используется как механизм отражения.
Так что не полностью избегайте их использования, а... используйте его разумно.
спасибо Ayusman
Getters and Setters - плохой дизайн OO?
Только при использовании без мышления.
Если вы хотите создать объект-значение для переноса данных, все будет в порядке.
Если вы создаете более важный объект, их там не должно быть. Посмотрите на интерфейс ArrayList * например. Вы не видите Object[] getElementData(), потому что это сломает инкапсуляцию (кто-то может умерить базовый массив).
* Im ссылаясь на публичный интерфейс класса (методы, обнаруженные определением класса)
Getters/Setters идеально подходят в правильных условиях. Однако массовый Get/Set ошибочен.
Однако я немного запутался. Вы отметили Java, но материал на самом деле не является специфичным для Java (только для примеров). Стоит отметить, что в С++ (лучше всего сделано в 0x) многие из этих проблем не существуют. Если вы хотите изменить свой интерфейс от long до int, то между decltype, templates и auto это легко достижимо, и именно поэтому такие конструкции порождают. Typedef тоже хорошо работает.