The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Менеджер. Контроллер. Помощник. Обработчик. Писатель. Читатель. Конвертер. Валидатор. Маршрутизатор. Диспетчер. Наблюдатель. Слушатель. Сортировщик. Кодировщик. Декодировщик. Это имена классов зала позора. Вы видели их в своем коде? В открытых исходных кодах библиотек, которые вы используете? В книгах по шаблонам? Все они неправильные. Что у них общего? Они все оканчиваются на “-er”. И что не так? Они не являются классами, и объекты, которые они создают, не являются объектами. Вместо этого они являются наборами процедур, притворяющихся классами.
Питер Коад говорил: Оспаривайте любые имена классов, которые оканчиваются на “-er”. Есть несколько хороших статей на эту тему, включая Your Coding Conventions Are Hurting You Карло Пешчо, One of the Best Bits of Programming Advice I Ever Got Трэвиса Григгса и Naming Objects – Don’t Use ER in Your Object Names Бена Холла. Основной аргумент против суффикса “-er” заключается в том, что “когда вам нужен менеджер, это часто означает, что управляемые объекты являются простыми структурами данных, а менеджер - это умная процедура, выполняющая реальную работу”.
Я полностью согласен, но хотел бы добавить несколько слов к этому.
Я уже упоминал в “Семи добродетелях хорошего объекта”, что хорошее имя объекта не является названием должности, но не объяснил, почему я так думаю. Кроме того, в “Утилитарные классы не имеют ничего общего с функциональным программированием” я пытался объяснить разницу между декларативным и императивным программированием. Теперь пришло время объединить эти две части.
Допустим, я - объект, и вы - мой клиент. Вы даете мне ведро яблок и просите отсортировать их по размеру. Если я живу в мире императивного программирования, вы получите их отсортированными сразу, и мы больше никогда не будем взаимодействовать. Я выполню свою работу, как вам было запрослено, даже не задумываясь о почему вам нужно их отсортировать. Я был бы сортировщиком, которому на самом деле не важно ваше реальное намерение:
Как вы видите здесь, истинное намерение заключается в том, чтобы найти самое большое яблоко в ведре.
Это не то, что вы ожидаете от хорошего делового партнера, который может помочь вам работать с ведром яблок.
Вместо этого, если бы я жил в мире декларативного программирования, я бы сказал вам: “Предположим, они отсортированы; что вы хотите сделать дальше?”. Вы, в свою очередь, скажете мне, что вам сейчас нужно самое большое яблоко. И я бы сказал: “Нет проблем; вот оно.” Чтобы вернуть самое большое, я бы не сортировал их все. Я бы просто прошел через каждое по очереди и выбрал самое большое. Эта операция гораздо быстрее, чем сначала сортировка, а затем выбор первого в списке.
Другими словами, я бы молча не следовал вашим инструкциям, но попытался делать свой бизнес по-своему. Я был бы гораздо более умным партнером для вас, чем этот императивный сортировщик. И я стал бы настоящим объектом, который ведет себя как отсортированный список яблок, а не как процедура, которая сортирует.
See the difference?
Уделите особое внимание разнице между именами sorter и sorted.
Вернемся к именам классов. Когда вы добавляете суффикс “-er” к имени вашего класса, вы немедленно превращаете его в глупого исполнителя ваших приказов. Вы не позволяете ему думать и импровизировать. Вы ожидаете, что он будет делать ровно то, что вы хотите — сортировать, управлять, контролировать, печатать, записывать, объединять, конкатенировать и так далее.
Объект - это живой организм, которому не хочется, чтобы ему указывали, что делать. Он хочет быть равным партнером для других объектов, проявляя свое поведение в соответствии с его контрактом(ами), также известными как интерфейсы в Java и C# или протоколы в Swift.
Философски говоря, суффикс “-er” является проявлением неуважения к бедному объекту.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 10:36
