Единственный Принцип Ответственности: все открытые методы в классе должны использовать все зависимости от класса?
При заботе [приблизительно 114] о XSS тогда, необходимо использовать большую часть времени, таким образом, короткий тег не имеет большое значение.
, Даже если Вы сокращаетесь echo htmlspecialchars() к h(), это - все еще проблема, что необходимо не забыть добавлять его почти каждый раз, когда (и пытающийся отслеживать, каких данных предварительно оставляют, который не завершен-но-безопасен, только делает ошибки более вероятно).
я использую механизм шаблонной обработки , который безопасен по умолчанию и записи теги для меня.
6 ответов
Поддерживает ли SomeClass внутреннее состояние или просто «собирает» различные части функциональности? Можете ли вы переписать его таким образом:
internal class SomeClass
{
...
internal string SomeFunctionality(IDependency _someDependency)
{
...
}
internal string OtherFunctionality(IDependency2 _someDependency2)
{
...
}
}
В этом случае вы не можете нарушить SRP, если SomeFunctionality и OtherFunctionality каким-то образом (функционально) связаны, что не очевидно при использовании заполнителей.
И у вас есть добавленная стоимость возможности выбора зависимость использования от клиента, а не во время создания / DI. Возможно, некоторые тесты, определяющие варианты использования этих методов, помогут прояснить ситуацию: если вы можете написать содержательный тестовый пример, в котором оба метода вызываются для одного и того же объекта, тогда вы не нарушите SRP.
Что касается шаблона Facade, я я слишком много раз видел, как он сошел с ума, чтобы ему это понравилось, знаете, когда у вас будет более 50 классов методов ... Вопрос в следующем: Почему вам это нужно? Из соображений эффективности а-ля устаревший EJB?
Я обычно группирую методы в классы, если они используют разделяемую часть состояния, которая может быть инкапсулирована в класс. Наличие зависимостей, которые используются не всеми методами в классе, может быть запахом кода, но не очень сильным. Обычно я отделяю методы от классов только тогда, когда класс становится слишком большим, у класса слишком много зависимостей или у методов нет общего состояния.
Мой вопрос: должны ли все зависимости класса использоваться всеми его функциональными возможностями, т.е. если разные части функциональности используют разные зависимости, это значит, что они, вероятно, должны жить в отдельных классах?
Это намек, указывающий на то, что ваш класс может быть немного непоследовательным («делать больше, чем просто одно дело»), но, как вы говорите, если вы зайдете слишком далеко, вы получите новый класс для каждой части нового функциональность. Таким образом, вы захотите ввести объекты фасада, чтобы снова собрать их вместе (кажется, что объект фасада - полная противоположность этому конкретному правилу проектирования).
Вы должны найти хороший баланс, который работает для вас (и остальной части твоя команда).
Похоже на перегрузку. Вы пытаетесь что-то сделать, и есть два способа сделать это, так или иначе. На уровне SomeClass у меня была бы одна зависимость для выполнения работы, а затем этот единственный зависимый класс поддерживал бы два (или более) способа делать одно и то же, скорее всего, с взаимоисключающими входными параметрами. Другими словами, у меня был бы тот же код, что и для SomeClass, но вместо этого я определил бы его как SomeWork и не включил бы какой-либо другой несвязанный код.
HTH
Когда каждый метод экземпляра касается каждой переменной экземпляра, тогда класс становится максимально связным. Когда ни один метод экземпляра не разделяет переменную экземпляра с любым другим, класс минимально связан. Хотя это правда, что нам нравится высокая сплоченность, верно также и то, что действует правило 80-20. Получение этого последнего небольшого увеличения сплоченности может потребовать гигантских усилий.
В общем, если у вас есть методы, которые не используют некоторые переменные, это запах. Но небольшого запаха недостаточно для полного рефакторинга класса. Это то, о чем следует беспокоиться и за чем нужно следить, но я не рекомендую немедленных действий.
Фасад используется, когда вы хотите скрыть сложность (например, интерфейс к устаревшей системе) или хотите консолидировать функциональность, сохраняя при этом обратную совместимость с точки зрения интерфейса.
Ключевым моментом в вашем случае является то, почему у вас есть два разных метода в одном классе. Есть ли намерение создать класс, который объединяет похожие типы поведения, даже если он реализован через несвязанный код, например, при агрегировании. Или вы пытаетесь поддерживать такое же поведение, но имеете альтернативные реализации в зависимости от специфики, что может быть подсказкой для решения типа наследования / перегрузки.
Проблема будет в том, будет ли этот класс продолжать расти и в каком направление. Два метода не имеют значения, но если это повторяется более чем с 3, вам нужно будет решить, хотите ли вы объявить его как фасад / адаптер или вам нужно создать дочерние классы для вариантов.
Ваши подозрения верны, но запах - всего лишь струйка дыма от горящих тлеющих углей. Вам нужно следить за ним на случай, если он вспыхнет, а затем вам нужно будет принять решение, как вы хотите потушить огонь, прежде чем он выйдет из-под контроля.