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