Niemal standardowe nazwy klas

2008-01-02 13:48
Model-View-Controller
Model-View-Controller (MVC),
bardzo modny ostatnio ‘wzorzec’

Wzorce projektowe (design patterns) to w założeniu ogólne modele związków pomiędzy klasami (i samych klas), jakie mogą pojawiać się w projektach. Każdy taki wzorzec jest przeznaczony do dość ściśle określonych okoliczności, dokładnie opisany i, przede wszystkim, nazwany. Na pewno każdy średnio zaawansowany programista miał okazję spotkać się z takimi terminami jak Iterator, Fabryka czy Singleton. Są one już na tyle długo używane, że w większości przypadków nie ma problemów ze zrozumieniem tego, co w danej sytuacji oznaczają.

Wzorce nie są oczywiście doskonałe. Ze względu na względnie dużą ścisłość nie mogą opisywać wszystkich rozwiązań, jakie mogą być konieczne, jeśli myślimy o zaprojektowaniu dowolnego programu. Nie jest więc tak, że każda klasa, jaka przyjdzie nam głowy, może być od razu wpasowana w jakiś gotowy szablon.
Przeglądając gotowe kody i różnego rodzaju dokumentacje stwierdziłem jednak, że często powtarzają się w nich różnego rodzaju “pseudowzorce”. Objawiają się one głównie używaniem pewnych słów w nazwach klas, dzięki którym można mniej więcej domyślić się, jaka jest rola poszczególnych typów, do czego służą, jak – z grubsza – działają oraz jakie wykazują zależności z innymi klasami. Naturalnie mogą występować spore różnice pomiędzy poszczególnymi bibliotekami i językami, ale przynajmniej dla dwóch największych zbiorów klas, jakie są obecnie w powszechnym użyciu (czyli .NET Framework i JDK), rozbieżności nie są zbyt duże. Co więcej, ponieważ wielu programistów używa któregoś z tych dwóch narzędzi, często przejmują oni te wzorce nazewnictwa (świadomie lub nie) i stosują je we własnych kodach. Kto wie, może dzięki temu przeciętna czytelność kodu produkowanego przez statystycznego programistę (jeśli w ogóle istnieje ktoś taki :]) ma szansę choć odrobinę wzrosnąć?…

Jakie są więc te nieformalne “wzorce”? Otóż znalazłem kilka następujących:

  • Manager to egzemplarz występujący bardzo często i niestety chyba najmniej jednoznaczny z nich wszystkich. W dosłownym tłumaczeniu jest to ‘zarządca’ czegoś i właściwie niewiele więcej można o nim powiedzieć. Nazywanie wszystkiego ‘menedżerem’ jest popularne zwłaszcza wśród programistów gier: mamy więc menedżery zasobów, tekstur, stanów, czcionek – i tak dalej. Zastanawiam się tylko, skąd to upodobanie to tego akurat terminu. Czyżby programiści z sentymentem wspominali w ten sposób Menedżera Programów, czyli sławetną “powłokę” systemu Windows w archaicznych wersjach 3.x? :)
  • Handler (ew. listener) jest już znacznie precyzyjniejszym pojęciem. Zazwyczaj jest to bowiem obiekt, który ma wykonywać jakieś działanie w reakcji na określenie zdarzenie – czyli ma je ‘obsługiwać’. Najczęściej oznacza to, że typ handlera jest tylko abstrakcyjną klasą bazową lub interfejsem, po którym powinniśmy dziedziczyć, a następnie zaimplementować jego metody i wreszcie “podpiąć” powstały obiekt pod mechanizm obsługi zdarzeń. Typowym zastosowaniem takiego rozwiązania jest reakcja na zdarzenia interfejsu użytkownika (klikanie w przyciski, wciśnięcia klawiszy, itd.) albo powiadamianie o przebiegu operacji asynchronicznych (np. komunikacji sieciowej).
  • Provider jest z kolei obiektem, który ma ‘dostarczać'(lub ‘zapewniać’) jakąś funkcjonalność. Od strony technicznej często działa on tak samo jak handler (czyli w oparciu o polimorfizm metod wirtualnych), tyle że jego przeznaczenie i sposób użycia są nieco inne. Takiego providera podajemy w funkcji lub w obiekcie, dzięki czemu może ona wykonać przy jego pomocy jakieś czynności. Prostym przykładem jest chociażby sortowanie, któremu podajemy obiekt komparatora, odpowiedzialny za dokonywanie porównań. Tak naprawdę jest to więc po prostu wzorzec Strategia (Polityka – policy), któremu ktoś z niewiadomych powodów nadał bardziej “profesjonalną” nazwę.
  • Context oznacza najczęściej taki obiekt, który definiuje jakieś ‘środowisko’, w którym działają inne obiekty. Są one zależne od obiektu reprezentującego kontekst, ale nie można powiedzieć, aby ten się z nich składał (może on nawet “nie wiedzieć”, że jest przez nie wykorzystywany). Po prostu dzięki niemu obiekty “potomne” mogą wykonywać swoje czynności.

Prawdopodobnie dałoby się wyróżnić jeszcze kilka pozycji (chociaż część byłaby dokładnym odpowiednikiem klasycznych wzorców projektowych), ale, jak widać, w sumie chyba nie jest ich zbyt dużo. To w gruncie rzeczy całkiem dobra wiadomość, gdyż nietrudno zauważyć, że wszystkie te nazwy są raczej “magiczne” i na pierwszy rzut nie przywołują jakichś natychmiastowych skojarzeń – zwłaszcza, jeśli nie jesteśmy do nich przyzwyczajeni. Ale taki już urok projektowania zorientowanego obiektowo, polegającego na tworzeniu dziwnych bytów i jeszcze dziwniejszych zależności między nimi :)

Be Sociable, Share!
Be Sociable, Share!
Tags: ,
Author: Xion, posted under Programming »


4 comments for post “Niemal standardowe nazwy klas”.
  1. moriturius:
    January 3rd, 2008 o 9:54

    Możesz powiedzieć trochę więcej o Providerze i Context’cie? (jak to napisac? :P). Jak dotąd używałem tylko Managerów i Handlerów :P

    Chętnie poznam nowe formy kształtowania kodu ^^

  2. moriturius:
    January 3rd, 2008 o 9:55

    W myśl zasady:

    “O ile Ty staniesz się lepszy – Twój kod stanie się lepszy” :P

  3. Xion:
    January 3rd, 2008 o 10:20

    Provider to abstrakcyjny interfejs, który implementuje się, aby inna klasa lub funkcja mogła wykonywać pewne operacje w sposób dla nas pożądany. Przykład to choćby IFormatProvider z .NETa, który to odpowiada za sposób interpretacji znaczników formatowania tekstu (coś jak printf() z C++).

    Context nazwałem ‘wzorcem’ może trochę na wyrost. Generalnie jest to taki obiekt narzędziowy, który jest dostępny właściwie wszędzie (może być globalny), który udostępnia jakąś kluczową funkcjonalność. Przykład to HttpContext z ASP.NET, za pośrednictwem którego ma się dostęp do żądania HTTP, strumienia odpowiedzi na to żądanie, danych serwera, danych sesji, danych zalogowanego usera – czyli dosłownie wszystkiego, co jest potrzebne aplikacji webowej do działania.
    Mój własny przykład to MathContext – obiekt główny parsera wyrażeń matematycznych, który potrafi tworzyć obiekty rzeczonych wyrażeń, ale także pamięta wartości zmiennych oraz definicje niestandardowych funkcji, które mogą być wykorzystywane przez te wyrażenia.

  4. siso:
    September 29th, 2009 o 2:18

    Nie nazywałbym “Manager’a” wzorcem nieformalnym. Jego istnienie jest jak najbardziej udokumentowane, nawet poświęcono mu osobny dział teorii DP – wzorce z zarządzaniu zasobami (polecam książkę o zbliżonym tytule).

    Listener jest także nazywany Observer’em.

Comments are disabled.
 


© 2020 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.