Когда дополнительных методов нужно избежать?
Прежде чем Вы начнете указывать на меня на дубликаты, просто знают, что я прочитал почти все сообщения на ТАК о дополнительных методах. Я просто пытаюсь играть защитника дьявола в течение минуты для рассмотрения альтернативы моему рабочему мнению.
Недавно я работал над проектом, и потребность предстала перед методом, чтобы быть основой интерфейса. Таким образом, я предложил, чтобы мы записали дополнительный метод, и он был подстрелен. Высказывание его добавило сложность и тяжелее отлаживать.
Я, конечно, спорил и преуспел ТАК для нахождения всех замечательных сообщений, которые показывают много причин, почему использовать дополнительные методы. Не забыть, что много платформы .NET использует их. Мы в конечном счете не использовали его, поскольку я был отвергнут командой.
Но затем это получило меня взгляды, есть ли времена, когда дополнительный метод мог использоваться, но не должен быть?
Я действительно не мог думать ни о ком, но думал, что буду отправлять здесь и видеть, мог ли кто-либо думать о каких-либо других причинах, почему они не должны использоваться.
5 ответов
Каждый раз, когда у вас есть функция, которая "в целом применима" к объекту определенного типа, независимо от его состояния, метод расширения является хорошим выбором.
Например, сегодня я добавил в нашу базу данных два новых метода расширения:
public static XElement ToXElement(this XmlElement element) { }
public static XmlElement ToXmlElement(this XElement element) { }
Оба они, вообще говоря, применимы к типам, которые они расширяют, независимо от состояния экземпляра или места, где мы его используем.
Если ваш метод не соответствует этому критерию, его, вероятно, следует переместить в вспомогательный метод, расположенный ближе к контексту, где конкретный случай всегда истинен или легко проверяется.
Например, недавно один из разработчиков предложил в качестве метода расширения следующее:
public static bool ParseYesNoBool(this string input) { }
Здесь есть две проблемы: во-первых, это появится на всех строках в приложении, хотя количество строк, которые могут быть кандидатами на этот случай, очень мало. Таким образом, мы нарушили первое правило, заключающееся в том, что это не полезно независимо от состояния. Аналогично, но во вторую очередь, потребитель этой функциональности ограничен единственным парсером для одного конкретного соединения с внешней системой. Поэтому продвижение специфичной для реализации функциональности в пространство имен общего пользования не имеет смысла. Это было понижено до вспомогательного метода в синтаксическом анализаторе.
Что касается читабельности и отладки, это просто неправильно для разработчика любого разумного уровня квалификации.
В этом обсуждении раздела «Гильделины дизайна фреймворка», посвященного методам расширения, содержится несколько полезных советов. Я думаю, что соответствующая часть вашего сценария:
Обеспечение вспомогательной функциональности, относящейся к каждой реализации интерфейса, если указанная функциональность может быть написана в терминах основного интерфейса.
Если предложенное вами использование не прошло этот тест, то его следовало уничтожить.
Как правило, если вы управляете исходным кодом для сборки и добавление метода не вызывает каких-либо критических изменений в существующем коде (что было бы, если бы, например, не был реализован LINQ через методы расширения) лучше просто добавить обычный метод.
Я бы сказал, что вам следует избегать их, когда «они не проясняют смысл кода». Конечно, то, является ли какой-то код (или стиль кодирования) «более ясным», сильно различается у разных людей, так что это в значительной степени бесполезно. (У меня был один начальник, который сказал, что мы должны избегать использования интерфейсов, потому что они сделали код «слишком сложным и трудным для понимания»)
Методы расширения позволяют «добавлять» методы к существующим типам без создания нового производного типа, перекомпиляции или иного изменения исходного типа.
Каждый раз, когда вы нарушаете замысел и дизайн функции, я бы рекомендовал пересмотреть использование метода расширения. Я вижу несколько ситуаций, когда вы не хотите использовать метод расширения:
1) Изменение объектной модели для разрешения метода расширения : класс, для которого вы хотите создать расширение, является абстрактный класс. Это потребует от вас либо сделать каждый унаследованный класс собственной версией расширения, либо удалить абстракцию из класса. В любом случае вы меняете объектную модель, чтобы использовать метод расширения.
2) Забыть шаблон декоратора : Количество методов расширения, которые вы создаете для класса, превышает три.Я считаю, что с декорированными объектами легче организовать / общаться и поддерживать модель домена / объекта, чем с расширенными объектами. Однако верно и обратное: если у декорированного объекта меньше четырех методов, я нахожу в своем проекте много почти «пустых» объектов.
3) Частные функции : Частные функции предназначены для изменения (создания, удаления и т. Д.) Объектов и методов расширения, которые должны использовать тип, как и структура. Если вы обнаружите, что расширение назначается другому экземпляру типа, то, вероятно, его не должно быть в расширении.