Статические классы со статическими методами считаются SOLID?

SOLID включает принцип подстановки Лискова, который имеет понятие, что «объекты в программе должны заменяться экземплярами их подтипов без изменения правильности этой программы».

Поскольку статические классы со статическими методами (немного похожими на Mathкласс) вообще не имеют экземпляров, считается ли моя система SOLID, если у меня есть статические классы со статическими методами?

language-agnostic solid static-access Pacerier
источник

Я думаю, что этот вопрос великолепен. Давайте посмотрим, что может предложить сообщество.

Саид Нимати

Математический класс не включает в себя состояние. Таким образом, вы никогда не передаете объекты этого типа вокруг. Поэтому я не уверен, насколько это актуально.

Мартин Йорк

Я не думаю, что статические классы действительно можно назвать чистыми SOLID (во многом по тем же причинам, что уже упоминались), однако я бы посчитал их отличным сторонником и инструментом для принципа DRY.

дреза

Как же так? По моему опыту, чрезмерное использование статических классов в основном приводит к тому, что люди все время повторяют себя с половиной кода, постоянно манипулирующего одним глобальным статическим божественным объектом.

back2dos

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

dreza

Ответы:

LSP применяется для передачи экземпляра класса в метод, когда метод выполняет некоторые действия с этим экземпляром и часто дает какой-то результат. Это не имеет значения для статических классов, так как в C # вы не можете создать экземпляр статического класса.

Что еще более важно, статические классы запечатаны и поэтому не могут быть унаследованы. Это делает ваш вопрос спорным, поскольку C # идет.

Можно сказать, что статические классы всегда совместимы с LSP, поскольку вы никогда не сможете создать подкласс, который нарушал бы этот принцип. Вы также можете сказать, что статические классы никогда не совместимы с LSP по той же причине.

В Java статические классы немного отличаются. Вы не можете пометить класс верхнего уровня как «статический», поэтому, если вы хотите создать служебный класс, похожий на статические классы C #, вы должны объявить его как finalи скрыть его конструктор. Однако, как только вы это сделаете, они будут вести себя так же, как в C # - вы не сможете их создать или создать подкласс. Вы можете объявить внутренний класс как static, но это не означает то же самое, что и в C #: он просто обозначает вложенный класс верхнего уровня .

Насколько я знаю, в этом случае VB.NET ведет себя точно так же, как и C #.

Вы не упомянули, заинтересованы ли вы в других принципах, но я все равно включу их для полноты.

S Ingle принцип ответственности : статический класс легко следовать этому принципу.
O перо / закрытый принцип : такстатические классы запечатаны, они никогда не могут следовать этому принципу.
L Иськов принцип замещения : как указано выше.
Я принцип nterface сегрегации : не относится к одному классу, но расщепление один большой статический класс на меньшие, более специализированные может быть шагомнаправлении соблюдения этого принципа.
D принцип ependency инверсия : статические классы не могут реализовывать интерфейсы, поэтому любой классиспользуя его всегда будет зависеть от любой реализации существует в данный момент. Поэтому статические классы нарушают этот принцип.

Поскольку статические классы не удовлетворяют всем 5 критериям, они не являются твердыми.

Адам Лир
источник

поскольку быть твердым означает, что мы должны удовлетворить все 5 критериев, не значит ли это, что они не являются твердыми?

Pacerier

@Pacerier Да, но не следует пытаться постоянно вводить класс в SOLID, если он не нужен; это зависит от контекста класса. Если это служебный класс или что-то в этом роде, то хорошо, что IMO не является "SOLID", но если это реальный класс домена, который имеет конкретное использование домена ...

Уэйн Молина

Я бы не классифицировал такой класс как объектно-ориентированный, и поэтому я бы сказал, что он не может (и не должен пытаться) соответствовать принципам объектно-ориентированного проектирования.

Эти классы - просто обходной путь к неспособности предоставить код вне класса в таких языках, как Java и C #. Если они могут быть, они должны быть определены как автономные функции, так как они не получают никаких преимуществ от объектной ориентации.

Гьян ака Гари Буйн
источник

Я был бы не согласен с тем, чтобы ставить отдельные функции вне класса. Простая возможность группировать связанные функции (статические или нет) под общим именем полезна для удобства чтения. Математические функции отлично отвечают всем требованиям.

Jojo

@jojo Согласен. Языки, которые поддерживают функции, определенные вне классов, также поддерживают логическую группировку этих функций, например, пространства имен в C ++.

Gyan aka Gary Buyn

Стоит отметить, что поскольку вы не указали язык, в C ++ вы можете передавать классы, в которых есть только статические члены, и получать к ним доступ через шаблон, и, следовательно, можно заменить класс только статическими членами и, возможно, методами. называется форма это "интерфейс".

DeadMG
источник

vb.net / c # / java

Pacerier