Wzór dla klasy, która robi tylko jedną rzecz

Powiedzmy, że mam procedurę, która wykonuje różne czynności :

void doStuff(initalParams) {
    ...
}

Teraz odkrywam, że „robienie rzeczy” to dość skomplikowana operacja. Procedura staje się duża, podzielę ją na wiele mniejszych procedur i wkrótce zdaję sobie sprawę, że posiadanie jakiegoś stanu byłoby przydatne podczas robienia rzeczy, więc muszę przekazywać mniej parametrów między małymi procedurami. Tak więc dzielę to na własną klasę:

class StuffDoer {
    private someInternalState;

    public Start(initalParams) {
        ...
    }

    // some private helper procedures here
    ...
}

A potem nazywam to tak:

new StuffDoer().Start(initialParams);

lub tak:

new StuffDoer(initialParams).Start();

I to jest złe. Korzystając z .NET lub Java API, nigdy nie dzwonię new SomeApiClass().Start(...);, co mnie podejrzewa, że ​​robię to źle. Jasne, mógłbym ustawić konstruktora StuffDoer na prywatny i dodać metodę statycznego pomocnika:

public static DoStuff(initalParams) {
    new StuffDoer().Start(initialParams);
}

Ale wtedy miałbym klasę, której zewnętrzny interfejs składa się tylko z jednej metody statycznej, co również wydaje się dziwne.

Stąd moje pytanie: czy istnieje dobrze ustalony wzorzec dla tego typu klas, które

• mieć tylko jeden punkt wejścia i
• nie mają stanu „zewnętrznie rozpoznawalnego”, tj. stan instancji jest wymagany tylko podczas wykonywania tego jednego punktu wejścia?

Istnieje wzorzec o nazwie Method Object, w którym wyróżniasz pojedynczą, dużą metodę z dużą ilością tymczasowych zmiennych / argumentów w oddzielnej klasie. Robisz to zamiast wyodrębniać części metody w osobne metody, ponieważ potrzebują one dostępu do stanu lokalnego (parametry i zmienne tymczasowe) i nie możesz udostępnić stanu lokalnego za pomocą zmiennych instancji, ponieważ byłyby lokalne dla tej metody (i metody wyodrębnione z niego) i pozostałyby nieużywane przez resztę obiektu.

Zamiast tego metoda staje się własną klasą, parametry i zmienne tymczasowe stają się zmiennymi instancji tej nowej klasy, a następnie metoda zostaje podzielona na mniejsze metody nowej klasy. Klasa wynikowa ma zwykle tylko jedną metodę instancji publicznej, która wykonuje zadanie zawarte w klasie.

Powiedziałbym, że przedmiotowa klasa (wykorzystująca pojedynczy punkt wejścia) jest dobrze zaprojektowana. Jest łatwy w użyciu i przedłużany. Dość SOLIDNY.

To samo dotyczy no "externally recognizable" state. To dobre kapsułkowanie.

Nie widzę żadnych problemów z kodem, takich jak:

var doer = new StuffDoer(initialParams);
var result = doer.Calculate(extraParams);

Z punktu widzenia zasad SOLID odpowiedź jgauffina ma sens. Nie należy jednak zapominać o ogólnych zasadach projektowania, np . Ukrywania informacji .

Widzę kilka problemów z danym podejściem:

• Jak sam zauważyłeś, ludzie nie oczekują użycia słowa kluczowego „new”, gdy utworzony obiekt nie zarządza żadnym stanem . Twój projekt odzwierciedla jego intencję. Osoby korzystające z twojej klasy mogą się mylić co do tego, w jakim stanie zarządza i czy kolejne wywołania metody mogą spowodować inne zachowanie.
• Z perspektywy osoby korzystającej z klasy stan wewnętrzny jest dobrze ukryty, ale gdy chcesz wprowadzić zmiany w klasie lub po prostu ją zrozumieć, komplikujesz sytuację. Ja już napisałem wiele o problemach widzę metodami rozszczepiania tylko, aby im mniejszy , zwłaszcza podczas przenoszenia stan zakresu klasy. Zmieniasz sposób, w jaki powinien być używany interfejs API, aby mieć mniejsze funkcje! To moim zdaniem zdecydowanie posuwa się za daleko.

Niektóre powiązane odniesienia

Być może głównym argumentem jest to, jak daleko należy rozciągnąć zasadę pojedynczej odpowiedzialności . „Jeśli dojdziesz do tego ekstremum i zbudujesz klasy, które mają jeden powód istnienia, możesz skończyć z tylko jedną metodą na klasę. Spowodowałoby to duży rozrost klas nawet dla najprostszych procesów, powodując, że system byłby trudne do zrozumienia i trudne do zmiany ”.

Kolejne istotne odniesienie do tego tematu: „Podziel swoje programy na metody, które wykonują jedno możliwe do zidentyfikowania zadanie. Zachowaj wszystkie operacje w metodzie na tym samym poziomie abstrakcji ”. - Kent Beck Key tutaj jest „tym samym poziomem abstrakcji”. Nie oznacza to „jednej rzeczy”, ponieważ jest często interpretowane. Ten poziom abstrakcji zależy wyłącznie od kontekstu, dla którego projektujesz.

Jakie jest właściwe podejście?

Trudno powiedzieć bez znajomości konkretnego przypadku użycia. Jest scenariusz, w którym czasami (nie często) stosuję podobne podejście. Kiedy chcę przetworzyć zestaw danych, bez potrzeby udostępniania tej funkcji dla całego zakresu klasy. Napisałem na blogu o tym, w jaki sposób lambdas może jeszcze bardziej poprawić enkapsulację . Zacząłem też pytanie na ten temat tutaj, na temat programistów . Poniżej znajduje się najnowszy przykład zastosowania tej techniki.

new TupleList<Key, int>
{
    { Key.NumPad1, 1 },
            ...
    { Key.NumPad3, 16 },
    { Key.NumPad4, 17 },
}
    .ForEach( t =>
    {
        var trigger = new IC.Trigger.EventTrigger(
                        new KeyInputCondition( t.Item1, KeyInputCondition.KeyState.Down ) );
        trigger.ConditionsMet += () => AddMarker( t.Item2 );
        _inputController.AddTrigger( trigger );
    } );

Ponieważ bardzo „lokalny” kod w ForEachpliku nie jest ponownie używany nigdzie indziej, mogę po prostu przechowywać go w dokładnej lokalizacji, w której ma znaczenie. Zarysowanie kodu w taki sposób, że kod, który opiera się na sobie, jest silnie zgrupowane razem, czyni moim zdaniem bardziej czytelnym.

Możliwe alternatywy

• W języku C # można zamiast tego użyć metod rozszerzenia. Operuj więc argumentem, który przekazujesz bezpośrednio do tej metody „jednej rzeczy”.
• Sprawdź, czy ta funkcja faktycznie nie należy do innej klasy.
• Uczyń go funkcją statyczną w klasie statycznej . To najprawdopodobniej jest najbardziej odpowiednie podejście, co znajduje również odzwierciedlenie w ogólnych interfejsach API, o których mowa.

Powiedziałbym, że jest całkiem dobry, ale twój interfejs API powinien nadal być metodą statyczną w klasie statycznej, ponieważ tego oczekuje użytkownik. Fakt, że metoda statyczna używa newdo tworzenia obiektu pomocnika i wykonywania pracy, jest szczegółem implementacji, który powinien być ukryty przed tym, kto go wywołuje.

new StuffDoer().Start(initialParams);

Występuje problem z nieświadomymi programistami, którzy mogą korzystać z udostępnionej instancji i korzystać z niej

1. wiele razy (ok, jeśli poprzednie (może częściowe) wykonanie nie psuje późniejszego wykonania)
2. z wielu wątków (nie jest OK, wyraźnie powiedziałeś, że ma stan wewnętrzny).

Potrzebuje to więc wyraźnej dokumentacji, że nie jest bezpieczny wątkowo, a jeśli jest lekki (tworzenie go jest szybkie, nie wiąże się z zasobami zewnętrznymi ani dużą ilością pamięci), to jest w porządku, aby utworzyć instancję w locie.

Pomaga w tym ukrywanie go w metodzie statycznej, ponieważ ponowne użycie instancji nigdy się nie zdarza.

Jeśli to ma jakieś drogie inicjalizacji, to może (nie zawsze) będzie korzystne, aby przygotować inicjowanie go raz i używając go wiele razy, tworząc kolejną klasę, która będzie zawierać tylko stan i uczynić go Cloneable. Inicjalizacja utworzy stan, w którym będzie przechowywany doer. start()sklonuje go i przekaże metodom wewnętrznym.

Pozwoliłoby to również na inne rzeczy, takie jak utrzymywanie stanu częściowego wykonania. (Jeśli zajmie to dużo czasu, a czynniki zewnętrzne, np. Awaria zasilania elektrycznego, mogą przerwać wykonanie). Ale te dodatkowe wymyślne rzeczy zwykle nie są potrzebne, więc nie warto.

Poza moją bardziej złożoną, spersonalizowaną inną odpowiedzią , uważam, że poniższa obserwacja zasługuje na osobną odpowiedź.

Istnieją oznaki, że możesz stosować się do anty-wzorca Poltergeists .

Poltergeists to klasy o bardzo ograniczonych rolach i efektywnych cyklach życia. Często rozpoczynają procesy dla innych obiektów. Przebudowane rozwiązanie obejmuje realokację obowiązków na obiekty o dłuższym okresie życia, które eliminują Poltergeistów.

Objawy i konsekwencje

• Nadmiarowe ścieżki nawigacji.
• Przemijające skojarzenia.
• Klasy bezpaństwowe.
• Tymczasowe, krótkotrwałe obiekty i klasy.
• Klasy pojedynczej operacji, które istnieją tylko w celu „rozstawienia” lub „wywołania” innych klas za pomocą tymczasowych skojarzeń.
• Klasy o nazwach operacji podobnych do sterujących, takich jak start_process_alpha.

Refaktoryzowane rozwiązanie

Pogromcy duchów rozwiązują Poltergeistów, usuwając je całkowicie z hierarchii klas. Jednak po ich usunięciu funkcjonalność „zapewniona” przez poltergeist musi zostać wymieniona. Jest to łatwe dzięki prostemu dostosowaniu w celu korekty architektury.

Istnieje kilka wzorów, które można znaleźć w P Martina Fowlera z katalogu EAA ;

1. Skrypt transakcji : nieco podobny do wspomnianego podejścia.
2. Zastąp metodę w / Metoda obiektu : Wygląda też na dobre podejście, jak wspomniano @anon.