Wzorce projektowe -Design Patterns

Wzorce projektowe:
elementy oprogramowania obiektowego wielokrotnego użytku
Wzorce projektowe cover.jpg
Autor „Gang Czterech”:
Kraj Stany Zjednoczone
Podmiot Wzorce projektowe , inżynieria oprogramowania , programowanie obiektowe
Wydawca Addison-Wesley
Data publikacji
 1994
Strony 395
Numer ISBN 0-201-63361-2
OCLC 31171684
005.1/2 20
Klasa LC QA76.64 .D47 1995

Design Patterns: Elements of Reusable Object-Oriented Software (1994) toksiążka o inżynierii oprogramowania opisująca wzorce projektowania oprogramowania . Książka została napisana przez Ericha Gamma , Richarda Helma, Ralpha Johnsona i Johna Vlissidesa , z przedmową Grady Boocha . Książka podzielona jest na dwie części, przy czym pierwsze dwa rozdziały badają możliwości i pułapki programowania obiektowego, a pozostałe rozdziały opisują 23 klasyczne wzorce projektowania oprogramowania . Książka zawiera przykłady w C++ i Smalltalk .

Wywarł wpływ na dziedzinę inżynierii oprogramowania i jest uważany za ważne źródło teorii i praktyki projektowania obiektowego. Sprzedano ponad 500 000 egzemplarzy w języku angielskim i 13 innych językach. Autorzy są często określani jako Gang of Four ( GoF ).

Historia

Książka rozpoczęła się od sesji ptaków z piór (BoF) podczas OOPSLA '90, „Towards an Architecture Handbook”, prowadzonej przez Bruce'a Andersona, gdzie Erich Gamma i Richard Helm spotkali się i odkryli ich wspólne zainteresowania. Później dołączyli do nich Ralph Johnson i John Vlissides. Oryginalna data publikacji książki to 21 października 1994 r. z prawem autorskim 1995, stąd często przytaczana jest z 1995 rokiem, mimo że została opublikowana w 1994 roku. Książka została po raz pierwszy udostępniona opinii publicznej na spotkaniu OOPSLA, które odbyło się w Portland. , Oregon, w październiku 1994 r. W 2005 r. ACM SIGPLAN przyznał autorom tegoroczną nagrodę za osiągnięcia w zakresie języków programowania w uznaniu wpływu ich pracy "na praktykę programowania i projektowanie języków programowania". W marcu 2012 roku książka była w 40. druku.

Wstęp

Rozdział 1 to omówienie technik projektowania obiektowego , oparte na doświadczeniach autorów, które ich zdaniem doprowadziłyby do dobrego projektowania oprogramowania zorientowanego obiektowo, w tym:

Autorzy twierdzą, że przewaga interfejsów nad implementacją jest następująca:

  • klienci pozostają nieświadomi konkretnych typów obiektów, z których korzystają, o ile obiekt przylega do interfejsu
  • klienci pozostają nieświadomi klas, które implementują te obiekty; klienci wiedzą tylko o abstrakcyjnych klasach definiujących interfejs

Użycie interfejsu prowadzi również do dynamicznego wiązania i polimorfizmu , które są głównymi cechami programowania obiektowego.

Autorzy odnoszą się do spadku jako białej skrzynki ponownego użycia , z biało-box odnosząc się do widoczności, ponieważ wewnętrzne klas dominujących są często widoczne na podklasy . W przeciwieństwie do tego autorzy odnoszą się do kompozycji obiektów (w której obiekty z dobrze zdefiniowanymi interfejsami są używane dynamicznie w czasie wykonywania przez obiekty uzyskujące referencje do innych obiektów) jako do ponownego wykorzystania czarnoskrzynkowego, ponieważ żadne wewnętrzne szczegóły skomponowanych obiektów nie muszą być widoczne w kodzie za pomocą im.

Autorzy szczegółowo omawiają napięcie między dziedziczeniem a enkapsulacją i stwierdzają, że w swoim doświadczeniu projektanci nadużywają dziedziczenia (Gang of Four 1995:20). Niebezpieczeństwo jest określone w następujący sposób:

„Ponieważ dziedziczenie udostępnia podklasę szczegółom implementacji jej rodzica, często mówi się, że„ dziedziczenie łamie enkapsulację ”. (Gang Czwórki 1995:19)

Ostrzegają, że implementacja podklasy może być tak powiązana z implementacją jej klasy rodzica, że ​​każda zmiana w implementacji rodzica zmusi podklasę do zmiany. Co więcej, twierdzą, że sposobem na uniknięcie tego jest dziedziczenie tylko z klas abstrakcyjnych — ale jednocześnie zwracają uwagę, że ponowne użycie kodu jest minimalne.

Stosowanie dziedziczenia jest zalecane głównie przy dodawaniu funkcjonalności istniejących komponentów, ponownym wykorzystaniu większości starego kodu i dodawaniu stosunkowo niewielkich ilości nowego kodu.

Dla autorów „delegacja” jest skrajną formą kompozycji obiektów, którą zawsze można wykorzystać do zastąpienia dziedziczenia. Delegacja obejmuje dwa obiekty: „nadawca” przechodzi do „delegata”, aby umożliwić delegatowi odwoływanie się do nadawcy. W ten sposób połączenie między dwiema częściami systemu jest ustanawiane tylko w czasie wykonywania, a nie w czasie kompilacji. Artykuł Callback zawiera więcej informacji na temat delegowania.

Autorzy omawiają również tzw. typy sparametryzowane, które są również nazywane rodzajami (Ada, Eiffel, Java , C#, VB.NET i Delphi) lub szablonami (C++). Pozwalają one na zdefiniowanie dowolnego typu bez określania wszystkich innych używanych typów — nieokreślone typy są dostarczane jako „parametry” w miejscu użycia.

Autorzy przyznają, że delegowanie i parametryzacja są bardzo potężne, ale dodają ostrzeżenie:

„Dynamiczne, wysoce sparametryzowane oprogramowanie jest trudniejsze do zrozumienia i zbudowania niż bardziej statyczne oprogramowanie”. (Gang Czwórki 1995:21)

Autorzy dalej rozróżniają „ agregację ”, w której jeden obiekt „ma” lub „jest częścią” innego obiektu (co oznacza, że ​​zagregowany obiekt i jego właściciel mają identyczne czasy życia) oraz znajomość, gdzie jeden obiekt po prostu „zna” inny obiekt. Czasami znajomość nazywa się „stowarzyszeniem” lub „stosowaniem”. Znajome obiekty mogą żądać od siebie operacji, ale nie są za siebie odpowiedzialne. Znajomość jest słabszą relacją niż agregacja i sugeruje znacznie luźniejsze sprzężenie między obiektami, co często może być pożądane dla maksymalnej łatwości konserwacji w projekcie.

Autorzy używają terminu „zestaw narzędzi”, podczas gdy inni mogą dziś używać „biblioteki klas”, jak w C# lub Javie. W swoim żargonie zestawy narzędzi są obiektowo zorientowanymi odpowiednikami bibliotek podprogramów, podczas gdy „ framework ” to zestaw współpracujących ze sobą klas, które tworzą projekt wielokrotnego użytku dla określonej klasy oprogramowania. Twierdzą, że aplikacje są trudne do zaprojektowania, zestawy narzędzi są trudniejsze, a frameworki są najtrudniejsze do zaprojektowania.

Wzory według typu

Kreatywne

Główny artykuł: wzorzec kreacji

Wzorce twórcze to takie, które tworzą obiekty, a nie muszą bezpośrednio tworzyć instancje obiektów. Daje to programowi większą elastyczność w decydowaniu, które obiekty należy utworzyć w danym przypadku.

  • Fabryka abstrakcyjna grupuje fabryki obiektów, które mają wspólny motyw.
  • Builder buduje złożone obiekty, oddzielając konstrukcję i reprezentację.
  • Metoda Factory tworzy obiekty bez określania dokładnej klasy do utworzenia.
  • Prototype tworzy obiekty poprzez klonowanie istniejącego obiektu.
  • Singleton ogranicza tworzenie obiektów dla klasy tylko do jednej instancji.

Strukturalny

Dotyczą one kompozycji klas i obiektów. Wykorzystują dziedziczenie do komponowania interfejsów i definiują sposoby komponowania obiektów w celu uzyskania nowej funkcjonalności.

  • Adapter umożliwia współpracę klas z niekompatybilnymi interfejsami poprzez owijanie własnego interfejsu wokół interfejsu już istniejącej klasy.
  • Bridge oddziela abstrakcję od jej implementacji, dzięki czemu obie mogą się różnić niezależnie.
  • Composite składa zero lub więcej podobnych obiektów, dzięki czemu można nimi manipulować jak jednym obiektem.
  • Dekorator dynamicznie dodaje/nadpisuje zachowanie w istniejącej metodzie obiektu.
  • Fasada zapewnia uproszczony interfejs do dużej części kodu.
  • Flyweight zmniejsza koszt tworzenia i manipulowania dużą liczbą podobnych obiektów.
  • Proxy zapewnia miejsce zastępcze dla innego obiektu, aby kontrolować dostęp, zmniejszać koszty i zmniejszać złożoność.

Behawioralne

Większość z tych wzorców projektowych dotyczy w szczególności komunikacji między obiektami.

  • Łańcuch odpowiedzialności deleguje polecenia do łańcucha przetwarzanych obiektów.
  • Polecenie tworzy obiekty, które hermetyzują akcje i parametry.
  • Tłumacz implementuje język specjalistyczny.
  • Iterator uzyskuje dostęp do elementów obiektu sekwencyjnie bez ujawniania jego podstawowej reprezentacji.
  • Mediator umożliwia luźne sprzężenie między klasami, będąc jedyną klasą, która ma szczegółową wiedzę na temat swoich metod.
  • Memento daje możliwość przywrócenia obiektu do poprzedniego stanu (cofnij).
  • Observer to wzorzec publikowania/subskrypcji, który umożliwia wielu obiektom obserwatora zobaczenie zdarzenia.
  • Stan pozwala obiektowi zmienić swoje zachowanie, gdy zmieni się jego stan wewnętrzny.
  • Strategia umożliwia wybór jednego z rodziny algorytmów w locie w czasie wykonywania.
  • Metoda szablonowa definiuje szkielet algorytmu jako klasę abstrakcyjną, umożliwiając jego podklasom zapewnienie konkretnego zachowania.
  • Odwiedzający oddziela algorytm od struktury obiektu, przenosząc hierarchię metod do jednego obiektu.

Krytyka

Krytyka była skierowana ogólnie na koncepcję wzorców projektowania oprogramowania , a konkretnie na wzorce projektowe . Główną krytyką wzorców projektowych jest to, że ich wzorce są po prostu obejściem brakujących funkcji w C ++, zastępując eleganckie abstrakcyjne funkcje długimi konkretnymi wzorcami, zasadniczo stając się „ludzkim kompilatorem” lub „ręcznie generującym rozszerzenia niektórych makr”. Paul Graham napisał:

Kiedy widzę wzorce w moich programach, uważam to za oznakę kłopotów. Kształt programu powinien odzwierciedlać tylko problem, który musi rozwiązać. Każda inna prawidłowość w kodzie jest oznaką, przynajmniej dla mnie, że używam abstrakcji, które nie są wystarczająco potężne -- często, że generuję ręcznie rozwinięcia jakiegoś makra, które muszę napisać.

Peter Norvig pokazuje, że 16 z 23 wzorców we wzorcach projektowych jest uproszczonych lub wyeliminowanych przez funkcje językowe w Lisp lub Dylan . Pokrewnych obserwacji dokonali Hannemann i Kiczales, którzy zaimplementowali kilka z 23 wzorców projektowych przy użyciu zorientowanego aspektowo języka programowania ( AspectJ ) i wykazali, że zależności na poziomie kodu zostały usunięte z implementacji 17 z 23 wzorców projektowych i że zorientowane aspektowo programowanie może uprościć implementacje wzorców projektowych.

Pojawiły się również humorystyczne krytyki, takie jak pokazowy proces w OOPSLA '99 3 listopada 1999 r. oraz parodia formatu autorstwa Jima Copliena zatytułowana „ Kansas City Air Conditioner ”.

W wywiadzie dla InformIT w 2009 r. Erich Gamma stwierdził, że autorzy książki przeprowadzili dyskusję w 2005 r. na temat tego, w jaki sposób dokonaliby refaktoryzacji książki i doszli do wniosku, że zmieniliby kategorie niektórych wzorców i dodali kilka dodatkowych. Gamma chciał usunąć wzorzec Singletona, ale nie było zgody wśród autorów, aby to zrobić.

Zobacz też

Uwagi

Bibliografia