Null object mi różnicy nie robi

Untitled

Brzydal

Każdy czegoś nie lubi, ja na przykład nie lubię gdy ktoś siada na moim krześle, a potem ja muszę na nim usiąść, fuj – takie ciepłe, zawsze chwilę odczekuje.
Albo NULL – to ciągłe sprawdzanie czy zmienna nie jest nullem, a potem jeszcze specjalna obsługa tu i tam i jeszcze tam, a potem tam i tam niosą, się ify po całym projekcie, albo wyjątki – BLEH

Sposób

Na szczęście na jedno i drugie jest sposób; każdemu mówię, że na moim krześle się nie siada i głośno warczę gdy ktoś łamię tę regułę, albo czekam aż wystygnie – przecież ich nie pogryzę.
Na drugie jest trochę lepszy sposób – null object pattern, “pusty obiekt” – kiedy już myślałem, że tego nie da się przetłumaczyć wiki mnie pokonała. No dobra, przeczytajcie sobie wiki a potem wróćcie tutaj.

Null Object Pattern – to taki wzorzec, który przypomina trochę emo nastolatka, gdy pytacie co chce na obiad, odpowie – #meh, to bez różnicy, bez sensu i trzaśnie drzwiami – coś powiedział, ale nic nie wiadomo. Albo taki kolega, którego zaprosiliście na imprezę, bo siedzi w pokoju, ale to czy przyjdzie czy nie przyjdzie i tak nie robi różnicy samej imprezie. Albo gdy ktoś podaje wam rękę na powitanie, a zamiast normalnego uścisku dłoni macie takiego śledzia w ręce – no dobra, tutaj lepiej byłoby w ogóle się nie witać 😉

Podsumowując NOP (bez złych skojarzeń proszę) to obiekt, który po zaaplikowaniu nie wprowadza żadnych zmian w systemie. Totalnie nic się nie stanie gdy dodasz NOPa do koszyka, pobierzesz faktury z NOPa, wprowadzisz poprawki z NOPa, etc.

NOP do kolekcji

Najprostszy NOP, który przychodzi mi do głowy to pusta kolekcja:
Taki przykład:

Niby wszystko spoko, ale ktoś wymyślił że w @5 możemy otrzymać NULL, bo nie będzie takich użytkowników, którzy pasują do wyszukiwania. Na szczęście wy (teraz już wiecie) ratujecie świat, bo na końcu (@6) sprawdzacie czy zwracacie null i jeśli tak, to hocus-pocus szybka zamiana na pustą kolekcje.
I teraz z taką kolekcją można działać, można po niej iterować, można z niej wyciągać dane, może na niej wykonywać projekcje danych (select), można wiele innych rzeczy i po pierwsze primo wszystkie one będą poprawne po drugie primo zwrócą one kolejne puste kolekcje. No dobra First oraz Single się wywalą.

Strategiczne podejście

Innym przykładem na NOP może być algorytm sortujący czy filtrujący.
Przkład:

W obu przypadkach (@3, @8) NOP nie robi nic, poza stworzeniem nowej listy na podstawie parametru i zwrócenia jej z taką samą zawartością i kolejnością jak oryginalna.

Nie wiem czy lubicie singletona, ale on świetnie współpracuje z NOPem. Idea jest taka, że fajnie jeśli w systemie jest tylko jeden NOP dla zadanego typu. Tylko jeden NOP-user, tylko jeden NOP-basket, … i teraz dzięki singletonowi nie trzeba ich ciągle tworzyć od nowa i nowa – taka mała oszczędność. Dodatkową zaletą jest to, że jeśli zechcecie porównać ze sobą takie dwa puste koszyki, czy dwóch pustych użytkowników to będą oni tacy sami. To będą te puste koszyki, ci puści użytkownicy (niepoprawnie polityczny humor się włącza)

Domyślny NOP

NOP wcale nie musi być skomplikowany, wystarczy chwilę pomyśleć aby klasa zachowywała się jak NOP. Tak nowy tworzony obiekt będzie zachowywać się jak NOP:

Domyślnie tworzy się obiekt, który jest w pełni sprawny i można na nim wykonywać dowolne operacje, ale tak z pudełka nie posiada on żadnych rzeczy (@8), a cena to zero (@9). W taki przypadku taki koszyk można przypisać do każdego użytkownika systemu, bez strachu że zmieni to ich stan, albo że nagle będą musieli oni za coś płacić. Fajnie jeśli tak tworzycie swoje klasy, że od początku są one w pełni zainicjalizowanym obiektem, a jednocześnie nic nie wnoszącym do systemu – NOPem.

Netto

Jaki jest z tego profit? Jeśli dobrze rozegracie akcję z NOPem to wszędzie w waszym kodzie możecie pomijać sprawdzanie czy parametr jest nullem. Wszędzie bezpiecznie możecie korzystać z argumentów przekazywanych do metody, jak i tych zwracanych z metody. To w dużym stopniu przekłada się na zmniejszenie ilości występowania ifów w kodzie, a to przekłada się na mniejszą ilość testów które trzeba napisać – mniej rozgałęzień w kodzie.
NOP – to nie tylko wzorzec projektowy, ale podobnie jak kraj na wschód od nas, duży, gdzie nazwa zaczyna się od RO, ma literki SJ, a kończy się pierwszą literą naszego alfabetu – to stan umysłu.

Ja namiętnie korzystam z NOPa w swoim projekcie, źródła dostępne pod adresem: https://github.com/jstadnicki/isthereanynews w razie wątpliwości, czy pytań chętnie pogadam.

6 thoughts on “Null object mi różnicy nie robi

  1. Odnośnie ‘NOP do kolekcji’, to jest jeszcze takie ładne:

    private IEnumerable<User> GetUsers()
    {
    return Enumerable.Empty<User>();
    }

  2. Pingback: dotnetomaniak.pl
  3. Słaby ten artykuł 🙂 Null object patternu to na pewno nie wytłumaczyłeś. Tych rozlazłych zamysłów o singletonach żeś nie wytłumaczył.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.