Czy klasy statyczne z metodami statycznymi są uważane za SOLIDNE?

SOLID obejmuje zasadę podstawienia Liskowa, która zakłada, że „obiekty w programie powinny być zastępowalne instancjami ich podtypów bez zmiany poprawności tego programu”.

Ponieważ klasy statyczne z metodami statycznymi (trochę jak Mathklasa) w ogóle nie mają instancji, czy mój system jest SOLIDNY, jeśli mam klasy statyczne z metodami statycznymi?

language-agnostic solid static-access

— Pacerier
źródło

Myślę, że to pytanie jest świetne. Zobaczmy, co społeczność ma do zaoferowania.

— Saeed Neamati,

Klasa Math nie obejmuje stanu. Więc tak naprawdę nigdy nie przekazujesz obiektów tego typu. Nie jestem więc pewien, jak to w ogóle jest istotne.

— Martin York,

Nie sądzę, by można było powiedzieć, że klasy statyczne są czystymi SOLIDNYMI (wiele z tych samych powodów, o których już wspomniano), ale uważam je za wielkiego zwolennika i narzędzie do zasady DRY.

— dreza

Jak to? Z mojego doświadczenia wynika, że nadużywanie klas statycznych powoduje, że ludzie cały czas się powtarzają, a połowa kodu stale manipuluje jednym globalnym statycznym obiektem boga.

— back2dos,

Myślę, że myślę więcej w kategoriach klas użyteczności, aby zapewnić wspólny kod. Zgadzam się, że łatwo i często są niewłaściwie używane, ale nadal uważam, że mogą zapewnić użyteczne środki do grupowania wspólnego kodu, w którym stan nie jest problemem

— dreza

Odpowiedzi:

LSP ma zastosowanie do przekazywania instancji klasy do metody, dzięki czemu metoda wykonuje pewne czynności z tą instancją i często daje pewien wynik. Nie ma to znaczenia dla klas statycznych, ponieważ w języku C # nie można utworzyć instancji klasy statycznej.

Co ważniejsze, klasy statyczne są zapieczętowane i dlatego nie można ich dziedziczyć. To sprawia, że twoje pytanie jest dyskusyjne w miarę C #.

Można powiedzieć, że klasy statyczne są zawsze zgodne z LSP, ponieważ nigdy nie można stworzyć podklasy, która naruszałaby tę zasadę. Można również powiedzieć, że klasy statyczne nigdy nie są zgodne z LSP z tego samego powodu.

W Javie klasy statyczne są nieco inne. Nie możesz oznaczyć klasy najwyższego poziomu jako „statycznej”, więc jeśli chcesz utworzyć klasę użyteczności podobną do klas statycznych C #, musisz zadeklarować ją jako finali ukryć jej konstruktor. Gdy to zrobisz, zachowują się one podobnie do C # - nie możesz ich utworzyć ani podklasować. Możesz zadeklarować klasę wewnętrzną jako static, ale to nie znaczy tego samego, co w C #: po prostu oznacza zagnieżdżoną klasę najwyższego poziomu .

W tym przypadku VB.NET zachowuje się dokładnie tak samo jak C #, o ile wiem.

Nie wspomniałeś, czy interesują Cię inne zasady, ale i tak je uwzględnię, aby uzyskać kompletność.

S Ingle zasada odpowiedzialności : klasa statyczna łatwo śledzić tę zasadę.
O długopis / zasada zamknięta : ponieważ klasy statyczne są zapieczętowane, nigdy nie mogą przestrzegać tej zasady. Zasada podstawienia
L iskova : jak wyżej.
I zasada nterface segregacja : nie stosuje się do jednej klasy, ale dzielenie jedna duża klasa statyczna na mniejsze, bardziej wyspecjalizowane te mogłyby być krokiem w kierunku przestrzega tej zasady.
D Zasada inwersji zależności : klasy statyczne nie mogą implementować interfejsów, więc każda klasa, która go używa, zawsze będzie zależeć od tego, co istnieje w danym momencie. Klasy statyczne naruszają zatem tę zasadę.

Ponieważ klasy statyczne nie spełniają wszystkich 5 kryteriów, nie są SOLIDNE.

— Adam Lear
źródło

ponieważ bycie SOLIDNYM oznacza, że musimy spełniać wszystkie 5 kryteriów, czy to nie znaczy, że nie są SOLIDNE?

— Pacerier

@Pacerier Tak, ale nie należy próbować cały czas zmieniać klasy w SOLID, jeśli nie jest to potrzebne; zależy to od kontekstu klasy. Jeśli jest to klasa użyteczności, czy coś takiego, IMO może nie być „SOLIDNY”, ale jeśli jest to rzeczywista klasa domeny, która ma określone użycie domeny ...

— Wayne Molina

Nie sklasyfikowałbym takiej klasy jako obiektowej i dlatego powiedziałbym, że nie może ona (i nie powinna próbować) spełniać zasad projektowania obiektowego.

Klasy te są jedynie obejściem niemożności zapewnienia kodu poza klasą w językach takich jak Java i C #. Jeśli tak, należy je zdefiniować jako samodzielne funkcje, ponieważ nie odnoszą one żadnych korzyści z orientacji obiektowej.

— Gyan alias Gary Buyn
źródło

Nie zgadzałbym się z umieszczaniem samodzielnych funkcji poza klasą. Prosta możliwość grupowania powiązanych funkcji (statycznych lub nie) pod wspólną nazwą jest użyteczna dla czytelności. Funkcje matematyczne idealnie pasują do rachunku.

— jojo

@jojo uzgodnione. Języki obsługujące funkcje zdefiniowane poza klasami obsługują również logiczne grupowanie tych funkcji, np. Przestrzenie nazw w C ++.

— Gyan alias Gary Buyn

Warto wspomnieć, ponieważ podano żadnego języka, który w C ++ Państwo może przekazać zajęcia wokół którego mają członków tylko statyczne i dostęp do tych członków przez matrycę, a więc możliwe jest, aby zastąpić klasy z członków tylko statycznych i zapewne metody zwana forma to „interfejs”.

— DeadMG
źródło

vb.net / c # / java

— Pacerier