BLOG

W wielu opracowaniach o podstawach programowania obiektowego można przeczytać, iż obiektowość ma w pewnym stopniu naśladować świat rzeczywisty. Zasada, którą poznamy w tym wpisie, nauczy nas jak ograniczyć zależności pomiędzy klasami. Przekonamy się, że niezależność jest pożądaną cechą zarówno w świecie rzeczywistym, jak i tym programistycznym.
Wyobraźmy sobie taką sytuację – kupujemy w sklepie produkt, który potrzebujemy. Niestety trafiamy na sprzedawcę, speca od „marketingu”, który w przypływie szczodrości obdarowuje nas dodatkowo katalogiem wszystkich produktów firmy, próbkami innych produktów, brelokiem z logo firmy i masą innych niepotrzebnych nam rzeczy. Dzisiejszy wpis pokaże nam w jaki sposób radzić sobie z niepotrzebnymi rzeczami w programistycznym świecie.
W tym wpisie porozmawiamy o dziedziczeniu. Jeżeli dana metoda przyjmuje jako argument obiekt pewnej klasy bazowej, zachowuje się ona w pewien oczekiwany przez nas sposób. Załóżmy teraz że obiekt klasy, która dziedziczy po klasie bazowej, zostanie przesłany do tej metody. Co wtedy się stanie? Odpowiedź: działanie metody się nie zmieni. A przynajmniej nie powinno.
Stworzenie działającej aplikacji nie oznacza zakończenia prac nad projektem. Czasem wpadamy na nowe pomysły jak ulepszyć aplikację czy też dodać do niej dodatkowe funkcjonalności. Jednak zdarza się, iż po dodaniu czegoś nowego, przestaje nam działać coś innego. Dzieje się tak, gdyż dodając nowe funkcjonalności jesteśmy zmuszeni modyfikować dotychczas napisany kod. W tym artykule przedstawię zasadę, która pomoże rozwiązać ten problem.
„Jak coś jest do wszystkiego, to jest do niczego” – chyba każdy zna to popularne powiedzenie. I myślę, że większość z nas przekłada tę myśl na życie codzienne – lubimy korzystać z przedmiotów, które mają tylko jedno zastosowanie, ale wykonują dobrze to, czego od nich oczekujemy. Nie inaczej jest z programowaniem, gdyż można powiedzieć, iż „klasa, która jest do wszystkiego, jest do niczego”.
Zazwyczaj proces pisania programów wygląda następująco: najpierw wprowadzamy nową funkcjonalność, a następnie piszemy testy jednostkowe. Takie podejście wydaje się oczywiste i naturalne. Jednak istnieje również inne podejście, odwracające kolejność postępowania – jest nim właśnie Test Driven Development.
W drugim artykule o testach jednostkowych przedstawię szczególne obiekty wykorzystywane w testach, zwane atrapami. Opiszę czym są i do czego służą Stub, Mock i Spy. Przedstawię także dobre praktyki związane z pisaniem testów jednostkowych, a także pokrótce napiszę czego się wystrzegać przy pisaniu testów.
Każdy programista w czasie pracy nieraz natrafi na błędy w swoich projektach. Im program bardziej rozbudowany, tym trudniej będzie te błędy wychwycić. Ich poszukiwanie jest niezwykle żmudnym i frustrującym zajęciem, nierzadko zniechęcającym do dalszej pracy. I o ile całkowite wyeliminowanie popełniania błędów jest niemożliwe (w końcu jesteśmy tylko ludźmi), to możemy skutecznie poprawić wykrywalność popełnianych przez nas błędów.
Wydawać by się mogło, że tworzenie nowych obiektów to nic trudnego – wystarczy użyć operatora „new”. Co zrobić w przypadku, gdy proces tworzenia obiektu przebiega w wielu etapach, a sam obiekt składa się z kilku mniejszych podobiektów? Odpowiedź brzmi: wykorzystać wzorce projektowe. A konkretnie – wzorzec Budowniczy.
Każdy programista czasem staje przed koniecznością skorzystania z kodu napisanego przez kogoś innego. Nierzadko zdarza się, że taki kod nie jest kompatybilny z naszym. W tym momencie rozpoczyna się żmudny proces modyfikacji kodu, aby poprawnie współpracował z naszym programem. Jest jednak lepsze rozwiązanie tego problemu – zastosowanie wzorca Adapter.
W pierwszym wpisie na moim blogu chcę rozpocząć krótką serię dotyczącą wybranych najważniejszych wzorców projektowych. Jako pierwszy na warsztat wziąłem wzorzec Strategia. Jest on niezbyt skomplikowany, a jego zastosowanie może znacznie poprawić czytelność pisanego kodu, co postaram się w niniejszym wpisie udowodnić.

Znajdź mnie również na:

arrow