Единственным (кроме вышеупомянутого Синглтона и его соучастника в преступлении, Фабрики) не будет GoF, это будут сеттеры и геттеры при применении к собственным свойствам объекта.
Установщики и получатели, применяемые к переменным-членам, функционально идентичны общедоступным переменным-членам. Получатель без установщика больше похож на общедоступную конечную переменную-член - но в этот момент, почему бы просто не использовать общедоступную переменную-конечный член, они больше не причиняют вреда ...
Единственная разница в том, что вы "могли" перехватить вызов и переопределить его, но люди редко делают. Чаще всего он используется в качестве опоры для процедурных программистов, чтобы избежать программирования ОО (что является реальной причиной того, что это анти-паттерн).
Используя сеттер и / или геттер, вы по-прежнему выставляете свою внутреннюю структуру-член для внешнего мира (например, вам придется реорганизовать другие классы, если вы обнаружите, что вам нужно изменить int на long), и вы почти гарантируя, что некоторый код, который должен быть внутри вашего объекта, вместо этого размещается снаружи.
Есть несколько исключений, о которых я могу подумать:
Сеттеры, используемые для упрощения конструкции объектов. Иногда необходимо создать объект, а затем установить другие значения. Эти значения должны быть неизменными (вы не должны вызывать set дважды) для безопасности.
Геттеры, используемые для доступа к содержащимся объектам. Поскольку содержащиеся в них объекты обычно способны обеспечить собственную целостность, делиться ими замечательно. В этом случае сеттеры, как правило, плохие, вы не хотите, чтобы объект с определенным состоянием выгружался прямо под вашим носом, это значительно затрудняет обеспечение вашей собственной целостности.
Java Beans, используемые для компонентов экрана: Да, не могу найти лучшего способа реализовать эти "шары свойств". Отражение пригодится для этого компонента, шаблоны полезны - это довольно странно, но работает.
Объекты DAO / DTO Bean. Честно говоря, я думаю, что это ненадежное использование паттерна, но это паттерн . Это делает манипулирование свойствами с помощью метаданных вместо кода гораздо сложнее, чем должно быть, поскольку оно должно быть отражающим. Свойства bean-компонентов всегда связаны с каким-либо внешним источником (формат базы данных, формат передачи данных, свойства компонента, ...), так почему же мы дублируем работу по определению каждой части?
Редактировать: Украденный из комментария Кёрю, поднятый на пост, потому что это действительно идеальное резюме того, что я говорил, и его можно было пропустить в комментариях. Это необходимо, поскольку не все, похоже, понимают, что добавление средств доступа к языку лишь кодифицирует неправильный шаблон проектирования ОО:
Короткая версия -
if (account1.balance > 1000)
{
account1.balance = account1.balance - 1000;
account2.balance = account2.balance + 1000;
}; = BAD CODE.
account2.deposit(account1.withdraw(1000)); = GOOD CODE.
Второй не требует доступа ... - kyoryu
(Немного изменен Биллом К, потому что у меня есть немного больше места, чем он сделал в своем комментарии).
Второй перемещает тест и некоторую другую математику в Аккаунт, а не дублирует его во всем коде, куда бы вы ни делали перевод.
Просто для того, чтобы обозначить точку ДАЖЕ БОЛЬШЕ, обратите внимание, что со стилем «ХОРОШИЙ КОД» вполне очевидно, что вывод .withdraw может быть объектом транзакции, который содержит информацию обо всей транзакции, включая ее успех, источник и назначение, а также ведение журнала. способность. Как бы это произошло с тем, кто пишет свой код в стиле «ПЛОХОЙ КОД»?
Кроме того, как бы вы реорганизовали BAD CODE, чтобы даже использовать такой объект? Это просто беспорядок.