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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

Зависит от фактического содержимого классов.

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

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

Ответ 4

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

Application.Helper.SharePoint
Application.Helper.Authentication

и т.д.

Ответ 5

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

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

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

Ответ 6

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