Является ли слово «Помощник» в названии класса запахом кода?

Question

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

ADHelper, (Active Directory) AuthenicationHelper, SharePointHelper

У других людей есть большое количество классов с этим соглашением об именах?

Answer 1

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

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

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

Некоторое время назад я наткнулся на класс под названием XmlHelper во время проверки кода. У него было несколько методов, которые, очевидно, все имели отношение к Xml. Однако из имени типа неясно, что общего у методов (кроме того, что они связаны с Xml). Оказалось, что некоторые методы форматировали Xml, а другие разбирали Xml. Таким образом, ИМО класс должен был быть разделен на две или более частей с более конкретными именами.

Answer 2

Как всегда, это зависит от контекста.

Когда вы работаете с своим собственным API , я бы определенно счел это запахом кода, поскольку FooHelper указывает, что он работает на Foo, но поведение, скорее всего, относится непосредственно к Foo класс.

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

Answer 3

Зависит от фактического содержания занятий.

Если огромное количество реальных бизнес-логик / бизнес-правил в вспомогательных классах, то я бы сказал, да.

Если классы на самом деле являются просто помощниками, которые могут использоваться в других корпоративных приложениях (повторное использование в абсолютном смысле слова - не копировать, а настраивать), то я бы сказал, что помощники не являются запахом кода.

Answer 4

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

Application.Helper.SharePoint
Application.Helper.Authentication

и т. Д.

Answer 5

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

.NET Framework делает это также (например, в классе LogicalTreeHelper из WPF, в котором есть только несколько статических (не расширенных) методов).

Спросите себя, будет ли код лучше, если код в вашем вспомогательном классе будет реорганизован в «реальные» классы, то есть объекты, которые вписываются в вашу иерархию классов. Код имеет где-то , и если вы не можете разобрать класс / объект, к которому он действительно принадлежит, например, простые вспомогательные функции (отсюда и «Помощник»), у вас все будет в порядке.

Answer 6

Я бы не сказал, что это запах кода. В ASP.NET MVC это довольно распространено.