Чи вважаються статичні класи зі статичними методами SOLID?

SOLID включає принцип заміщення Ліскова, який має поняття, що "об'єкти в програмі повинні бути замінені екземплярами їх підтипів, не змінюючи правильність цієї програми".

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

language-agnostic solid static-access

— Пейсьєр
джерело

Я думаю, це питання чудове. Подивимося, що може запропонувати громада.

— Saeed Neamati

Клас Math не включає стан. Отже, ви ніколи насправді не передаєте об'єкти такого типу. Тож я не впевнений, наскільки це навіть актуально.

— Мартін Йорк

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

— дреза

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

— back2dos

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

— dreza

Відповіді:

LSP застосовується для передачі екземпляра класу в метод, який має метод робити якісь речі з цим екземпляром і часто дають певний результат. Це не має значення для статичних класів, оскільки в C # ви не можете створити екземпляр статичного класу.

Ще важливіше, що статичні класи є герметичними і тому не можуть бути успадковані. Це робить ваше питання суперечливим, наскільки йде C #.

Можна сказати, що статичні класи завжди сумісні з LSP, оскільки ви ніколи не можете створити підклас, який би порушував цей принцип. Ви також можете сказати, що статичні класи ніколи не відповідають стандартам LSP з тієї ж причини.

У Java статичні класи дещо відрізняються. Ви не можете позначати клас вищого рівня як "статичний", тому, якщо ви хочете створити клас утиліти, подібний до статичних класів C #, ви повинні оголосити його як finalта приховати його конструктор. Коли ви це зробите, вони поводяться аналогічно C # - ви не можете їх створити ініціювати або підкласифікувати. Ви можете оголосити внутрішній клас як static, але це не означає те саме, що в C #: він просто позначає вкладений клас верхнього рівня .

Наскільки я знаю, VB.NET поводиться точно так само, як і C #.

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

S Ingle принцип відповідальності : статичний клас легко дотримуватися цього принципу.
O перо / закритий принцип : такстатичні класи запечатані, вони ніколи не можуть дотримуватися цього принципу.
L Іськів принцип заміщення : як зазначено вище.
Я принципу сегрегації інтерфейсів : не застосовується до одного класу, але розділення одного великого статичного класу на менші, більш спеціалізовані може стати кроком до дотримання цього принципу.
D принцип ependency інверсія : статичні класи не можуть реалізовувати інтерфейси, тому будь-який класвикористовуючи його завжди буде залежати від будь-якої реалізації існує в даний момент. Тому статичні класи порушують цей принцип.

Оскільки статичні класи не відповідають усім 5 критеріям, вони не є СОЛІДНІМ.

— Адам Лір
джерело

оскільки бути ТОЛИЧНИМ означає, що ми повинні задовольнити всі 5 критеріїв, чи це не означає, що вони не є СОЛІДНІМ?

— Pacerier

@Pacerier Так, але не варто намагатися весь час вбирати клас у SOLID, якщо він не потрібен; це залежить від контексту класу. Якщо це корисний клас або щось подібне, IMO добре не бути "SOLID", але якщо це фактичний клас домену, який має специфічне використання домену ...

— Wayne Molina

Я б не класифікував такий клас як об'єктно-орієнтований, і тому я б сказав, що він не може (і не повинен намагатися) відповідати принципам об'єктно-орієнтованого дизайну.

Ці класи є лише вирішенням неможливості надати код поза класом на таких мовах, як Java та C #. Якщо вони можуть бути, їх слід визначити як окремі функції, оскільки вони не отримують ніякої вигоди від орієнтації на об'єкт.

— Gyan aka Gary Buyn
джерело

Я б не погоджувався з виведенням самостійних функцій поза класом. Проста здатність групувати пов'язані функції (статичні чи ні) під загальною назвою корисна для читабельності. Математичні функції ідеально підходять до рахунку.

— jojo

@jojo погодився. Мови, які підтримують функції, визначені поза класами, також підтримують логічне групування цих функцій, наприклад, простори імен у C ++.

— Gyan aka Gary Buyn

Варто згадати, оскільки ви не вказали жодної мови, що в C ++ ви можете передавати класи, навколо яких є лише статичні члени та отримувати доступ до цих членів за допомогою шаблону, і тому можна замінити клас лише статичними членами, і, можливо, методами називається формою, це "інтерфейс".

— DeadMG
джерело

vb.net / c # / java

— Pacerier