Czy klasy statyczne są pożądane w projektach?

W WCF pisze klase walidującą z 4 metodami sprawdzającymi kompletność i spójność otrzymanych danych oraz czy spelniaja logike biznesową.

Pisze to jako klase statyczna ze statycznymi metodami i zastanawiam sie czy to dobre podejscie. Tworzy mi to silna zależność miedzy klasami i pewnie bedzie trudniej testowac metody wywolująca ta klase statyczną.

Chciałem Was zapytać czy czesto użwyacie static class ? w jakich przypadkach i czy chętnie ? oraz czy w moim przypadku to ma sens?

Dzieki za opowiedzi i sorry za banalność pytania, caly czas rozkminiam oop.

Kiedyś próbowałem się dostosować do "ogólnych norm" i nawet w aplikacjach WinForms chciałem wdrożyć dependecy injection żeby pozbyć się klas statycznych, ale z czasem stwierdziłem, że to kompletnie nie jest wartę zachodu. W zależności od projektu robię sobie statyczną klasę Methods gdzie trzymam metody, których potrzebuje w kilku miejscach. Do bazy danych tworzę sobie statyczną klasę Queries, w której trzymam stringi z zapytaniami do bazy danych. Nie przejmuje się testami i tym czy to dobre podejście jeśli działa.

PS.
Uważam, że w tych czasach więcej czasu spędza się na myśleniu o "dobrych praktykach" zamiast na pisaniu programów.

Poczytaj sobie o czasie życia klas statycznych i domenach aplikacji

Nie ma nic złego w klasach statycznych jako takich. Grunt to odpowiednie nazewnictwo i unikanie nadmiernego skomplikowania. Ja zazwyczaj trzymam się zasady że jeśli do metody nie musimy dostarczać dodatkowych zależności w celu wykonania jej logiki to jest ok. Jeśli natomiast taka metoda potrzebuje dodatkowych zależności, i w kodzie wywołującym wstrzykujemy (lub co gorsze tworzymy) tę zależność tylko po to aby przekazać ją do statycznej metody, to jest to jasny sygnał że nie powinna być to klasa statyczna a serwis (walidator czy jakakolwiek inna nazwa) wstrzykiwany do kodu klienckiego. Moim zdaniem- i mówię to na podstawie doświadczenia-- to jest najlepszym wyznacznikiem tego czy klasa powinna być statyczna czy też nie.

@WeiXiao

W zależności od projektu robię sobie statyczną klasę Methods gdzie trzymam metody, których potrzebuje w kilku miejscach. Do bazy danych tworzę sobie statyczną klasę Queries, w której trzymam stringi z zapytaniami do bazy danych.

To ma sens tylko w bardzo prostych aplikacjach. Nie wyobrażam sobie takiego podejścia w rozbudowanych aplikacjach. Nie mówiąc już o tym że nazewnictwo i tak pozostawia wiele do życzenia.

Dzieki Aventus, takie jasne wytłumaczenie trafia do mnie.

Starając sie to rozkminic, na stonie MIcrosoftu gdzie zalecaja oszczedne uzywanie i kilka blogow ze raczej odradzali dlago zasanawiałem sie jaka jest praktyka.

Dzieki

DO use static classes sparingly.

Static classes should be used only as supporting classes for the object-oriented core of the framework.

DO NOT treat static classes as a miscellaneous bucket.

DO NOT declare or override instance members in static classes.

DO declare static classes as sealed, abstract, and add a private instance constructor if your programming language does not have built-in support for static classes.

AdamWox napisał(a):

Nie przejmuje się testami i tym czy to dobre podejście jeśli działa.

Brawo. Z goto też korzystasz? To też działa.

Meini napisał(a):

Brawo. Z goto też korzystasz? To też działa.

Jeden doświadczony C-dev mówił mi, że używa do wychodzenia z zagnieżdżonych pętli.
Nawet w docu właśnie taki przykład przytoczono: https://docs.microsoft.com/pl-pl/cpp/c-language/goto-and-labeled-statements-c?view=vs-2019

Meini napisał(a):

Brawo. Z goto też korzystasz? To też działa.

Oczywiście, np. w state machinach.

lub aby uprościć kod

Trochę offtopowo:

AdamWox napisał(a):

Uważam, że w tych czasach więcej czasu spędza się na myśleniu o "dobrych praktykach" zamiast na pisaniu programów.

Pisanie oprogramowania w pełnej zgodzie z podstawowymi dobrymi praktykami zajmuje tyle samo czasu co pisanie tego "na pałę".

Ale oczywiście tylko na początku. W miarę tego jak projekt się rozrasta to graf zależności rośnie do niebotycznych rozmiarów a samego kodu w praktyce nie da się dobrze przetestować.
"Walnięcie zmiennej" w klasie czy dodanie statycznej zależności nie wygląda na groźne czy niepożądane "tu i teraz" ale w perspektywie rozwoju projektu może mieć ogromne konsekwencje jeśli taki tryb będzie ochoczo realizowany przez co najmniej część zespołu i przy cichej akceptacji reszty.

Takie "pisanie programów" miałem okazję widzieć nie raz w praktyce i kończyło się to nawet całkowitym przepisaniem aplikacji - na szczęście to akurat była część systemu w architekturze mikroserwisowej więc nie zajęło to dużo czasu.

Brutalna prawda jest taka, że przed napisaniem programu fajnie jest wiedzieć co ten program ma robić, znać założenia projektu i przemyśleć jego architekturę. Proces tworzenia oprogramowania składa się z dużo więcej elementów niż tylko samego pisania.

Oczywiście nie mam tu na myśli aplikacji robiącej backup katalogu tylko coś dużo bardziej poważnego co ma:

1. zarabiać na siebie
2. działać w sposób bezpieczny, niezawodny i przewidywalny
3. pozwalać na łatwe rozwijanie

Staram się używać metod statycznych tak często, jak to możliwe, a więc w przypadkach, gdy nie ma zewnętrznych zależności ani też żadnego statycznego stanu.

Ale nie jestem pewien, czy w przypadku walidatorów jest to dobrze podejście. Może dlatego, że nie wynajduję koła na nowo i do walidacji używam FluentValidation.

W skrócie - klas statycznych (poza rozszerzeniami innych klas) używa się głównie do metod "utilsowych", np:

static class StrUtils
{
    public string Foo(string s, int i)
   {
        return $"{i}{s}";
   }
}

Ale jeśli masz już jakąś zależność i zrobisz coś takiego:

static class StrUtils
{
    public string Foo(string s, int i)
   {
        string result = $"{i}{s}";
        SomeOtherClass c = new SomeOtherClass();
        return c.Bar(result);
   }
}

To już jest mocne powiązanie i nie powinieneś tak robić. Oczywiście to wszystko zależy od konkretnego problemu. Ja mówię całkiem ogólnie.
Ale tak, jak pisali Ci wyżej - jeśli klasa statyczna zależy od jakiejś innej klasy, to tu już jest lampka - czy ona faktycznie powinna być statyczna.