Podobne wpisy:

1. Coś na weekend
2. Coś na weekend
3. Coś lekkiego na weekend
4. Coś lekkiego na weekend

Brak podobnych wpisów

S – Single Responsibility Principle (oraz cz. 2)

O – Open Close Principle (oraz cz. 2)

L – Liskov Substitution Principle

I – Inversion Segregation Principle

D – Dependency Inversion Principle

Słowo SOLID bardzo dobrze odzwierciedla to, do czego te zasady prowadzą czyli do budowania solidnego kodu. Przez solidny kod rozumiem taki, który jest łatwy w modyfikacji i który szybko można dostosować do zmieniających się wymagań. Nie są to jednak wszystkie zasady programowania obiektowego, które warto znać i stosować.

Na tapetę bierzemy zatem Reuse Release Equivalence Principle czyli zasadę, która mówi, że kod, który chcemy ponownie wykorzystać, powinien być w paczce, czarnej skrzynce, która jest dostarczalnym modułem czyli po ludzku biblioteką czy też assembly (w .necie).

A jeszcze bardziej po ludzku, zasada ta mówi po prostu, że ponownie użycie kodu to nie jest skopiowanie klasy z jednego projektu do drugiego. Jeżeli chcemy użyć ponownie raz napisany kod to należy go wydzielić do biblioteki czy modułu, który później możemy użyć ponownie.

Takie podejście powoduje, że gdy autor oryginalnego kodu wprowadzi zmianę – w szczególności poprawi jakiś błąd – wówczas możemy łatwo korzystać z dobrodziejstw takich zmian pobierając nową wersję biblioteki. W zespołach korzystających z automatyzacji (Continious Integration/Delivery) nawet nic nie trzeba robić – build server zrobi za nas wszystko.

To co powyżej napisałem może wydawać się oczywistą oczywistością jednak niestety nie jest. Jest wielu programistów (serio!), którzy “ponowne użycie kodu” rozumieją jako kopiowanie z jednego pliku do innego pliku. Dzięki czemu odcinają się od jakiejkolwiek możliwości rozsądnej aktualizacji kodu poza spisaniem na kartce wszystkich takich kopii i regularnie przeglądanie repozytorium w poszukiwaniu zmian – POWODZENIA

Zasada ta ma szczególne znaczenie w grupach, gdzie pracuje więcej niż jedna osoba lub gdy jedna osoba pracuje nad więcej niż jednym projektem – czyli praktycznie zawsze.

Jedyne ewentualne odstępstwo od tej zasady jakie widzę, to kopiowanie kodu, który jest podobny jednak logicznie posiadający inny kontekst.

Aby korzystać z dobrodziejstw zasady Reuse Release Equivalence Principle dobrze stosować się do wcześniejszych – tych z SOLID-a bo wyobraź sobie, że w metodzie CalculateInvoiceValue nagle ktoś zmieni obliczanie faktury na obliczanie różnicy pomiędzy dwiema datami.

Brak podobnych wpisów

Podobne wpisy:

1. Coś lekkiego na weekend
2. Coś na weekend
3. Coś na weekend
4. Coś lekkiego na sobotni poranek – Heineken vs damskie torebki
5. Jak zamienić małe litery na duże lub duże litery na małe w programie Word 2007 – uzupełnienie

public enum SomeEnum
{
    Dog,
    Cat,
    Lion
}

public class SomeAnimals
{
    public void Sounds(SomeAnimals animal)
    {
        switch (animal)
        {
            case SomeEnum.Cat :
                Console.WriteLine("Meow");
                break;
            case SomeEnum.Dog :
                Console.WriteLine("Wof");
                break;

               ...
         }
    }
}

Po dodaniu nowej wartości w SomeEnum wystarczy tylko…. poprawić wszystkie kawałki kodu, które wykorzystują SomeEnum – w głównej mierze trzeba przeglądnąć wszystkie switche i kaskady ifów. Zamiast stosować Open Close Principle i np. wzorzec Visitor z każdym kolejnym dodaniem do enuma miałem sporo pracy. Teraz coraz częściej dochodzę do wniosku, że enum mógł by nie istnieć. Wiele złego kodu by nie powstało. Czasem enum jest dobry jak w przypadku ustawiania klas do szyfrowania czy określania dostępu w FileStreamie ale pisząc kod częściej lepiej unikać ich niż z nich korzystać.

Brak podobnych wpisów

public double CalculateDiscount(IOrder order)
{

    if (order.Total >= 500 && order.Total < 1000)
    {
        return order.Total*0.05;
    }
    if (order.Total > 1000)
    {
        return order.Total*0.1;
    }

    if (order.Total > 5000)
    {
        order.SippingFee = 0;
        return order.Total*0.1;
    }

    return 0;
}

Napisane, przetestowane, zapłacone. Ale teraz klient (zleceniodawca/kierownik/project owner/właściciel tego sklepu) mówi, że chce dodać jeszcze jedną opcję: 30tego listopada darmowa przesyłka dla wszystkich (taki dzień darmowej dostawy). Nic trudnego dodamy trochę kodu:

public double CalculateDiscount(IOrder order)
{

    if (order.Total >= 500 && order.Total < 1000)
    {
        return order.Total*0.05;
    }
    if (order.Total > 1000)
    {
        return order.Total*0.1;
    }

    if (DateTime.UtcNow.Month == 11 && DateTime.UtcNow.Day == 30)
    {
        order.SippingFee = 0;
    }

    if (order.Total > 5000)
    {
        order.SippingFee = 0;
        return order.Total*0.1;
    }

    return 0;
}

I miesiąc później nasz klient chce mieć obsługę kuponów rabatowych:

...
if (order.HasCoupon && CouponIsValid(order.Coupon))
{
    return order.Total*order.Coupon.Discount;
}
...

Kolejny miesiąc i kolejny pomysł – jakaś promocja w zakupach grupowych:

// miejmy nadzieję że wcześniejszy kod pozwoli korzystać z wielu różnych kuponów

…. widać w jakim kierunku to idzie. Kod rośnie szybciej niż ciasto drożdżowe na kaloryferze i równie szybko co ryba na kaloryferze zaczyna pachnieć.

Na takie bolączki przychodzi Open Close Principle. Zamiast małymi kroczkami psuć kod i z każdą iteracją zwiększać złożoność przypadkową , czyli tą złą, możemy zastosować Open Close Principle, która mówi: Klasa powinna być zamknięta na modyfikacje ale jednocześnie otwarta na rozszerzanie.

A gdyby tak nasza metoda wyglądała mniej więcej tak ?

public double CalculateDiscount(IOrder order)
{
    var discounts = GetAllAvaliableDiscountsInPropperOrder();

    foreach (var discount in discounts)
    {
        discount.Recalculate(order);
    }

    return order.Discount;
}

Taki kod jak powyżej jest zamknięty na modyfikacje ale otwarty na rozszerzanie. Dodawanie kolejnego sposobu obliczania zniżki nie wymaga modyfikowania powyższego kodu. Co więcej, możemy zniżki ładować dynamicznie np. za pomocą MEF-a a przez to w zależności od klienta dystrybuować aplikacje z różnymi modelami obliczania zniżki – bez rekompilacji czy dziwnych, skomplikowanych konfiguratoró. Prawie pewne jest, że po 5-10 klientach zbuduje nam się pokaźna biblioteka wymysłów pomysłów, która zaspokoi 90% potrzeb przyszłych klientów.  Czyż nie jest to piękne? Każdy kolejny klient nie kosztuje nas praktycznie nic.

Brak podobnych wpisów

Źródło: http://twitter.com/venkat_s/status/198771575573585920

Krytykowanie jest łatwe bo nie wymaga wiedzy i nie wymaga takiego wysiłku jak przy tworzeniu.

Brak podobnych wpisów

Interface Segregation Principle mówi, że klient nie powinien być zmuszany do implementowania interfejsów, których nie używa. Z tego wynika, że interfejs powinien być minimalistyczny lub po prostu możliwie chudy. Idealnie by było, gdyby miał jedną metodę a poważnie, można by tutaj parafrazować Single Responsibility Principle i powiedzieć, że interfejs powinien definiować jedną czynność (logiczną czynność – nie metodę/funkcję).

Dlaczego to jest ważne? Dlaczego wielkie grube interfejsy są nie fajne? Dlatego, że ktoś kto będzie musiał zaimplementować wielki barokowy interfejs najprawdopodobniej większość metod pozostawi pustych (lub z NotImplementedException) a zaimplementuje te, które są dla niego niezbędne. To znowu może prowadzić do dziwnych wyjątków i dziwnego działania aplikacji, jeśli taki “niedoimplementowany” obiekt zostanie ponownie użyty w innym miejscu. Wszak przy dużych systemach nikt nie czyta całego kodu każdego obiektu tylko go używa mając nadzieję, że jego nazwa i metody rzeczywiście robią to na co wskazują. Zatem nie wprowadzajmy siebie i innych w błąd i nie utrudniajmy sobie życia, twórzmy małe chude interfejsy, które reprezentują jedną spójną i logiczną czynność.

Podobne wpisy:

1. Single Responsibility Principle
2. Kwadrat jest prostokątem czyli Liskov Substitution Principle (LSP)
3. Dependency Inversion Principle – czyli co powinno zależeć od czego
4. Single Responsibility Principle – ciąg dalszy
5. Architektura czyli jedna z najbardziej niedocenianych umiejętności

Podobne wpisy:

1. Coś na weekend
2. Coś lekkiego na weekend

Prostokąt:

        public class Rectangle
        {
            internal double _width;
            internal double _height;

            public double Width
            {
                get { return _width; }
                set { _width = value; }
            }

            public double Height
            {
                get { return _height; }
                set { _height = value; }
            }
        }

i kwadrat dziedziczący z prostokąta (wszak każdy kwadrat jest prostokątem):

        public class Square : Rectangle
        {
            public new double Width
            {
                get { return _width; }
                set
                {
                    _width = value;
                    _height = value;
                }
            }
        }

Za pomocą operatora new nadpisaliśmy property Width tak aby pasowała do naszej teorii. Wszystko ładnie i pięknie – należało by jeszcze tak samo potraktować Height i już jest pięknie….

Barbara Liskov mówi, że nie. Powyższy kod jest książkowym przykładem na złamanie zasady podstawiania – Liskov Substitution Principle (LSP). Zasada ta mówi, że funkcje, które używają referencji do klas bazowych, muszą być wstanie użyć również klas dziedziczących z klasy bazowej bez dokładnej znajomości tych obiektów. Po ludzku oznacza to tyle, że funkcja powinna działać przewidywalnie bez względu na to czy jako parametr przekażemy klasę bazową czy też klasę, która po niej dziedziczy.

Dlaczego to jest ważne? Co zrobi poniższy kod?

Rectangle rectangle = new Square();

rectangle.Width = 10;

Ustawiając szerokość spodziewałbym się, że wysokość również będzie 10 (w końcu mamy new Square()) ale nie…

Złamanie zasady LSP powoduje, że pośród innych powodujemy sporo trudnych do znalezienia błędów. Jeżeli chcemy pracować szybko i wygodnie to niestety lepiej nie łamać tej zasady a kwadraty i prostokąty nie powinny dziedziczyć z siebie a z bardziej ogólnego typu np.: kształt.

Podobne wpisy:

1. Dependency Inversion Principle – czyli co powinno zależeć od czego
2. Single Responsibility Principle – ciąg dalszy
3. Single Responsibility Principle
4. Koncepcja elastycznej architektury
5. Architektura czyli jedna z najbardziej niedocenianych umiejętności

    public class MyGreatApplication
    {
        public IAbout About()
        {
            // zwraca informacje na temat aplikacji
        }

        public void LoadData(IApplicationData applicationData)
        {
            // wczytanie danych aplikacji
        }

        public ICalculatedTax CalculateTax(IDataToCalculateFrom inputData)
        {
            // obliczenie podatku
        }

    }

Plus takiego podejścia to możliwość wymiany sposobu przechowywania danych na dowolne inne w bardzo krótkim czasie. Wzorzec IRepository ułatwi zbudowanie czegoś, co będzie działało jako wewnętrzne źródło danych, to co znajduje się po drugiej stronie nie ma już znaczenia dla samej aplikacji. Również sposób komunikacji ze światem nie ma zupełnie znaczenia. Najbardziej podstawowym mogą być testy jednostkowe. Może to być również aplikacja okienkowa np. WPF w połączeniu z MVVM lub ASP.NET MVC. Tak długo jak aplikacja będzie czysta od sposobu prezentacji oraz sposobu przechowywania danych, tak długo będziemy mogli elastycznie nimi żonglować.

Podstawową wartością biznesową jest nasza aplikacja. To tutaj jest miejsce na logikę biznesową i na umieszczenie wszystkiego tego co chcemy aby aplikacja robiła. To jak dostarczymy tą aplikację użytkownikowi jest sprawą wtórną – dostarczymy w sensie jak użytkownik będzie konsumował nasz produkt.

Zwróć uwagę, że kilka lat temu większość aplikacji była dostępna w formie aplikacji okienkowej i taka forma konsumpcji była dobra dla większości użytkowników (wcześniej była to jedyna forma). Później pojawiło się coś co się nazywa “aplikacja webowa” (to dlaczego pojawiły się tutaj ząbki opiszę kiedyś w osobnej notce) a obecnie instalowana dedykowana aplikacja wraca do łask i ponownie zyskuje na popularności tyle tylko, że w formie aplikacji na platformy mobilne (iOS, Android, WP7). Wyobrażasz sobie koszty stworzenia aplikacji prawie od nowa przy pojawieniu się nowej technologii?

Proponowane wyżej podejście do budowania aplikacji pozwala bardzo niskim kosztem stworzyć nowy mechanizm konsumpcji naszej aplikacji – nawet co kilka miesięcy. Tak jak pisałem już wcześniej, bardzo niskim kosztem możemy zbudować na tym samym rdzeniu zarówno usługę sieciową jak i WPF-a, WP7 i formsy i Silverlighta – a może potrzebny jest gadget do Visty lub Windows 7? Za kilka miesięcy wyjdzie Windows 8 więc może warto zastanowić się nad wykorzystaniem nowych możliwości. Widzisz przewagę konkurencyjną? Zamiast przepisywać część aplikacji aby użyć nowej technologii i najzwyczajniej w świecie gonić konkurentów można zaoszczędzić czas inteligentnie budując kod.

Mam nadzieję, że zainspirowałem Cię wystarczająco aby zmienić ciągle niestety najpopularniejszy sposób pisania aplikacji.

Podobne wpisy:

1. Architektura czyli jedna z najbardziej niedocenianych umiejętności
2. Single Responsibility Principle – ciąg dalszy
3. Single Responsibility Principle
4. Konkurs „Daj się poznać” – podsumowanie
5. Lekcja języka polskiego w programowaniu

Jak wyglądają pierwsze kroki w programowaniu? Po opanowaniu pętli for i foreach, ifów i caseów, Console.WriteLineów oraz tych wszystkich klas i obiektów i nie zapominając o polimofizmach wielu rzuca się w wir poznawania meandrów standardowo dostępnych bibliotek a potem przychodzi czas na biblioteki zewnętrzne.

Idylla trwa do czasu…

… kiedy coś trzeba zmienić a to coś to integralna część naszego Dzieła. Wtedy często okazuje się, że całość sypie się niczym domek z kart.

Dobra architektura to taka, która pozwala na przesunięcie decyzji biznesowych w czasie*

No właśnie. Dobra architektura pozwala na przesunięcie decyzji biznesowych w czasie, w dodatku możliwie jak najdłużej. A co rozumiem przez decyzje biznesowe tutaj? Są to decyzje typu czy używamy takiej czy innej bazy danych – a może nie użyjemy bazy danych. Czy użyjemy tej czy innej biblioteki do logowania. Czy nasza aplikacja ma byś dostępna przez www czy jako aplikacja desktopowa. Tego typu decyzji trzeba podejmować bardzo dużo w czasie tworzenia aplikacji, architektura, która pozwoli odwlec tą decyzję w czasie to dobra architektura.

Ale dlaczego odwlekanie w czasie jest dobre?

Odwlekanie w czasie jest dobre ponieważ wiele aplikacji, szczególnie tych dużych buduje się bardzo długo. Może się okazać, że np. biblioteka prezentacji danych, której używamy na początku pod koniec budowania aplikacji nie będzie już modna nie będzie już rozwijana. Nie znaczy oczywiście, że należy tworzyć aplikacje zupełnie bez bazy danych, bez logowania, bez interfejsu – znaczy to tyle, że należy tworzyć aplikację tak, aby te elementy były łatwo wymienialne.

Rober C. Martin, na którego się często powołuję i który jest moją inspiracją między innymi również do tego cyklu, popełnił (pośród wielu) aplikację FitNesse. Podczas jej tworzenia stwierdzili, że ponieważ jest to projekt webowy to muszą użyć MySql-a. Jednak zamiast natychmiast implementować na hura zapisywanie danych w MySql-u na początek stworzyli zapisywanie danych w formie tablicy haszującej zapisywanej do plików (w dużym uproszczeniu). Implementacja zapisu do bazy danych miało nastąpić później. Jednak z czasem okazało się, że zapis do bazy danych jest niepotrzebny a zapis do plików w zupełności wystarcza.

Co więcej, pojawił się po jakimś czasie człowiek, który potrzebował zapisu do bazy danych i architektura jaką stworzyli była tak elastyczna, że stworzenie kodu do zapisu do bazy danych wymagało jedynie jednego dnia pracy. Wyobraźcie sobie, że Wasze aplikacje można przepisać na inną bazę w jeden dzień… dla wielu, którzy nie zwracali uwagi na architekturę odpowiednio wcześnie dzisiaj nie mogą tego zrobić. Dodanie wsparcia dla nowej bazy wymaga u “Nich” dość często przepisanie całej aplikacji. Nie idźmy tą drogą. Coraz częściej klienci chcą aby aplikacją współpracowała z inną bazą niż tą z której my korzystamy (powodów mogą być dziesiątki). I choć baza danych nie jest tu wyjątkiem to jest to chyba jedno z częstszych ograniczeń  z jakim muszą walczyć programiści.

*) podobnej treści tekst powiedział Robert C. Martin, niestety nie pamiętam dosłownego brzmienia – jednak to On jest inspiracją.

Podobne wpisy:

1. Architektura aplikacji w sposób łatwy i przyjemny
2. Single Responsibility Principle
3. Dependency Inversion Principle – czyli co powinno zależeć od czego
4. Single Responsibility Principle – ciąg dalszy
5. Lekcja języka polskiego w programowaniu

private Person _owner;

public bool ValidateOwner(Person personToValidate)
{
//.....
}

piszemy

private IPerson _owner;

public bool ValidateOwner(IPerson personToValidate)
{

//.....

}

Co to daje? Ano daje to możliwość podmieniania poszczególnych elementów programu. Powyższy przykład nie jest zależny już od klasy Person a od interfejsu IPerson. To jaki obiekt będziemy validować, nas zupełnie nie obchodzi. Ważne, żeby implementował nasz interfejs.

Co więcej, powyższe podejście pozwala na łatwe wyciągnięcie jakiejś klasy do osobnej biblioteki i użycie jej w innym projekcie. Jeżeli nie stosowalibyśmy Dependency Inversion Principle, wówczas wyciągnięcie klasy do zewnętrznej biblioteki wymagało by wyciągnięcia również wszystkich użytych przez nas klas albo byli byśmy zmuszeni ciągnąć za sobą masę referencji. DIP ułatwia wyciągnięcie klasy i interfejsów, które nas interesują. Zazwyczaj już nie potrzebujemy żadnych dodatkowych referencji.

Pamiętając, że chcemy pracować wydajniej i lepiej to czy nie było by pięknie, gdyby jakąkolwiek funkcjonalność, logikę biznesową czy algorytm pisalibyśmy tylko raz? Jak wydajna byłaby organizacja gdyby każdy taki pojedynczy klocek powstawał tylko i wyłącznie raz? Okazuje się, że bardzo. Okazuje się, że tak pracujące zespoły mogą bardzo szybko i co najważniejsze niskim kosztem potrafią w szybkim tempie dostarczyć nowe wersje czy nawet nowe produkty w mgnieniu oka. Elastyczna architektura pozwala na taką pracę. To co daje .net pozwala z jednego kodu bazowego zrobić usługę w WCF-ie, aplikację konsolową, bardzo bogatą graficznie aplikację w WPF-ie, albo klasyczną Formsową, można szybko dostarczyć stronę www w MVC, aplikację na telefon (WP7) czy nawet w formie gry na XBox-a. To wszystko jest możliwe z jednego kodu bazowego przy odpowiedniej architekturze. .NET nie jest tutaj wyjątkiem. Podobne możliwości daje prawie każdy nowoczesny język programowania. W Javie mamy możliwość tworzenia apletów na strony www, aplikacji również graficznie bogatych, usługi, telefony, telewizory i wiele innych.

Podobne wpisy:

1. Single Responsibility Principle
2. Single Responsibility Principle – ciąg dalszy

Brak podobnych wpisów

Jak to? Nie mogę używać słowa kluczowego new? Nie mogę tworzyć obiektów?

No właściwie to nie. Jeżeli chcesz w klasie tworzyć obiekty to to już jest odpowiedzialność. Wiec klasa nic poza tworzeniem obiektów nie powinna robić. Ale przecież klasa która nie robi nic poza tworzeniem obiektów to fabryka. Wszystko jak najbardziej się zgadza. Fabryka – wzorzec kreacyjny (hm… a może znacie jakieś bardziej odpowiednie słowo) gangu czterech.

Wydaje Ci się trochę za dużo pisania w porównaniu do starego sposobu? No cóż, na początek (i bez wprawy) pewnie tak ale popatrzmy po co to robić, co to nam da i dlaczego pozwoli pisać lepsze programy.

Wczorajszy przykład z zapisywaniem obiektu mógł by wyglądać tak:

            private readonly IFactory _factory;

            public Employee(IFactory factory)
            {

                _factory = factory;

            }

            public void Save()
            {

                var persistingObject = _factory.PersistingObject();

                persistingObject.Save(this);

            }

Klasa pracownik już nie musi implememntować metod do zapisywania – ma od tego „ludzi”

            public interface ISomeInterfaceToSaveObject
            {
                void Save(IEmployee employee);
            }

            public interface IFactory
            {
                ISomeInterfaceToSaveObject  PersistingObject();
            }

            public class SaveToXml : ISomeInterfaceToSaveObject
            {
                public void Save(IEmployee employee)
                {
                    //zapis do xml-a
                }
            }

            public class SaveToTextFile : ISomeInterfaceToSaveObject
            {
                public void Save(IEmployee employee)
                {
                    // zapis do pliku tekstowego
                }
            }

            public class SaveToMsSql : ISomeInterfaceToSaveObject
            {
                public void Save(IEmployee employee)
                {
                    // zapisz do sql-a
                }
            }

Pozostaje napisać fabrykę, która zwraca odpowiedną klasę – zapisującą czy to do sql-a czy pliku tekstowego czy innego.

a tak może wyglądać użycie powyższego cuda.

            IEmplyee someEmployee = GetEmployeeFromSomewhere;

            someEmployee.Save();

Plusem takiego rozwiązania jest to, że możemy praktycznie w locie podmieniać kod odpowiedzialny za zapisywanie. Bez względu gdzie i jak chcemy zapisywać, klasa Pracownik nie zmienia się. Co więcej klasa ta nawet nie posiada świadomości gdzie i jak zapisywać – nie ma takiej potrzeby.

Jest też druga strona medalu, klasy do zapisywania możemy łatwo wykorzystać czy to w innym miejscu aplikacji lub nawet w innej aplikacji. To znowu skutkuje, że raz dobrze napisany kawałek kodu może być użyty wielokrotnie. Jeśli znowu nie stosujemy się do SRP to próbując wykorzystać kod w innym miejscu musimy ciągnąć całkiem sporo referencji i zbędnego kodu ze sobą.

Jest jeszcze jeden plus korzystania z SRP. Jeżeli np. zapis danych do bazy danych mamy w osobnej klasie, to co stoi na przeszkodzie aby napisać nową wersję korzystającą z innej bazy? Zamiast MS SQL-a Oracle-a albo MySql-a zamiast Oracle-a a może cos z NoSql. SRP ułatwi nam takie zadanie i nawet jeśli nie potrzebujemy takiej możliwości dzisiaj to jaką mamy pewność, że za miesiąc lub za rok jakiś klient lub nie będzie chciał (lub potrzebował) aby nasza aplikacja działała na innej bazie danych?

No i ostatni argument, jeżeli dodamy do konstruktora jakiś parametr to w przypadku korzystania z fabryki mamy jedno (słownie JEDNO) miejsce do poprawy – fabryka. Jeśli natomiast używamy operatora new to tu, to tam, wówczas po dodaniu parametru do konstruktora otrzymujemy kilkadziesiąt lub nawet kilkaset miejsc gdzie ten parametr należy dopisać. Niestety najczęściej kończy się to tak, że w wielu miejscach zamiast parametru wpisujemy null, a potem w metodach, które się sypią pojawia się warunek if(….. != null) i tak literka za literką i linijka za linijką kod zaczyna zmieniać się w potwora.

Potwór ten powoli spowalnia nas (jak na krzywej z wpisu Podstawy programowania) aby na końcu urwać dupę  zmusić do rozpoczęcia pracy od początku.

Podobne wpisy:

1. Single Responsibility Principle
2. Pobieranie Windows 7 – ciąg dalszy…
3. MacBook Air – Nie dziękuję… historii ciąg dalszy
4. Nikon D7000 czyli następca Nikona D90 – historii ciąg dalszy
5. Lekcja języka polskiego w programowaniu