Есть ли лучший способ справиться с именами причуд?

Question

В прошлом году и немного работы над кодовой базой моей команды я заметил устойчивое развитие соглашений об именах.

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

Вот те, которые я пятнистый:

MyClassUtil 
MyClassFactory 
MyClassHelper 
MyClassManager 
MyClassService 

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

Каков наилучший способ справиться с этой тенденцией? Это действительно проблема? Как эти приманки приходят в моду, следует ли использовать последнюю причуду? Следует ли переименовать все существующие элементы с новым соглашением об именах? Или нужно просто принять разнообразие как нечто неотвратимое?

Answer 1

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

MyClassUtil -Удобные утилиты для работы с MyClass, с которыми у него не было. Возможно, MyClass принадлежит к библиотеке, которую вы используете, но вы часто используете некоторые функции более высокого уровня, и вам нужно где-то их разместить.

MyClassFactory -Создает экземпляры MyClass абстрактным способом. Это позволяет вам писать код, который требует экземпляров MyClass. Он может получить эти новые экземпляры из MyClassFactory. Это позволило бы Фабрике изменить в будущем, чтобы обслуживать различные конкретные реализации MyClass.Может быть, при модульном тестировании, Factory просто подает фиктивные/mock MyClasses. Это означает, что класс, который использует фабрику, может быть протестирован без необходимости его изменения, просто измените заводскую настройку, а voilà вы можете изолировать тестируемый класс.

MyClassHelper -Ok, могу согласиться, возможно, это может быть более конкретным. Он что-то помогает в MyClass, но что. Может быть, это немного похоже на MyClassUtil. Но, вероятно, MyClassUtil - это общие функции, которые работают с MyClass, тогда как помощник инициализируется конкретным экземпляром MyClass, а затем может выполнять операции над этим одним экземпляром. Для каждого MyClass вам нужен новый помощник.

MyClassManager -Может ли это иметь дело с пулом экземпляров MyClass и хранить или организовывать их. Например. в CommunicationManager класс будет обрабатывать соединения вместе с классами, которые обрабатывают разговор с портом или соединением, например ethernet или serial, и класс, который обрабатывает передаваемый через него протокол comms, чтобы он мог передавать пакеты, и класс, который имеет дело с сообщений в этих пакетах.

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

Answer 2

Все имена классов, которые вы указали выше, указывают на поразительный отход от объектно-ориентированных принципов. Невозможно сказать, что делает «MyClassUtil» или «MyClassService». Это может быть что угодно. Именование классов должно быть конкретным и должно четко передавать фактическую функцию класса. Ничто из этого не делает. Лучший способ справиться с этой тенденцией - раскрыть навыки объектно-ориентированного программирования и соответственно назвать классы.

Теперь, возможно, эти примеры указывают на то, что в рамках архитектуры приложения эти классы представляют собой, и использование вами «MyClass» просто является заполнителем для чего-то более определенного во время выполнения, и в этом случае I не рассматривали бы их как именования причуд, а скорее как описательные индикаторы функции самого класса, с небольшим намеком на базовую архитектуру приложения.

Answer 3

Я не вижу, как завод или услуги подходят к конкретной причуде ...

Завод является шаблоном, и если класс действительно является завод, то это вполне подходящее название.

Если класс является службой Windows, что не так, позвонив в службу?

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

Answer 4

Если это всепроникающе, команде необходимо потратить некоторое время на изучение дизайна OO: чтение исходного кода на уважаемые структуры OO, книги по шаблонам проектирования или книги, такие как Evans «Domain Driven Design».

«Утилита» и «Менеджер» часто являются симптомами плохого дизайна - «код пахнет». Так что «Помощник» вне специальных контекстов (Rails-приложения), где он хорошо укоренился.

«Фабрика» и «Сервис» имеют точные технические значения, вы можете проверить код, чтобы убедиться, что он соответствует этим шаблонам проектирования.

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

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

Answer 5

Рекомендуется переименовывать имена в лучшие и рефакторинг кода, чтобы каждый класс имел ясный responsibility. Чтобы узнать, какие имена использовать, прочитайте статью Тима Оттингера о Meaningful Names.

Когда класс делает только одно, а дать ему описательное имя, как правило, легко. Такие слова, как «менеджер», являются неопределенными и могут указывать на то, что класс несет ответственность за выполнение множества несвязанных вещей, что простое имя не может описать, что делает класс. Если вы знаете, что делает класс, просто глядя на имя класса, класс имеет хорошее имя.

Answer 6

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

Если вы в.NET world Microsoft предоставляет инструмент под названием StyleCop

Answer 7

В примерах классов, которые вы указываете, стоит ли «MyClass» для фактического имени класса, так что вы действительно видите такие имена, как «PersonnelRecordUtil» или «GraphNodeFactory»? MyClassFactory - действительно плохое фактическое имя для класса.