Мы все согласны: хорошее имя всегда самое главное. Давай найдем их.
Мы используем имена для программирования, неважно, является ли язык высоким или низким, будь то императивный, функциональный или объектно-ориентированный. Имена везде. Но мы продолжаем ими злоупотреблять. Во второй части мы увидим, как изменить некоторые привычки.
Поиск продолжается
В предыдущей статье мы познакомили с различными определениями и методами поиска хороших имен. В этой заметке мы постараемся показать некоторые существующие проблемы номенклатуры, чтобы улучшить нашу практику.
Нам не нужна помощь
Помогают все объекты, «не поддерживающих» объектов нет.
В реальном мире помощников нет.
У нас есть единое дизайнерское правило. Если концепция не существует в реальном мире и мы не можем объяснить ее эксперту в предметной области, этот объект не должен существовать.
Правило 9: Помощников не существует
Нам не нужны начальники
Все объекты рождаются равными. Наши спроектированные объекты будут иметь социальное равенство. Нет менеджеров. Есть объекты с разными обязанностями.
В реальном мире менеджеров нет (если только мы не моделируем рабочие роли).
Правило 10: Менеджеров не бывает.
Нам не нужно говорить «объекты».
Объекты вездесущи. Присвоение имени классу «Object…» - это запах кода, подобный упомянутым выше.
Правило 11: Объектов не существует. Все они.
Вся ваша База принадлежит нам
Если мы не моделируем космическую или военную систему, мы не должны называть наши классы именем Base.
База означает отсутствие абстрактной концепции реального мира и вероятность того, что мы повторно используем код посредством наследования. Еще один запах кода.
Это нарушает принцип проектирования, согласно которому мы предпочитаем (динамическую) композицию объектов (статическому) наследованию классов.
Правило 12: Базовых объектов не существует.
Все эти имена очень плохие. Есть юмористические сайты, которые их генерируют автоматически.
Нам не нужны аксессуары
Как мы видели в предыдущих статьях, наличие сеттеров и геттеров приводит к нарушению инкапсуляции и неправильному распределению обязанностей. Нам следует с подозрением относиться ко всем функциям getXXX () или setXXX ().
Обычно мы не находим эти обязанности в сущностях предметной области в предвзятом отношении к реальному миру. В бизнес-моделях нет реальных обязанностей set () и get ().
В случае случайного совпадения ответственности с атрибутом мы вызовем функцию таким же образом без префикса get ().
Правило 13: не существует методов setXXX или getXXX.
Не спрашивай кто я
Функции, начинающиеся с isXXXX (), обычно являются реализационными.
Они запрашивают тип (избегая шаблона двойной отправки), генерируют связь и всегда сопровождаются if.
Как правило, мы должны ограничивать использование логических значений ситуациями, когда такие логические значения существуют в реальном мире.
Как следствие, думая о MAPPER, не доверяйте методам isXXX ().
Правило 14: Не существует методов isXXX ().
Если пахнет интерфейсом, значит, интерфейс
Такие имена, как итерируемый, сериализуемый и т. Д., Проповедуют обязанности объекта. Это будут отличные имена интерфейсов, поэтому мы не должны использовать их для именования классов.
Правило 15: Имена… в состоянии остаются для интерфейсов (поэтому они не могут быть созданы)
Утки на пруду
Утки всегда присутствуют в разработке программного обеспечения.
Есть техника отладки резиновой уточки. и это техника утиного набора
Когда я вижу птицу, которая ходит как утка, плавает как утка и звучит как утка, я называю эту птицу уткой.
Джеймс Уиткомб Райли
Этот метод предполагает, что мы знаем объекты по их обязанностям и их контекстной роли. Следствие гласит, что мы должны называть объекты в соответствии с этой ответственностью.
Правило 16. Используйте имена после наблюдения за поведением.
Шаблоны именования
Самая большая выгода от известных шаблонов проектирования - это унификация общего языка.
Все мы знаем, что такое декоратор, стратегия, адаптер или фасад. И мы знаем, что вы никогда не должны использовать Синглтоны:
Правило 17: Используйте имена шаблонов для реализации концепций.
Если он абстрактный, у него абстрактное имя.
Наш язык очень богат, и в нем много слов, которые моделируют концепции. Если мы хотим сгруппировать концепции, используя технику классификации Аристотеля, мы назовем классы этими именами.
Это классический пример наследования:
Общий суперкласс {Car, Boat, Airplane} не должен быть AbstractCar или BaseCar, ни BaseBoat, ни подвижный.
Это должно быть: Автомобиль.
Правило 18: должны быть обнаружены абстрактные имена. Не придумано.
Следствие 18: не используйте слово «абстрактный» как часть имени.
Ответственность - лучшее имя
Лучшее правило для наименования класса - найти его аналог в взаимно однозначном соответствии. Если это будет сложно, мы должны понять концепцию, исходя из их ответственности.
Давайте посмотрим на пример:
Если его можно обойти, его можно добавить или удалить, это не ArrayHelper, не ArrayManager, не BaseArray. , а тем более ArrayObject.
Например, при попытке сгруппировать: Array, Set, LinkedList, Multiset, Stack, Queue и т. д. мы можем получить слово, которое лучше всего их всех описывает.
Его основная обязанность - сбор предметов, поэтому у нас есть Сбор.
Мы узнаем это только после того, как узнаем многие из его подклассов, использующих принцип подстановки Лискова (L для Solid).
Правило 19: чтобы называть концепции, мы должны знать их протокол.
Мы говорим на одном языке
Поскольку я являюсь носителем испанского языка и преподаю в университете, студенты часто спрашивают нас, должны ли они давать имена на испанском (деловой язык) или на английском (базовый язык языков программирования).
Если мы хотим соответствовать полиморфизму функций, мы всегда должны использовать один и тот же язык.
Чтобы итератор foreach () был полиморфным со всеми повторяемыми объектами, он должен иметь свое имя на английском языке.
Если мы создадим объект с помощью функции recorrer () (переход на испанском языке), мы потеряем полиморфизм, и нам придется использовать правило if.
20: Код должен быть написан на английском языке.
Сводка правил
- Имена должны быть декларативными, а не реализующими.
- Имена должны быть контекстными.
- Не смешивайте типаж с ролью.
- Не используйте сеттеры или геттеры.
- Не используйте несуществующие термины, такие как Менеджер, Помощник, База.
- Не используйте слишком общие термины, такие как Object.
- Распределите обязанности перед тем, как назначать имена.
- Если сомневаетесь, ставьте дурные имена.
- Избегайте комментариев.
Частично цель этой серии статей - создать пространство для дебатов и дискуссий по дизайну программного обеспечения.
Ждем комментариев и предложений по этой статье.
Эта статья также доступна на испанском здесь.
Вы можете связаться со мной в твиттере.
