ОК, осуществляет IComparable и другие интерфейсы (как IDisposable) на одном классе является нарушением SRP принципа.SOLID, SRP, IComparable
SRP утверждает, что каждый класс должен реализовать signle ResponsAbility и методы должны быть соединены между собой в высокой степени для достижения сплоченные классы.
Не является ли сравнение другой ответственностью?
Некоторое уточнение будет оценено.
Если бы я был вами, я бы попытался придерживаться SRP, но не так строго, как усилие, наконец, станет контрпродуктивным. Итак, теперь, когда вы сказали, что вам делать? Либо вы реализуете IComparable, либо имеете полное сравнение в объекте, либо имеете отдельный компаратор и реализуете в нем логику сравнения. Теперь для сравнения, что касается SRP, если сравнение является довольно простым и не должно меняться, я бы выполнил IComparable и покончил с этим. Если вы можете разумно предвидеть некоторые изменения в будущем, или если сравнение использует регистр-зависимое, то я бы пошел по пути компаратора. Конечной целью является разработка закрытых компонентов и их взаимодействие, составление их, поэтому, если сравнение имеет мало шансов на изменение, компонент может быть закрыт, и вы не услышите об этом снова. Вы также можете прокомментировать использование IComparable в своем коде, и если некоторые изменения произойдут в будущем, переключитесь на составление с компаратором, так как изменение, которое, как говорили, не произошло, действительно произошло.
Спасибо, поэтому придерживаться этих принципов не должно быть настолько строгим. Это зависит от ситуации . как насчет сравнения для сущностей? –
SOLID - это инструмент, а не средство для достижения цели. Кроме того, у вас часто будет выбор между строгостью и снисходительностью. Вы не можете предвидеть все изменения, и вы должны также держать его простым. По моему скромному мнению, строгая SRP заставила бы вас переоценить вещи. Что касается сущностей, если по объектам вы имеете в виду постоянные объекты, то, что я написал ранее, все еще выполняется. Это зависит от сходства изменений и зависимости от некоторого варианта использования - и у вас будут разные варианты использования с разными сравнениями для одного и того же объекта в будущем. –
Я бы сказал, что нарушения Imomparable и IDisposable являются не обязанностей вообще, и поэтому не будут нарушать SRP.
В контексте SRP ответственность заключается в взаимодействии вашей системы (то есть с пользователем, ролью или внешней системой). Если ваша система имеет документ бизнес-требований, все обязанности должны быть как минимум выведены в рамках функциональных или нефункциональных требований. Если нет, спросите себя, какой владелец бизнеса попросит вас изменить способ размещения объекта.
В первом проекте, над которым я работал после изучения SRC, мы интерпретировали его как «один общедоступный метод для каждого класса» и применили его как жесткое правило. В то время как это облегчило пребывание в «соблюдении», мы оказались с кодом, который был намного сложнее, чем нужно.
Если IComparable/IDisposable реализации необходимо изменить, что изменение будет зависеть от функциональной (деловой) части вашего класса также требующих изменения (в то же время и по той же причине ).
Как насчет провайдера? И SRP, и ISP являются частью SOLID, поэтому не должны конфликтовать. –