Nie używaj „statycznego” w C #?

Złożyłem aplikację, którą napisałem do innych architektów w celu przejrzenia kodu. Jeden z nich niemal natychmiast odpisał mi i powiedział: „Nie używaj„ statycznego ”. Nie możesz pisać automatycznych testów za pomocą klas i metod statycznych. Należy unikać„ statycznego ”.

Sprawdziłem iw pełni 1/4 moich zajęć jest oznaczonych jako „statyczne”. Używam static, gdy nie zamierzam tworzyć instancji klasy, ponieważ klasa jest pojedynczą klasą globalną używaną w całym kodzie.

Później wspomniał o kpinie, technikach IOC / DI, których nie można używać ze statycznym kodem. Mówi, że niefortunnie jest, gdy biblioteki stron trzecich są statyczne z powodu ich braku możliwości testowania.

Czy ten drugi architekt ma rację?

aktualizacja: oto przykład:

APIManager - ta klasa przechowuje słowniki interfejsów API innych firm, do których dzwonię, wraz z następnym dozwolonym czasem. Egzekwuje limity użytkowania interfejsu API, które wiele podmiotów zewnętrznych ma w swoich warunkach świadczenia usług. Używam go wszędzie, gdzie dzwonię do usługi innej firmy, dzwoniąc do Thread.Sleep (APIManager.GetWait („ProviderXYZ”)); przed wykonaniem połączenia. Wszystko tutaj jest wątkowo bezpieczne i działa świetnie z TPL w C #.

Zależy to od tego, czy klasy statyczne utrzymują stan, czy nie. Osobiście nie mam problemu z funkcjami bezstanowymi zrzuconymi razem w klasie statycznej.

Jest w tym zbyt ogólny. Ma rację, utrudnia to testowanie. Jednak staticklasy i metody mają swoje miejsce i tak naprawdę zależy od kontekstu. Bez przykładów kodu nie można tak naprawdę powiedzieć.

Używam statycznego, gdy nie zamierzam tworzyć instancji klasy, ponieważ klasa jest pojedynczą klasą globalną używaną w całym kodzie.

Może to być silny zapach kodu. Do czego używasz klas? Do przechowywania danych? Aby uzyskać dostęp do bazy danych? Więc on ma rację. W takim przypadku powinieneś zajrzeć do wstrzykiwania zależności, ponieważ taka klasa statyczna jest w rzeczywistości niejawnym singletonem.

Jeśli używasz ich do metod rozszerzenia lub pomocników, które nie zmieniają stanu i działają tylko na podanych przez Ciebie parametrach, zwykle są one w porządku.

Sprawdziłem iw pełni 1/4 moich zajęć jest oznaczonych jako „statyczne”. Używam statycznego, gdy nie zamierzam tworzyć instancji klasy, ponieważ klasa jest pojedynczą klasą globalną używaną w całym kodzie.

Najlepiej jest przetestować kod jednostkowo. Spróbuj zaprojektować testy, które są powtarzalne, niezależne, proste i przetestuj tylko jedną metodę na raz. Spróbuj uruchomić testy w innej losowej kolejności. Czy możesz uzyskać stabilną „zieloną” wersję?

Jeśli tak, to ważny punkt do obrony twojego kodu. Jeśli jednak masz trudności, być może powinieneś wybrać metody oparte na instancjach.

Odpowiedzi już opublikowane obejmują wiele naprawdę dobrych punktów, ale wydaje się, że brakuje jednego:

Pola statyczne nigdy nie są usuwane.

Jest to bardzo ważne, jeśli masz aplikację z wieloma ograniczeniami pamięci, a ten wzór może być bardzo częsty, gdy ludzie próbują zaimplementować pamięć podręczną.

Funkcje statyczne nie są już tak złe, ale wszyscy inni opisali to już wystarczająco szczegółowo.

Jedną z zalet, które można uzyskać z IoC / DI, jest to, że większość interakcji między klasami jest negocjowana między interfejsami. Ułatwia to testowanie jednostek, ponieważ interfejsy można wyśmiewać automatycznie lub półautomatycznie, a zatem każdą z części można przetestować pod kątem wejść i wyjść. Co więcej, poza testabilty, umieszczenie interfejsów między wszystkim pozwala uzyskać najbardziej modułowy kod - możesz łatwo zastąpić jedną implementację bez większego obawy, że spieprzysz zależności.

Ponieważ C # nie ma metaklasy, klasa nie może zaimplementować interfejsu przy użyciu funkcji statycznych, więc statyczne cechy klas kończą wszelkie próby implementacji czystego modelu obiektowego IoC / DI. Innymi słowy, nie możesz stworzyć makiety, aby je przetestować i musisz stworzyć prawdziwe zależności.

Jeśli twoja firma / projekt jest mocno zainwestowany w robienie IoC, jest to oczywiście uzasadniony problem, a ból, przez który przechodzisz, jest dla korzyści wszystkich. Jednak z architektonicznego punktu widzenia osobiście nie sądzę, aby jakikolwiek model poszedł do grobu. Jest kilka rzeczy, które mają sens za pomocą metod statycznych - na przykład strategia projektowania singletonów. Sam jestem mniej skłonny do klas statycznych, ponieważ myślę, że zaczynają tracić zalety OO, ale są chwile, kiedy klasa biblioteczna jest prawdopodobnie bardziej naturalnym wyrażeniem czegoś niż silnika.

Komentator przypomina mi metody rozszerzeń, które oczywiście muszą znajdować się w klasach statycznych w języku C #. Jest to uzasadnione i jest przykładem tego, jak czysty IoC nie działa zbyt dobrze w języku C #, przynajmniej jeśli próbujesz skorzystać z szerokiej gamy języka.

Klasy statyczne są czasami niewłaściwie wykorzystywane i powinny być:

• singleton (gdzie klasa niestatyczna ma element statyczny i publiczną zmienną statyczną Instancji, aby pobrać / utworzyć ją tylko raz.
• metoda z innej klasy (w której liczy się stan). Jeśli masz członka, który nie korzysta z danych z tej klasy, prawdopodobnie nie powinien on należeć do tej klasy.

Może to być również tak zwana funkcja „użyteczności” i część klasy użyteczności. Klasy narzędzi to klasy, które zawierają tylko metody statyczne i służą jako funkcje pomocnicze bez żadnego kontekstu.

Metody statyczne są odpowiednie w użyciu i mają należne miejsce w programowaniu. Wygląda na to, że Twój architekt ma środowisko testowe, które nie w pełni obsługuje metody statyczne. Jeśli Twój kod jest częścią większego projektu, ważne jest, aby spełnić wytyczne architektów. Nie pozwól jednak, aby ten projekt zniechęcił cię do używania metod statycznych, gdy jest to właściwe.

Używam właściwości statycznych do rzeczy, które są wspólne dla wszystkich instancji klasy. I używam metod statycznych, aby uzyskać grupy obiektów klasy. Nie jestem bynajmniej ekspertem, ale do tej pory działało na mnie.

Przykład PHP:

class vendorData {
  private static $data_table = 'vendor_data'; // static property
  private $id; // instance property
  private $name; // instance property

  public function __construct($vendor_id) {
    if(!self::validId($vendor_id) ) { // static method
      return false; // id doesn't exist
    }
    $this->id = $vendor_id; // id has been validated
    $this->getProperties(); // object method
  }

  private static function validId($vendor_id) {
    // send db query to find if the id exists
    // return true/false;
  }

  private function getProperties() { // object method
    $sql = "SELECT * FROM `{self::$data_table}` // using static property
        WHERE `id` = {$this->id}"; // using object instance property
    // get resultset
    foreach($result as $property => $value) {
      $this->$property = $value; // object instance properties all set
    }
  }

  // and here
  public static function getBy($property,$value) { // static method to return object array
    $sql = "SELECT `id` FROM `{self::$data_table}` // using static property
      WHERE `$property` = '$value'";
    // send query, get $ids array
    $obj_array = array();
    foreach($ids as $id) {
      // create array of current class objects using special static keyword
      // meaning of static here is different than in property/method declarations
      $obj_array[$id] = new static($id);
    }
    return $obj_array;
  }
}

Powiem, że ich zasady są w porządku, ale stwierdzenie (nie używaj statyki) może być błędne. Ile kosztuje Twój kod? jeśli liczba jest wysoka i czujesz się komfortowo z testowaniem jednostkowym swojej aplikacji, to nic ci nie jest. Jeśli nie, proponuję przejrzeć kod. Może się zdarzyć, że przyczyną są klasy statyczne lub nie, będzie to zależeć od wielu rzeczy.

Zajęcia metodami statycznymi naruszają zasady OOP. To już nie jest OOP, to programowanie zorientowane na klasę COP.

Rzadko mają wyraźną „osobowość” (używam tutaj mojej ulubionej ludzkiej metafory ) lub tożsamość. Więc nie wiedzą, kim są. Sam ten punkt wystarczy, aby pozbyć się tej koncepcji w OOP, ale jest ich więcej.

Następny jest konsekwencją pierwszego punktu. Ponieważ takie klasy nie wiedzą, kim są, zwykle są duże lub duże.

Po trzecie, twój kod jest absolutnie nie do utrzymania. Zastosowanie metod statycznych wprowadza ukryte zależności . Pojawiają się wszędzie i nigdy nie wiesz, co dzieje się w twojej klasie. Nie możesz być tego pewien, patrząc tylko na podpis konstruktora.

Powoli, ale nieuchronnie, twój kod staje się coraz mniej spójny, ponieważ ukryte zależności są słabo kontrolowane. Wydają się niewidoczne. I tak łatwo jest dodać kolejny! Nie musisz modyfikować podpisu żadnej metody. Wszystko, co musisz zrobić, to wywołać metodę statyczną. A co za brzydki kod wynika ...

Ok, pewnie już zgadłeś. Szczelne połączenie często towarzyszy niskiej kohezji. Jeśli jest wielu klientów korzystających z jakiejś klasy, łączenie staje się coraz ściślejsze. I jest duża uwodzenie w użyciu już napisanej klasy lub metody, która wymaga tylko drobnej poprawki. Tylko jeden parametr-parametr metody.

Czego używać zamiast metod statycznych? Cóż, moja propozycja to OOP. Dlaczego nie spróbować?