Jak wybrać pomiędzy metodami statycznymi i niestatycznymi?

Zaczynamy.

Po pierwsze:

Więc często używam metod statycznych (być niezależnym od konkretnej instancji-niezależność jest zawsze dobra).

Wręcz przeciwnie: używając metod statycznych jesteś bardzo zależny od konkretnej instancji.

Nie można używać metod statycznych do implementacji interfejsu i nie można nadpisywać metod statycznych. Więc używanie metod statycznych oznacza, że po prostu nie robisz OOP.

Zastanów się, jak zaimplementowałbyś następującą funkcjonalność używając tylko metod statycznych?

interface IDocument 
{
   void Print(IDevice targetDevice);
}

IDocument instance;

instance = new PdfDocument();
instance.Print(printer);

instance = new WordDocument();
instance.Print(printer);

Moja "reguła" to:

• Jeśli nie muszę używać właściwości z mojej klasy, zrób to statycznie. (innymi słowy, jeśli metoda nie jest tak naprawdę dołączona do klasy, tylko do asocjacji logicznej, Użyj static)

Ogólnie jeśli masz metodę jak:

Document.Copy(myDocumentObject, toPath);

Myślę, że lepiej jest użyć metody niestatycznej, ponieważ pierwszy parametr będący dokumentem sugeruje, że jest to naprawdę operacja na dokumencie.

Ogólnie rzecz biorąc, podczas programowania przy użyciu oo, będziesz chciał unikać używania metod statycznych. W OOP, ideą jest reprezentowanie wszystkiego jako obiektów i dać każdemu obiektowi jasny zestaw umiejętności, które reprezentują jego podstawową abstrakcję. Metody statyczne "przełamują" tę abstrakcję.

Twój przykład mówiący o klasie dokumentu z metodą kopiowania jest najlepszym przykładem. Argumentowałbym, że poprawna implementacja OO jest pierwszą drogą . Czyli mieć kopię jako przykładowa Metoda:

document1.copy(toPath)

Ma sens, że możliwość kopiowania jest częścią abstrakcji rdzenia dokumentów. W ten sposób kod klienta wysyłającego wiadomość copy musi tylko określić, gdzie skopiować do , ponieważ zrozumiałe jest, że dokument śledzi, gdzie znajduje się wewnętrznie. Nie ma potrzeby, aby te informacje były powielane gdziekolwiek indziej, co jest poważnym problemem z trzecią opcją, którą prezentujesz, która wygląda tak:

Document.copy(fromPath, toPath)

Jeśli musisz pytać, nie używaj statyki.

Rzeczywista zasada (i jest wiele prawdziwych powodów technicznych, ale uważam, że pomaga to wyjaśnić pojęcia):

• Jeśli dana klasa może istnieć wiele razy, nie jest statyczna.

• Jeśli dana metoda działa przeciwko informacji o instancji, nie jest statyczna.

• Jeśli metoda lub klasa dotyczy meta-informacji, to jest statyczna.

Z tymi wytycznymi to jasne, że pliki i dokumenty są wielokrotnościami, a kopiowanie jest działaniem przeciwko instancji. Metoda nie powinna być statyczna.

Metody statyczne mogą być bardzo przydatne, uwielbiam metody rozszerzania, ale wymuszają sprzęganie i jeśli są używane niewłaściwie, mogą sprawić, że testowanie stanie się koszmarem!

Dobrym przykładem kiedy używać statycznego jest kiedy chcesz to zrobić Walidacja

public static errors Validate(Document myDoc)
{
..some validation code
}

To jest bardzo testowalne i nie ma znaczenia, że Twoje ścisłe powiązanie metody z obiektem. Złym miejscem do korzystania z metody statycznej jest, gdy dozuje coś innego, a następnie po prostu coś zwraca, przykładem może być w warstwie Biz, która waliduje obiekt i jeśli przejdzie walidację, zapisze dane do DB

public static errors ValidateAndSave(Document myDoc)
{
    errors docErrors = Validate(myDoc);
    if(docErrors.count==0)
    {
         docErrors = SaveToDB(myDoc);
    }

   return docErrors; 
} 

To jest prawdziwy ból do testowania, ponieważ za każdym razem, gdy go uruchomić, i przechodzi walidacji biorąc do bazy danych, twoja logika Biz może nie generować błąd, ale twoja warstwa DAL może, więc zamiast tylko testowania funkcjonalności warstwy Biz również trzeba przetestować warstwę DAL, jak również, i szczelnie łącząc swój obiekt, warstwy Biz i twój Dal razem czyni to bardzo trudne do testowania i utrzymania.

Ogólnie rzecz biorąc, powiedziałbym, że "kopiowanie" siebie, jeśli chodzi o obiekt, zwykle oznacza klonowanie własnych danych w nowy obiekt. Opisane tutaj "kopiowanie" jest czymś, co system plików robi w Twoim imieniu, a nie obiekt. Jako taki, zrobiłbym to metodą statyczną, a nie metodą na instancji dokumentu.

To samo co altCongnito i dodam ten fileObject.Kopiuj każdy będzie używał, więcej niż obiekt fileObject. Statyczne dla funkcji, które mają idealną relację z klasą, A nie funkcjonalną jej zależność.

Jeśli używasz innych obiektów, to domyślnie używasz metod poziomu instancji, aby można było skonfigurować te zależności za pomocą iniekcji zależności.

Na przykład, jeśli jeden z tych obrazów był obrazem SVG, możesz mieć zależność od parsera XML, który (przynajmniej w Javie) ma wiele implementacji, podobnie jak w przypadku RENDERERÓW SVG, jak sobie wyobrażam, i wiele innych składowych typów obrazów może wymagać podobnych rozwiązań, które ewoluują w miarę ewolucji stanu obiektu lub które muszą być zmiany w różnych scenariuszach użytkowania (np. test, produkcja, różne projekty ponownie wykorzystujące kod).

Migające pomarańczowe światło ostrzegawcze oznacza, że możesz używać klas, które nie są częścią domyślnych bibliotek twojego frameworka, więc dokonałeś wyboru zewnętrznego komponentu i jeśli używasz statyki, nie jesteś w stanie zmodyfikować tej decyzji.

Użytecznym "redline" jest to, że jeśli dotkniesz innego procesu (serwer bazy danych, serwis internetowy itp.), to uznałbym statyczną metodę za złą 100% czasu, ponieważ sprawia to, że testy jednostkowe są bardziej trudne.