Мы, кажется, абстрагируем много логического пути с веб-страниц и создаем "вспомогательные" классы. К сожалению, эти классы звучат одинаково, например
ADHelper, (Active Directory) AuthenicationHelper, SharePointHelper
У других людей есть большое количество классов с этим соглашением об именах?
Я бы сказал, что он квалифицируется как запах кода, но помните, что запах кода не обязательно вызывает проблемы. Это то, что вы должны изучить, а затем решить, все ли в порядке.
Сказав, что я лично считаю, что такое имя добавляет очень мало значения, и поскольку оно является таким общим, тип может легко стать ведром ненужных методов полезности. То есть класс помощника может превратиться в большой класс, который является одним из общих запахов кода.
Если возможно, я предлагаю найти имя типа, которое более точно описывает, что делают методы. Конечно, это может вызвать дополнительные вспомогательные классы, но пока их имена полезны, я не против номеров.
Некоторое время назад я встретил класс под названием XmlHelper во время проверки кода. У него было несколько методов, которые, очевидно, все имели отношение к Xml. Однако из названия типа было непонятно, какие методы имели общие (помимо связанных с Xml). Оказалось, что некоторые из методов были форматирование Xml, а другие - синтаксический анализ Xml. Таким образом, ИМО класс должен был быть разделен на две или более части с более конкретными именами.
Как всегда, это зависит от контекста.
Когда вы работаете с собственным API, я определенно считаю его запахом кода, потому что FooHelper указывает, что он работает на Foo, но поведение, скорее всего, будет принадлежать непосредственно на Foo.
Однако, когда вы работаете с существующими API (такими как типы в BCL), вы не можете изменить реализацию, поэтому методы расширения станут одним из способов для устранения недостатков в исходном API. Вы можете выбрать имена таких классов FooHelper так же, как и FooExtension. Он также вонючий (или нет).
Зависит от фактического содержимого классов.
Если в вспомогательных классах содержится огромное количество фактических бизнес-логик/бизнес-правил, я бы сказал "да".
Если классы действительно просто помощники, которые могут использоваться в других корпоративных приложениях (повторное использование в абсолютном смысле этого слова - не копирование, а затем настройка), то я бы сказал, что помощники не являются запахами кода.
Это интересный момент, если слово становится "шаблоном" в именах, тогда его, вероятно, немного хлыст - если не совсем настоящий запах. Возможно, используя папку "Помощник", а затем разрешая ей появляться в пространстве имен, сохраняет свое использование, не злоупотребляя словом?
Application.Helper.SharePoint
Application.Helper.Authentication
и т.д.
Во многих случаях я использую классы, заканчивающиеся на Helper для статических классов, содержащих методы расширения. Мне кажется неловким. Вы не можете поместить их в нестатический класс, и сам класс не имеет значения, поэтому помощник в порядке, я думаю. Пользователи такого класса все равно не будут видеть имя класса.
.NET Framework делает это также (например, в классе LogicalTreeHelper из WPF, который имеет несколько статических (не расширение) методов).
Спросите себя, будет ли код лучше, если код в вашем вспомогательном классе будет реорганизован на "реальные" классы, то есть объекты, которые вписываются в вашу иерархию классов. Код должен быть где-то, и если вы не можете определить класс/объект, к которому он действительно принадлежит, например, простые вспомогательные функции (следовательно, "Помощник" ), вы должны быть в порядке.
Я бы не сказал, что это запах кода. В ASP.NET MVC это довольно часто.