Zajęcia z jedną metodą - najlepsze podejście?

Powiedzmy, że mam klasę, która ma wykonywać jedną funkcję. Po wykonaniu funkcji można go zniszczyć. Czy jest jakiś powód, aby preferować jedno z tych podejść?

// Initialize arguments in constructor
MyClass myObject = new MyClass(arg1, arg2, arg3);
myObject.myMethod();

// Pass arguments to method
MyClass myObject = new MyClass();
myObject.myMethod(arg1, arg2, arg3);

// Pass arguments to static method
MyClass.myMethod(arg1, arg2, arg3);

Celowo nie rozumiałem szczegółów, próbując uzyskać wskazówki dotyczące różnych sytuacji. Ale tak naprawdę nie miałem na myśli prostych funkcji bibliotecznych, takich jak Math.random (). Myślę bardziej o zajęciach, które wykonują określone, złożone zadanie, ale wymagają do tego tylko jednej (publicznej) metody.

Kiedyś uwielbiałem klasy użytkowe wypełnione metodami statycznymi. Dokonali wielkiej konsolidacji metod pomocniczych, które w przeciwnym razie powodowałyby piekło redundancji i konserwacji. Są bardzo łatwe w użyciu, bez tworzenia instancji, bez utylizacji, po prostu odpal i zapomnij. Myślę, że to była moja pierwsza nieświadoma próba stworzenia architektury zorientowanej na usługi - wiele usług bezstanowych, które po prostu wykonały swoją pracę i nic więcej. Jednak wraz z rozwojem systemu pojawią się smoki.

Polimorfizm
Powiedzmy, że mamy metodę UtilityClass.SomeMethod, która radośnie brzęczy. Nagle musimy nieco zmienić funkcjonalność. Większość funkcji jest taka sama, ale mimo to musimy zmienić kilka części. Gdyby nie była to metoda statyczna, moglibyśmy stworzyć klasę pochodną i zmienić zawartość metody w razie potrzeby. Ponieważ jest to metoda statyczna, nie możemy. Jasne, jeśli musimy tylko dodać funkcjonalność przed lub po starej metodzie, możemy utworzyć nową klasę i wywołać w niej starą - ale to po prostu obrzydliwe.

Problemy z interfejsem
Metod statycznych nie można definiować za pośrednictwem interfejsów z powodów logicznych. A ponieważ nie możemy przesłonić metod statycznych, klasy statyczne są bezużyteczne, gdy musimy je przekazać przez ich interfejs. To sprawia, że ​​nie możemy używać klas statycznych jako części wzorca strategii. Możemy załatać niektóre problemy, przekazując delegatów zamiast interfejsów .

Testowanie
Zasadniczo idzie to w parze z problemami interfejsu opisanymi powyżej. Ponieważ nasza zdolność do wymiany implementacji jest bardzo ograniczona, będziemy mieć również problem z zastąpieniem kodu produkcyjnego kodem testowym. Ponownie możemy je zawinąć, ale będzie to wymagało zmiany dużych części naszego kodu, aby móc akceptować opakowania zamiast rzeczywistych obiektów.

Wspiera obiekty blob
Ponieważ metody statyczne są zwykle używane jako metody użytkowe, a metody narzędziowe zwykle mają różne cele, szybko skończymy z dużą klasą wypełnioną niespójną funkcjonalnością - najlepiej, aby każda klasa miała jeden cel w systemie . Wolałbym mieć pięć razy więcej klas, o ile ich cele są dobrze określone.

Pełzanie parametrów
Po pierwsze, ta mała urocza i niewinna metoda statyczna może przyjmować jeden parametr. Wraz ze wzrostem funkcjonalności dodawanych jest kilka nowych parametrów. Wkrótce dodawane są kolejne parametry, które są opcjonalne, więc tworzymy przeciążenia metody (lub po prostu dodajemy wartości domyślne w językach, które je obsługują). Wkrótce mamy metodę, która przyjmuje 10 parametrów. Tylko pierwsze trzy są naprawdę wymagane, parametry 4-7 są opcjonalne. Ale jeśli określono parametr 6, wymagane jest również wypełnienie 7-9 ... Gdybyśmy utworzyli klasę, której jedynym celem jest zrobienie tego, co zrobiła ta metoda statyczna, moglibyśmy rozwiązać ten problem, przyjmując wymagane parametry w konstruktor i zezwalając użytkownikowi na ustawianie wartości opcjonalnych za pomocą właściwości lub metod w celu ustawienia wielu współzależnych wartości w tym samym czasie. Ponadto, jeśli metoda urosła do takiego stopnia złożoności,

Wymaganie od konsumentów tworzenia instancji klas bez powodu
Jednym z najczęstszych argumentów jest to, po co żądać, aby konsumenci naszej klasy utworzyli instancję wywołującą tę pojedynczą metodę, nie mając później pożytku z instancji? Tworzenie instancji klasy jest bardzo tanią operacją w większości języków, więc szybkość nie jest problemem. Dodanie dodatkowej linii kodu do konsumenta to niski koszt położenia podwalin pod znacznie łatwiejsze w utrzymaniu rozwiązanie w przyszłości. I wreszcie, jeśli chcesz uniknąć tworzenia instancji, po prostu utwórz pojedynczą otokę swojej klasy, która umożliwia łatwe ponowne użycie - chociaż wymaga to, aby Twoja klasa była bezstanowa. Jeśli nie jest bezstanowy, nadal możesz tworzyć statyczne metody opakowujące, które obsługują wszystko, a jednocześnie zapewniają wszystkie korzyści na dłuższą metę. Wreszcie,

Tylko Sith postępuje absolutnie.
Oczywiście są wyjątki od mojej niechęci do metod statycznych. Prawdziwe klasy użytkowe, które nie stwarzają żadnego ryzyka rozdęcia, są doskonałymi przypadkami dla metod statycznych - na przykład System.Convert. Jeśli twój projekt jest jednorazowy i nie ma wymagań dotyczących przyszłej konserwacji, ogólna architektura naprawdę nie jest bardzo ważna - statyczna lub niestatyczna nie ma tak naprawdę znaczenia - jednak szybkość rozwoju ma znaczenie.

Normy, normy, standardy!
Korzystanie z metod instancji nie ogranicza możliwości używania metod statycznych i na odwrót. O ile istnieje uzasadnienie za różnicowaniem i jest ustandaryzowane. Nie ma nic gorszego niż przeglądanie warstwy biznesowej obejmującej różne metody implementacji.

Wolę sposób statyczny. Ponieważ klasa nie reprezentuje obiektu, nie ma sensu tworzyć jej instancji.

Klasy, które istnieją tylko dla ich metod, powinny pozostać statyczne.

Jeśli nie ma powodu, aby utworzyć instancję klasy w celu wykonania funkcji, użyj implementacji statycznej. Po co zmuszać konsumentów tej klasy do tworzenia instancji, gdy nie jest ona potrzebna.

Jeśli nie musisz zapisywać stanu obiektu, nie ma potrzeby tworzenia go w pierwszej kolejności. Wybrałbym pojedynczą statyczną metodę, do której przekazujesz parametry.

Ostrzegałbym również przed olbrzymią klasą Utils, która ma dziesiątki niepowiązanych metod statycznych. W pośpiechu może to spowodować dezorganizację i problemy z obsługą. Lepiej jest mieć wiele klas, każda z kilkoma powiązanymi metodami.

Powiedziałbym, że format metody statycznej byłby lepszą opcją. Uczyniłbym również klasę statyczną, dzięki czemu nie musisz się martwić o przypadkowe utworzenie instancji klasy.

Naprawdę nie wiem, jaka jest tutaj sytuacja, ale spróbuję umieścić ją jako metodę w jednej z klas, do których należą arg1, arg2 lub arg3 - Jeśli możesz semantycznie powiedzieć, że jedna z tych klas będzie właścicielem metoda.

Sugerowałbym, że trudno jest odpowiedzieć na podstawie dostarczonych informacji.

Wydaje mi się, że jeśli zamierzasz mieć tylko jedną metodę i natychmiast wyrzucisz klasę, to uczyń ją statyczną klasą, która przyjmuje wszystkie parametry.

Oczywiście trudno jest dokładnie określić, dlaczego musisz utworzyć jedną klasę tylko dla tej jednej metody. Czy jest to typowa sytuacja „klasy usług użyteczności publicznej”, jak większość zakłada? A może implementujesz jakąś klasę reguł, której może być więcej w przyszłości.

Na przykład niech ta klasa jest podłączalna. Następnie chciałbyś utworzyć interfejs dla swojej jednej metody, a następnie chciałbyś, aby wszystkie parametry były przekazywane do interfejsu, a nie do konstruktora, ale nie chciałbyś, aby był statyczny.

Czy Twoja klasa może być statyczna?

Jeśli tak, to uczyniłbym to klasą „Narzędzia”, w której umieściłbym wszystkie moje klasy z jedną funkcją.

Jeśli ta metoda jest bezstanowa i nie ma potrzeby jej przekazywania, najbardziej sensowne jest zdefiniowanie jej jako statycznej. Jeśli naprawdę potrzebujesz przekazać tę metodę, możesz rozważyć użycie delegata zamiast jednego z innych proponowanych podejść.

W przypadku prostych aplikacji i internalpomocników użyłbym metody statycznej. W przypadku aplikacji ze składnikami podoba mi się platforma Managed Extensibility Framework . Oto fragment dokumentu, który piszę, aby opisać wzorce, które znajdziesz w moich interfejsach API.

• Usługi
  • Zdefiniowany przez I[ServiceName]Serviceinterfejs.
  • Eksportowane i importowane według typu interfejsu.
  • Pojedyncza implementacja jest dostarczana przez aplikację hosta i wykorzystywana wewnętrznie i / lub przez rozszerzenia.
  • Metody w interfejsie usługi są bezpieczne wątkowo.

Jako wymyślony przykład:

public interface ISettingsService
{
    string ReadSetting(string name);

    void WriteSetting(string name, string value);
}

[Export]
public class ObjectRequiringSettings
{
    [Import]
    private ISettingsService SettingsService
    {
        get;
        set;
    }

    private void Foo()
    {
        if (SettingsService.ReadSetting("PerformFooAction") == bool.TrueString)
        {
            // whatever
        }
    }
}

Po prostu zrobiłbym wszystko w konstruktorze. tak:

new MyClass(arg1, arg2, arg3);// the constructor does everything.

lub

MyClass my_object(arg1, arg2, arg3);

Jeszcze jedną ważną kwestią do rozważenia jest to, czy system działałby w środowisku wielowątkowym i czy byłoby bezpieczne wątkowo mieć metodę statyczną lub zmienne ...

Należy zwrócić uwagę na stan systemu.

Może uda wam się wspólnie uniknąć tej sytuacji. Spróbuj refaktoryzować, aby uzyskać arg1.myMethod1(arg2, arg3). Zamień arg1 na arg2 lub arg3, jeśli ma to większy sens.

Jeśli nie masz kontroli nad klasą arg1, udekoruj ją:

class Arg1Decorator
    private final T1 arg1;
    public Arg1Decorator(T1 arg1) {
        this.arg1 = arg1;
    }
    public T myMethod(T2 arg2, T3 arg3) {
        ...
    }
 }

 arg1d = new Arg1Decorator(arg1)
 arg1d.myMethod(arg2, arg3)

Rozumowanie jest takie, że w przypadku OOP dane i metody przetwarzania tych danych należą do siebie. Plus masz wszystkie zalety, o których wspomniał Mark.

Myślę, że jeśli właściwości twojej klasy lub instancji klasy nie będą używane w konstruktorach lub w twoich metodach, metody nie powinny być zaprojektowane jako wzorzec „statyczny”. metoda statyczna powinna być zawsze traktowana jako pomoc.

W zależności od tego, czy chcesz tylko coś zrobić, czy coś zrobić i zwrócić, możesz to zrobić:

public abstract class DoSomethingClass<T>
{
    protected abstract void doSomething(T arg1, T arg2, T arg3);
}

public abstract class ReturnSomethingClass<T, V>
{
    public T value;
    protected abstract void returnSomething(V arg1, V arg2, V arg3);
}

public class DoSomethingInt extends DoSomethingClass<Integer>
{
    public DoSomethingInt(int arg1, int arg2, int arg3)
    {
        doSomething(arg1, arg2, arg3);
    }

    @Override
    protected void doSomething(Integer arg1, Integer arg2, Integer arg3)
    {
        // ...
    }
}

public class ReturnSomethingString extends ReturnSomethingClass<String, Integer>
{
    public ReturnSomethingString(int arg1, int arg2, int arg3)
    {
        returnSomething(arg1, arg2, arg3);
    }

    @Override
    protected void returnSomething(Integer arg1, Integer arg2, Integer arg3)
    {
        String retValue;
        // ...
        value = retValue;
    }
}

public class MainClass
{
    static void main(String[] args)
    {
        int a = 3, b = 4, c = 5;

        Object dummy = new DoSomethingInt(a,b,c);  // doSomething was called, dummy is still around though
        String myReturn = (new ReturnSomethingString(a,b,c)).value; // returnSomething was called and immediately destroyed
    }
}