это нарушает твердые принципы?

Question

У меня есть что-то подобное в моем проекте, проект, он вроде уже закончен (работает) я просто хочу знать, все ли в порядке с принципами SOLID

static public class Tools
{
    static public GetProduct(this id){...}

    static public GetProductCategory(this id){...}

    static public GetUser(this id){...}

    // I also have here methods like IsStringNull ...
    // IsNull IsFalse, lots of stuff, everything static
}

и использование так

var UserThatCreatedCategoryForThisProduct = 
      prodId.GetProduct().CategoryId.GetProductCategory().Creator.GetUser();

я знаю, что очевидно, что он нарушает SRP, но этот класс является статическим, и он содержит статические методы, которые не зависят друг от друга, и он не похож на тот, если бы я создал статический класс для каждого метода

Answer 1

Насколько я понимаю, здесь есть много ТВЕРДЫХ нарушений!

• Нарушения принципа единой ответственности - во-первых, у вас есть методы доступа к данным для нескольких классов, во-вторых, у вас есть вспомогательные методы (IsStringNull, IsNull и т. Д.), Сплетенные с ними.
• Нарушения принципа сегрегации интерфейса (как упомянуто Рубеном). Если меня интересуют только продукты, зачем мне использовать методы, которые привлекают пользователей?

Я уверен, что есть и другие, но это явные.

ОБНОВЛЕНИЕ Теперь, когда кто-то прокомментировал это, я думаю, что они правы; приведенный выше код выглядит как некая форма злоупотребления методом расширения .

Например, я не верю, что доступ к данным должен быть отнесен к методам расширения или, что еще хуже, к классу с именем «Инструменты».

Вероятно, было бы более разумно иметь базовый класс (в совершенно другом пространстве имен и / или сборке), который абстрагирует ваши общности доступа к данным, а затем наследовать один класс доступа к данным для каждого уникального объекта домена (например, UserDAO, ProductDAO , так далее). Поймите, что я предполагаю, что под GetProduct или GetUser вы на самом деле имеете в виду GetFromDatabase.

Остальные вспомогательные методы принадлежат расширениям, поэтому они в порядке.

Answer 2

Судя по вашим примерам, определенно есть нарушение ISP и SRP и, возможно, нарушение закона Деметры (не ТВЕРДЫЕ, но ...).

IMNSHO Вам гораздо лучше читать статьи о SOLID (или покупать Agile Принципы, Шаблоны и Практики в C # Роберта Мартина и Мики Мартина , которые превосходны во всем и являются одними из самых полезных книги, которые я читал в последние годы), чем просить частичный совет по поводу паутины для такого типа вещей.

Если вам нужен ярлык (хотя вы и не хотите - книги и PDF-файлы содержат примеры, которые очень хорошо объясняют!), Эти подкасты Hanselminutes с дядей Бобом очень хороши:

• Hanselminutes Podcast 145 - Твердые принципы с дядей Бобом - Роберт К. Мартин
• Hanselminutes Podcast 171 - Возвращение дяди Боба

редактировать: получил SRP от Джон Limjap и ppiotrowicz

Answer 3

Это нарушает принципы SOLID во многих отношениях.

• это не принцип единой ответственности, потому что я не делаю как минимум 3 разные вещи (возврат продуктов, возвращение клиентов, строковые операции?)
• нарушает принцип открытого закрытого доступа, поскольку не открыт для расширения