Pusty Obiekt (wzorzec projektowy)

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacji, wyszukiwania

Definicja intuicyjna:
Wzorzec Pusty Obiekt umożliwia nam uniknięcie sprawdzenia, czy wartość jest różna od null przy zachowaniu zasad pełnej obiektowości (polimorfizm, abstrakcja, enkapsulacja).

Pusty Obiekt (ang. Null Object) – jeden z czynnościowych wzorców projektowych (obiektowy), którego celem jest realizacja braku obiektu poprzez dostarczenie materialnej alternatywy, która oferuje domyślnie działanie puste, czyli niewykonujące żadnych operacji. W skrócie, jest to wzorzec w którym "z niczego nic się nie zdarzy"[1].

Po raz pierwszy został opublikowany w książce Pattern Languages of Program Design[2]. W książkach Martina Fowler'a Refactoring[3] i Joshua Kerievsky'ego Refactoring To Patterns[4] wzorzec ten uznawany jest jako Wzorzec refaktoryzacyjny .

Uzasadnienie użycia wzorca[edytuj | edytuj kod]

W większości języków zorientowanych obiektowo, takich jak Java lub C#, dopuszczalne jest, by referencje miały wartość pustą. Wywołanie metody na referencji pustej z reguły prowadzi do błędu, dlatego przed wywołaniem jakichkolwiek metod na referencji należy sprawdzić, czy nie ma ona pustej wartości. Aby wyeliminować powtarzanie testów wartości pustej wykorzystujemy wzorzec Pusty obiekt.

Zalety[edytuj | edytuj kod]

  • upraszcza kod programu, eliminując zbędne i powtarzające się instrukcje warunkowe,
  • stosuje klasy polimorficzne,
  • hermetyzuje puste zachowanie, poprzez metodę o pustym ciele,
  • umożliwia wielokrotne wykorzystanie pustego zachowania.

Wady[edytuj | edytuj kod]

  • sprawia, że puste zachowanie trudno rozpowszechnić wśród zachowań kilku obiektów współpracujących (silna hermetyzacja),
  • może powodować eksplozję (niepotrzebny rozrost) klasy,
  • może spowodować, że normalne wykonywanie programu potraktowane jest jako błąd.

Struktura[edytuj | edytuj kod]

Diagram klas wzorca Pusty Obiekt

Głównymi elementami w tym wzorcu są:

  • Client - klient stosuje realizację klasy abstrakcyjnej. Z punktu widzenie klienta nie ma znaczenia, czy realizacja jest obiektem pustym, czy rzeczywistym, ponieważ oba są stosowane w ten sam sposób.
  • AbstractObject - klasa abstrakcyjna, która może być realizowana przez klasę rzeczywistą lub pustą.
  • RealObject - rzeczywista realizacja klasy AbstractObject wykonująca konkretne działanie.
  • NullObject - realizacja klasy AbstractObject, w której nic nie jest wykonywane, w celu zapewnienia dostarczenia niepustego obiektu do klienta.

Przykłady[edytuj | edytuj kod]

Wzorce powiązane[edytuj | edytuj kod]

  • Pusty Obiekt jako Singleton. Klasa NullObject jest często implementowana jako Singleton[5] . Zwykle pusty obiekt nie ma żadnego stanu lub stanu nie można zmienić, więc w wielu przypadkach instancje są identyczne. Zamiast używania identycznych instancji w wielu przypadkach wystarczy, że system użyje jednej instancji wielokrotnie.
  • Pusty Obiekt jako szczególny przypadek wzorca Strategii[5]. Strategia określa kilka klas ConcreteStrategy jako różne podejścia do realizacji zadania. Jeśli jedno z tych podejść konsekwentnie nic nie wykonuje, to oznacza, że klasą ConcreteStrategy jest klasa NullObject.
  • Pusty Obiekt jako szczególny przypadek wzorca Stanu[5]. Jeśli konkretna klasa ConcreteState ze wzorca Stanu realizuje większość swoich metod jako puste (nic nie wykonują) lub przynajmniej zwracają pusty wynik, to wtedy taką klasę określamy jako pusty stan (ang. NullState).
  • Pusty Obiekt może być wykorzystany do umożliwienia wzorcowi Odwiedzający (ang. Visitor)[5] bezpiecznie odwiedzić hierarchię i obsłużyć puste sytuacje (obiekty).

Linki zewnętrzne[edytuj | edytuj kod]

Przypisy

  1. William Shakespeare: Król Lear.
  2. Bobby Woolf: Pattern Languages of Program Design 3. Addison-Wesley, 1998.
  3. Martin Fowler: Refactoring. Improving the Design of Existing Code. Addison-Wesley, 1999. ISBN 0-201-48567-2.
  4. Joshua Kerievsky: Refactoring To Patterns. Addison-Wesley, 2004. ISBN 0-321-21335-1.
  5. 5,0 5,1 5,2 5,3 Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.