Witam,
dziś chciałem napisać kilka słów o książce Clean Code - Robert C. Martin. Nie będę się rozpisywał o książce, należy ją po prostu przeczytać.
Książkę podzielił bym z ważywszy na doświadczenie czytelnika w programowaniu. Osoby które to programują poniżej 1,5 roku lub bawią się tylko w programowaniem, niech potraktują książkę jako pozycje obowiązkową. Osoby programujące zawodowo mogły się spotkać z większością zagadnień w pracy codziennej.
Może nieskromnie, ale pozwolę sobie zaliczyć się do 2 grupy i większość zagadnień była mi znana ale czytanie książki to tylko przyjemność i bardzo fajnie było sobie odświeżyć informacje, poznawać nowe elementy pożądanego programowania i uporządkować zamglone elementy wiedzy.
Niektóre problemy dokuczają tylko pracującym w dużych projektach(30 > osób), dlatego też niektóre elementy przez osoby nie pracujące w takich projektach mogą zostać niedocenione.
Pokazywanie postów oznaczonych etykietą wzorce. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą wzorce. Pokaż wszystkie posty
poniedziałek, grudnia 13
sobota, sierpnia 28
Chain of Responsibility
 |
Purpose:
Gdy potrzebujemy by request mógł być obsłużony przez kilku odbiorców(handler). Odbiorcy są połączeniu ze sobą i przekazują wzajemnie między sobą wynik obsłużenia.
Use:
- wiele obiektów może obsłużyć żądanie, nie jest zdeterminowane jaki obiekt będzie wstanie obsłużyć żądanie,
- kilka obiektów może obsłużyć żądanie, obiekty obsługujące są determinowane w czasie wykonania (runtime),
- jest do przyjęcia to, że żądanie nie zostanie obsłużone przez żaden obiekt.
Not Use:
- każde żądanie obsługiwane jest tylko przez jedne obiekt,
- gdy klient wie jaki serwis obsługuje jakie żądanie.
Example
Wzorzec ten realizowany jest przez obsługę wyjątków w niektórych językach. Gdy pojawia się wyjątek w metodzie, najpierw sprawdzane jest czy dana metoda posiada mechanizm obsługi, jeżeli dana metoda nie posiada mechanizmu obsługi wyjątek przekazywany jest do kolejnej metody na stosie. Przekazywanie kontynuowane jest do momentu napotkania metody potrafiącej obsłużyć wyjątek lub do skończenia się wywołań na stosie.
Resource:
- java.dzone.com/articles/design-patterns-uncovered-chain-of-responsibility
- en.wikipedia.org/wiki/Chain-of-responsibility_pattern
- javaworld.com/javaworld/jw-08-2003/jw-0829-designpatterns.html
- aragorn.pb.bialystok.pl/~tabedzki/dp/Chain_of_Responsibility.html
- c2.com/cgi/wiki?ChainOfResponsibilityPattern
wtorek, sierpnia 24
Gang of Four
Witam,
po pracowitym okresie nauki do SCJP i zdaniu egzaminu,
 |
Creational Patterns, używane do tworzenia instancji w taki sposób by w jak największym stopniu ukryć logikę i skomplikowanie procesu tworzenia.
- Abstract Factory - pozwala na zgrupowanie fabryk działających w tej samej domenie,
- Builder - oddziela budowanie obiektu od prezentacji, ma za zadanie ukryć skomplikowany proces budowania,
- Factory Method - budowanie złożonego obiektu bez dokładnego wyspecyfikowania drzewa zwróconych obiektów,
- Prototype - tworzenie nowej instancji klasy na podstawie już istniejącej instancji,
- Singleton - ma za zadanie zbudowanie tylko jednej instancji klasy. Niektóre źródła podają ten wzorzec jako 'antywzorzec'.
Structural Patterns, skupione są na klasach i dużych strukturach obiektów. Poprzez wykorzystanie dziedziczenia i kompozycji pozwalają na utworzenie nowych funkcjonalności na podstawie już istniejących.
- Adapter - pozwalana na współpracę klas z niekompatybilnymi interfejsami,
- Bridge - bardzo mocne oddzielenie(low coupling) formy abstrakcyjnej klasy od implementacji, co pozwala je traktować niezależnie,
- Composite - zebranie kilku obiektów w jeden, pozwala to na manipulowanie obiektami jak by były jednym obiektem,
- Decorator - dynamicznie dodaje/nadpisuje zachowanie metod w obiektach,
- Facade - udostępnia uproszczoną formę dużej ilości złożonego kodu,
- Flyweight - zmniejsza koszt tworzenia i manipulowania dużą liczbą podobnych obiektów,
- Proxy - zastępnik dla innego obiektu, ma za zadanie kontrolować dostęp, zredukować koszt użycia.
Behavioral Patterns, mają za zadanie uprościć komunikację, dzielenie się obowiązkami pomiędzy obiektami.
- Chain of Responsibility - deleguje polecenia do łańcucha przetwarzania,
- Command - tworzy obiekt enkapsulujący działanie i parametry,
- Interpreter - interpretuje nasz wewnętrzny język (nasz mały DSL),
- Iterator - sekwencyjny dostęp do obiektów bez zdradzania wewnętrznej implementacji,
- Mediator - pozwala na luźne powiązanie klas, gdzie tylko mediator posiada informację o budowie obiektów. Klasy wzajemnie nie posiadają informacji o swoich metodach,
- Memento - umożliwia zawsze przywrócenie obiektu do stanu z przed zmiany, operacja(undo),
- Observer - wzorzec publish/subscribe pozwala dużej liczbie obserwatorów(observers) zobaczyć zdarzenia,
- State - pozwala na zmianę zachowania obiektu, gdy jego stan ulegnie zmianie,
- Strategy - pozwala na wybieranie algorytmu ze zbioru podczas runtime'u,
- Template Method - definiuje szkielet algorytmu jako klasę abstrakcyjną, konkretne implementacje precyzują poszczególne zachowania,
- Visitor - wydzielenie algorytmu ze struktury na której pracuje.
Polecam też kilka anglojęzycznych katalogów wzorców:
wtorek, maja 4
The Differences Between Good Designers and Great Designers
Witam;
Zajęty pracą, oraz sprawami dnia codziennego nie mam czasu na nic twórczego(poza pracą ;p), ale dzisiaj w południe było mi dane przeczytać bardzo dobry wpis na stronie www.drawar.com. Wpis był interpretacją prezentacji 9 skills that separate good designers zrobioną przez Cameron Moll.
Prezentacja nie miała za wiele wspólnego z java, ale bez większych problemów można ją przenieść na nasze podwórko.
Pozdrawiam,
Arkadiusz Borek
ps. Ze strony prezentacje pobierzcie ją w wersji pdf, mnie design tej prezentacji bardzo zaciekawił.
Zajęty pracą, oraz sprawami dnia codziennego nie mam czasu na nic twórczego(poza pracą ;p), ale dzisiaj w południe było mi dane przeczytać bardzo dobry wpis na stronie www.drawar.com. Wpis był interpretacją prezentacji 9 skills that separate good designers zrobioną przez Cameron Moll.
Prezentacja nie miała za wiele wspólnego z java, ale bez większych problemów można ją przenieść na nasze podwórko.
Pozdrawiam,
Arkadiusz Borek
ps. Ze strony prezentacje pobierzcie ją w wersji pdf, mnie design tej prezentacji bardzo zaciekawił.
niedziela, kwietnia 18
Spoon
Witam;
By pewne rzeczy jakie przychodzi nam robić w każdym naszym projekcie stały się przyjemne pojawiała się nowa biblioteka opj4, o samej bibliotece było już wspominane na polskich portalach, uczynił to np. Sławek Sobódtka na swoim blogu. Wspominam o niej ponieważ pojawił się op4j 1.0 RELEASE. Biblioteka rozwiązuje podstawowe problemy w bardzo prosty i przystępny sposób, dlatego też nie inaczej jest napisana do niej dokumentacja, powstaje ona formie bloga.
Życzę wszystkim miłej zabawy.
ps. Przy pierwszym zetknięciu naprawdę zadziwia podejście autorów do problemu.
By pewne rzeczy jakie przychodzi nam robić w każdym naszym projekcie stały się przyjemne pojawiała się nowa biblioteka opj4, o samej bibliotece było już wspominane na polskich portalach, uczynił to np. Sławek Sobódtka na swoim blogu. Wspominam o niej ponieważ pojawił się op4j 1.0 RELEASE. Biblioteka rozwiązuje podstawowe problemy w bardzo prosty i przystępny sposób, dlatego też nie inaczej jest napisana do niej dokumentacja, powstaje ona formie bloga.
Życzę wszystkim miłej zabawy.
ps. Przy pierwszym zetknięciu naprawdę zadziwia podejście autorów do problemu.
poniedziałek, stycznia 25
KISS
Inżynierowie są perfekcjonistami. Interesują nas zawsze szczegóły rozwiązania, oraz schludność. Opracowując rozwiązanie musimy być pewni, że coś działa tak jak powinno. Często bywa tak, że posiadamy gotowe rozwiązanie, ale cały czas mamy niedosyt. Przecież każde rozwiązanie może być jeszcze szybsze, ładniejsze, wydajniejsze.
Posiadamy duża wiedzę która to umożliwi zoptymalizowanie naszego rozwiązania. Znamy np. wzorce programistyczne i umiemy je zaimplementować, przerabiamy nasza działając funkcjonalność zgodnie z wzorcem, przecież kiedyś może zostać rozszerzona, a nas wzorzec tak upraszcza proces rozszerzenia. Ale czy tak powinno być ??
Oprogramowanie jakie tworzymy ma spełniać wymagania klienta, jak często zdarza się nam zaimplementować jakieś wymaganie, ale przy okazji robimy pewne 'zbędę' rzeczy by nasze rozwiązanie było ładniejsze. Rozwiązywanie problemów prowadzi do poświęcenia 60% czasu implementacji wymagania biznesowego, a 40% zostaje zużytych zastosowania nowego wzorca, technologi.
Z pomocą przychodzi nam zasada KISS z wiki możemy się dowiedzieć, że:
KISS(ang. Keep It Simple, Stupid, czyli nie komplikuj, głupku) jest często wspominana przy dyskusji architektury lub szczegółów budowy projektów. Jej istotą jest dążenie do utrzymania eleganckiej i przejrzystej struktury, bez dodawania niepotrzebnych elementów. Doczekała się polskiego odpowiednika: BUZI (Bez Udziwnień Zapisu, Idioto), atrakcyjnego przez to, że nie tylko oddaje sens akronimu, ale i sam kojarzy się z angielskim pierwowzorem.
Spotyka się inne rozwinięcia KISS:
"Keep it Simple and Stupid" (to ma być proste i głupie),
"Keep It Small and Simple" (to ma być małe i proste),
"Keep It Short and Simple" (to ma być krótkie i proste),
"Keep It Sophisticatedly Simple" (upraszczaj, ale nie posuwaj się do prostactwa).
Chciałbym by zasada ta w oryginale prześwietlała nam zawsze, jak że to ułatwi późniejsze otrzymanie kodu.
ps. Albert Einstein miał swoją wersję zasady KISS: "Wszystko powinno być tak proste, jak to tylko możliwe, ale nie prostsze."
— (1879-1955)
Posiadamy duża wiedzę która to umożliwi zoptymalizowanie naszego rozwiązania. Znamy np. wzorce programistyczne i umiemy je zaimplementować, przerabiamy nasza działając funkcjonalność zgodnie z wzorcem, przecież kiedyś może zostać rozszerzona, a nas wzorzec tak upraszcza proces rozszerzenia. Ale czy tak powinno być ??
Oprogramowanie jakie tworzymy ma spełniać wymagania klienta, jak często zdarza się nam zaimplementować jakieś wymaganie, ale przy okazji robimy pewne 'zbędę' rzeczy by nasze rozwiązanie było ładniejsze. Rozwiązywanie problemów prowadzi do poświęcenia 60% czasu implementacji wymagania biznesowego, a 40% zostaje zużytych zastosowania nowego wzorca, technologi.
Z pomocą przychodzi nam zasada KISS z wiki możemy się dowiedzieć, że:
KISS(ang. Keep It Simple, Stupid, czyli nie komplikuj, głupku) jest często wspominana przy dyskusji architektury lub szczegółów budowy projektów. Jej istotą jest dążenie do utrzymania eleganckiej i przejrzystej struktury, bez dodawania niepotrzebnych elementów. Doczekała się polskiego odpowiednika: BUZI (Bez Udziwnień Zapisu, Idioto), atrakcyjnego przez to, że nie tylko oddaje sens akronimu, ale i sam kojarzy się z angielskim pierwowzorem.
Spotyka się inne rozwinięcia KISS:
"Keep it Simple and Stupid" (to ma być proste i głupie),
"Keep It Small and Simple" (to ma być małe i proste),
"Keep It Short and Simple" (to ma być krótkie i proste),
"Keep It Sophisticatedly Simple" (upraszczaj, ale nie posuwaj się do prostactwa).
Chciałbym by zasada ta w oryginale prześwietlała nam zawsze, jak że to ułatwi późniejsze otrzymanie kodu.
ps. Albert Einstein miał swoją wersję zasady KISS: "Wszystko powinno być tak proste, jak to tylko możliwe, ale nie prostsze."
— (1879-1955)
wtorek, października 20
java code convention
Witam
Podczas czytania książki SCJP for Java 6 zauważyłem, że dla Panów z Sun'a bardo ważnym jest by kod się kompilował, zapomnieli całkowicie o konwencji kodowania.
Pasjonaci kodowania często mówią, że kod ma wyglądać dobrze, ma się czytać dobrze, przy pierwszym spojrzeniu mówi do nas jakie są jego zadania. By kod tak wyglądał podczas kodowania stosujemy: metodyki, wzorce, standardy, ale często zapominamy o podstawach, czyli tytułowej konwencji kodowana. Konwencja dokumentuje podstawy związane z pisaniem kodu, takie jak: formatowanie kodu, organizacja plików, komentowanie, deklaracje, wyrażenia, .... Można by pomyśleć, że elementy tak podstawowe nie mogą wpłynąć na kod, ale jest całkiem inaczej, tak jak w życiu wszystko zaczyna się od podstaw.
Jako potwierdzenie mojej tezy, popełniłem małą klasę w PHP.
Przekornie klasę bez zmian użyję w kodzie.
Trudno sobie wyobrazić, że można w ten sposób zakodować klasę w javie, horror. Mam nadzieję, że chociaż jedną osobę przekonałem by wpisał w google frazę 'java code convention'.
Pozdrawiam i zapraszam do komentowania.
Podczas czytania książki SCJP for Java 6 zauważyłem, że dla Panów z Sun'a bardo ważnym jest by kod się kompilował, zapomnieli całkowicie o konwencji kodowania.
Pasjonaci kodowania często mówią, że kod ma wyglądać dobrze, ma się czytać dobrze, przy pierwszym spojrzeniu mówi do nas jakie są jego zadania. By kod tak wyglądał podczas kodowania stosujemy: metodyki, wzorce, standardy, ale często zapominamy o podstawach, czyli tytułowej konwencji kodowana. Konwencja dokumentuje podstawy związane z pisaniem kodu, takie jak: formatowanie kodu, organizacja plików, komentowanie, deklaracje, wyrażenia, .... Można by pomyśleć, że elementy tak podstawowe nie mogą wpłynąć na kod, ale jest całkiem inaczej, tak jak w życiu wszystko zaczyna się od podstaw.
Jako potwierdzenie mojej tezy, popełniłem małą klasę w PHP.
public class PHPInt {
private int $value = Integer.MIN_VALUE;
public static PHPInt __constructor(int $value) {
return new PHPInt($value);
}
public void __add(int $value) {
this.$value = this.$value + $value;
}
private PHPInt(int $value) {
this.$value = $value;
}
@Override
public String toString() {
return String.valueOf(this.$value);
}
}
Przekornie klasę bez zmian użyję w kodzie.
public class PHPCodeConvention {
public static void main(String[] args) {
PHPInt phpInt = PHPInt.__constructor(1);
phpInt.__add(1);
phpInt.__add(2);
System.out.println("PHPInt value = " + phpInt);
}
}
Trudno sobie wyobrazić, że można w ten sposób zakodować klasę w javie, horror. Mam nadzieję, że chociaż jedną osobę przekonałem by wpisał w google frazę 'java code convention'.
Pozdrawiam i zapraszam do komentowania.
poniedziałek, maja 18
gnije ale dlaczego
witam;
no to startujemy, pora opowiedzieć sobie co powoduje gnicie systemu;
Changing Requirements
Główna przyczyna degeneracji systemu jest bardzo dobrze znana. Wymagania które się zmieniają w taki sposób, że nie można ich w prosty sposób zaimplementować do pierwotnego projektu. Bardzo często zmiany muszą być bardzo szybko wykonane, często są wykonywane przez programistów nie będących przy tworzeniu pierwotnej wersji softu. Nie są oni wstanie wykonać poprawnie zmian ponieważ nie znają architektury. Zmiany do systemu nie są wprowadzane w czysty sposób dlatego też powodują akumulowania się kodu nie psującego do pierwotnej formy systemu.
Jednakże nie można obwiniać zmieniających się wymagać, o taki obrót sprawy. Każdy programista powinien być świadomy zmienności wymagań względem systemu.
Dependency Management
Jakie zmiany w projekcie powodują gnicie się systemu? Często zmiany wymuszają wprowadzanie nowych niezaplanowanych zależności pomiędzy klasami. Cztery symptomy wymienione w poście wcześniej wpływają bezpośrednio lub pośrednio, na to w jaki sposób są wprowadzane zależności pomiędzy klasami. Największym problemem w programowaniu obiektowym jest odpowiednie wprowadzanie zależności pomiędzy klasami, oraz odpowiednie zarządzanie tymi zależnościami. Programowanie obiektowe samo w sobie nie wspomaga tego mechanizmu, lecz istnieje kilka praktyk które pozwalają na dalszym etapie projektu wprowadzać zmian bez szkody dla niego.
… w kolejny postach przedstawię te mechanizmy, oraz na koniec pokażę zależność pomiędzy tymi praktykami.
ps. miłego czytania.
no to startujemy, pora opowiedzieć sobie co powoduje gnicie systemu;
Changing Requirements
Główna przyczyna degeneracji systemu jest bardzo dobrze znana. Wymagania które się zmieniają w taki sposób, że nie można ich w prosty sposób zaimplementować do pierwotnego projektu. Bardzo często zmiany muszą być bardzo szybko wykonane, często są wykonywane przez programistów nie będących przy tworzeniu pierwotnej wersji softu. Nie są oni wstanie wykonać poprawnie zmian ponieważ nie znają architektury. Zmiany do systemu nie są wprowadzane w czysty sposób dlatego też powodują akumulowania się kodu nie psującego do pierwotnej formy systemu.
Jednakże nie można obwiniać zmieniających się wymagać, o taki obrót sprawy. Każdy programista powinien być świadomy zmienności wymagań względem systemu.
Dependency Management
Jakie zmiany w projekcie powodują gnicie się systemu? Często zmiany wymuszają wprowadzanie nowych niezaplanowanych zależności pomiędzy klasami. Cztery symptomy wymienione w poście wcześniej wpływają bezpośrednio lub pośrednio, na to w jaki sposób są wprowadzane zależności pomiędzy klasami. Największym problemem w programowaniu obiektowym jest odpowiednie wprowadzanie zależności pomiędzy klasami, oraz odpowiednie zarządzanie tymi zależnościami. Programowanie obiektowe samo w sobie nie wspomaga tego mechanizmu, lecz istnieje kilka praktyk które pozwalają na dalszym etapie projektu wprowadzać zmian bez szkody dla niego.
… w kolejny postach przedstawię te mechanizmy, oraz na koniec pokażę zależność pomiędzy tymi praktykami.
ps. miłego czytania.
niedziela, maja 17
Symptoms of Rotting Design
solid czas rozpocząć;
Architecture and Dependencies
Aplikacja swoje życie rozpoczyna w umysłach programistów. Na początku posiada bardzo dobrą architekturę, prostotę, oraz zbudowana jest w oparciu o najlepsze wzorce programowania obiektowego.
Z systemem tak tworzonym zaczyna się coś dziać. Oprogramowanie zaczyna gnić. Początki nie są takie straszne, w jednym miejscu zastosuje się jakieś nie ładne rozwiązanie, w innym robi się jakiegoś sprytnego hacka, ale i tak nadal mówimy, że widać piękno pierwotnego projektu. Upływający czas powoduje, że ilość hacków w systemie wzrasta, a nasza prostota systemu zaczyna zanikać. System zaczyna posiadać coraz większy nieład w kodzie, a programiści uświadamiają sobie fakt, że zarządzanie kodem staje się coraz trudniejsze. Z każdą kolejną zmianą w kodzie trzeba zmieniać coraz więcej elementów systemu.
Symptoms of Rotting Design
Są cztery podstawowe symptomy po których można rozpoznać, że system zaczyna gnić. Nie są to zagadnienia przecinające się, ale powiązania między nimi są oczywiste. Podstawowe symptomy to rigidity (sztywność), fragility (kruchość), immobility (nie przenośność), viscosity (lepkość).
Ridigity (sztywność). System w którym jest bardzo trudno wprowadzać zmiany, nawet te łatwe. Każda zmiana pociąga za sobą dużą ilość zmian kaskadowych wynikających z zależności pomiędzy modułami. Zaczyna się to od tego, że zmiana które powinna zająć 2h, przeciąga się do 2 dni i powoduje zmiany w kilkunastu kalach w projekcie;
Kiedy system posiada takie symptomy programiści nie chętnie coś zmieniają i ograniczają się tylko do wprowadzania krytycznych zmian.
Fragility (kruchość). Blisko spokrewniona z sztywnością. Kruchość prowadzi do tego, że gdy dokonamy zmiany w jednym miejscu, system rozpada się w wielu miejscach. Często miejsca jakie ulegają uszkodzeniu nie mają bezpośredniego związku z miejscem zmiany. Sam problem nie pojawia się na etapie kompilacji, ale na etapie wykonania. Jeżeli problem ten zaczyna narastać to po pewnym czasie programistom towarzyszy strach. Wprowadzenie zmiany w jednym miejscu systemu może zepsuć każde inne bliżej nieokreślone miejsce. Jeżeli kruchość wzrasta może powodować wydłużanie się czasu wprowadzania zmian, ponieważ programiści zaczynają wykonywać nadmiarowe testy tylko, dlatego by uchronić się przed ewentualnymi problemami jakie zmiana mogła spowodować. Po pewnym czasie dbanie o system przestaje być opłacalne ponieważ nie wiadomo ile problemów może wprowadzić zmiana.
Immobility (nie przenośność)Immobility (nie przenośność). Pojawia się wtedy, gdy chce się wykorzystać projekt lub jego część w innym miejscu. Często zdarza się, że programista odkrywa to, że inni zrobili już coś podobnego i teraz można by wykorzystać gotowy kod. Ale gdy zaczyna się brać elementy które nas interesują okazuje się, że razem z nimi musimy wziąć bardzo dużo innych nie potrzebnych nam klas. Elementy dodatkowe nie są nam potrzebne, ale bez nich moduł nam potrzebny nie zadziała. Sytuacja ta powoduje, że dany fragment oprogramowania zamiast zostać użytym zostaje przepisany od nowa.
Viscosity (lepkość). Mówimy o lepkości projektu oraz systemu. Lepkość projektu pojawia się wtedy gdy zmianę można wykonać na więcej niż jedne sposób. Niektóre formy zmian są dłuższe, ale łamią pierwotnej architektury systemu, inne można nazwać potocznie hack. Jeżeli programiści wybierają dłuższe i leprze sposoby rozwiązywania problemu to nic strasznego się nie dzieje, ale może się tak zdarzyć, że presja klienta spowoduje zrobienie kacka. Oczywiście programista powtarza sobie, że zrobi hacks, puści release, a następnie rozwiązanie poprawi na porządne, tak się nigdy nie dzieje. Problemem w lepkości jest to, że zmiany łatwe które powinno się łatwo wprowadzać i nie powinny one łamać naszej pierwotnej architektury systemu, robią coś zupełnie przeciwnego.
Cztery symptomy o jakich napisałem są oznaką słabej architektury. Każda aplikacja posiadająca te oznaki zaczyna się psuć od środka. Ale co powoduje psucie się aplikacji, o tym napiszę w innym poście.
Architecture and Dependencies
Aplikacja swoje życie rozpoczyna w umysłach programistów. Na początku posiada bardzo dobrą architekturę, prostotę, oraz zbudowana jest w oparciu o najlepsze wzorce programowania obiektowego.
Z systemem tak tworzonym zaczyna się coś dziać. Oprogramowanie zaczyna gnić. Początki nie są takie straszne, w jednym miejscu zastosuje się jakieś nie ładne rozwiązanie, w innym robi się jakiegoś sprytnego hacka, ale i tak nadal mówimy, że widać piękno pierwotnego projektu. Upływający czas powoduje, że ilość hacków w systemie wzrasta, a nasza prostota systemu zaczyna zanikać. System zaczyna posiadać coraz większy nieład w kodzie, a programiści uświadamiają sobie fakt, że zarządzanie kodem staje się coraz trudniejsze. Z każdą kolejną zmianą w kodzie trzeba zmieniać coraz więcej elementów systemu.
Symptoms of Rotting Design
Są cztery podstawowe symptomy po których można rozpoznać, że system zaczyna gnić. Nie są to zagadnienia przecinające się, ale powiązania między nimi są oczywiste. Podstawowe symptomy to rigidity (sztywność), fragility (kruchość), immobility (nie przenośność), viscosity (lepkość).
Ridigity (sztywność). System w którym jest bardzo trudno wprowadzać zmiany, nawet te łatwe. Każda zmiana pociąga za sobą dużą ilość zmian kaskadowych wynikających z zależności pomiędzy modułami. Zaczyna się to od tego, że zmiana które powinna zająć 2h, przeciąga się do 2 dni i powoduje zmiany w kilkunastu kalach w projekcie;
Kiedy system posiada takie symptomy programiści nie chętnie coś zmieniają i ograniczają się tylko do wprowadzania krytycznych zmian.
Fragility (kruchość). Blisko spokrewniona z sztywnością. Kruchość prowadzi do tego, że gdy dokonamy zmiany w jednym miejscu, system rozpada się w wielu miejscach. Często miejsca jakie ulegają uszkodzeniu nie mają bezpośredniego związku z miejscem zmiany. Sam problem nie pojawia się na etapie kompilacji, ale na etapie wykonania. Jeżeli problem ten zaczyna narastać to po pewnym czasie programistom towarzyszy strach. Wprowadzenie zmiany w jednym miejscu systemu może zepsuć każde inne bliżej nieokreślone miejsce. Jeżeli kruchość wzrasta może powodować wydłużanie się czasu wprowadzania zmian, ponieważ programiści zaczynają wykonywać nadmiarowe testy tylko, dlatego by uchronić się przed ewentualnymi problemami jakie zmiana mogła spowodować. Po pewnym czasie dbanie o system przestaje być opłacalne ponieważ nie wiadomo ile problemów może wprowadzić zmiana.
Immobility (nie przenośność)Immobility (nie przenośność). Pojawia się wtedy, gdy chce się wykorzystać projekt lub jego część w innym miejscu. Często zdarza się, że programista odkrywa to, że inni zrobili już coś podobnego i teraz można by wykorzystać gotowy kod. Ale gdy zaczyna się brać elementy które nas interesują okazuje się, że razem z nimi musimy wziąć bardzo dużo innych nie potrzebnych nam klas. Elementy dodatkowe nie są nam potrzebne, ale bez nich moduł nam potrzebny nie zadziała. Sytuacja ta powoduje, że dany fragment oprogramowania zamiast zostać użytym zostaje przepisany od nowa.
Viscosity (lepkość). Mówimy o lepkości projektu oraz systemu. Lepkość projektu pojawia się wtedy gdy zmianę można wykonać na więcej niż jedne sposób. Niektóre formy zmian są dłuższe, ale łamią pierwotnej architektury systemu, inne można nazwać potocznie hack. Jeżeli programiści wybierają dłuższe i leprze sposoby rozwiązywania problemu to nic strasznego się nie dzieje, ale może się tak zdarzyć, że presja klienta spowoduje zrobienie kacka. Oczywiście programista powtarza sobie, że zrobi hacks, puści release, a następnie rozwiązanie poprawi na porządne, tak się nigdy nie dzieje. Problemem w lepkości jest to, że zmiany łatwe które powinno się łatwo wprowadzać i nie powinny one łamać naszej pierwotnej architektury systemu, robią coś zupełnie przeciwnego.
Cztery symptomy o jakich napisałem są oznaką słabej architektury. Każda aplikacja posiadająca te oznaki zaczyna się psuć od środka. Ale co powoduje psucie się aplikacji, o tym napiszę w innym poście.
start.. SOLID
Witam;
mój pierwszy post o SOLID będzie przedstawieniem treści innych postów, po wykładzie Bruno Bossoli na GeeCON zostałem zarażony tą ideą, dlatego startuję z postami na temat kilku praktyk jakie należy stosować w programowaniu obiektowym(według tej metodologii); cały artykuł będzie się składał z kilku postów o treści: jakie są znaki, że nasze oprogramowanie zaczyna się psuć; następnie kilka powodów psucia się pierwotnego projektu aplikacji; opiszę 5 praktyk w osobnych postach; opisanie tych praktyk wyjaśni etymologię słowa SOLID;
ps. zaraz dodam kolejnego posta;
mój pierwszy post o SOLID będzie przedstawieniem treści innych postów, po wykładzie Bruno Bossoli na GeeCON zostałem zarażony tą ideą, dlatego startuję z postami na temat kilku praktyk jakie należy stosować w programowaniu obiektowym(według tej metodologii); cały artykuł będzie się składał z kilku postów o treści: jakie są znaki, że nasze oprogramowanie zaczyna się psuć; następnie kilka powodów psucia się pierwotnego projektu aplikacji; opiszę 5 praktyk w osobnych postach; opisanie tych praktyk wyjaśni etymologię słowa SOLID;
ps. zaraz dodam kolejnego posta;
czwartek, stycznia 29
JSR294 – modułowość w Javie 7
Problem modułowości i reużywalności aplikacji pisanych w Javie znany jest nie od dziś. Chyba najważniejszą właściwością następnego wydania Javy (7.0) ma być modułowość sporego i czasami zbyt ciężkiego pakietu programistycznego JDK. Podkreślił to ostatnio także Mark Reinhold, główny architekt platformy Java Standard Edition, który jest odpowiedzialny za prace nad następną wersją. W swoim blogu zapowiedział inaugurację projektu Jigsaw, inicjatywy w ramach społeczności OpenJDK, której celem jest modułowość JDK 7 oraz praca nad specyfikacją JSR 294 "Improved Modularity Support in the Java Programming Language".
JSR 294 określa wprowadzenie tzw. superpakietów, a także rozszerzenie języka Java oraz wirtualnej maszyny Javy (JVM), w celu zagwarantowania możliwości tworzenia modularnego oprogramowania w Javie. Reinhold zamierza uwzględnić JSR 294 w Javie 7.
Kolejnymi specyfikacjami odnoszącymi się do tej tematyki są JSR 277 i JSR 291.
JSR 277 "Java Module System" wprowadza format dystrybucyjny oraz repozytorium dla pakietów Javy oraz przynależnych zasobów. Oprócz tego specyfikacja opisuje mechanizmy ładowania i integracji klas w czasie działania programu. Specyfikacja ta jest jednak krytykowana za zbyt małą elastyczność. JSR 277 nie będzie uwzględniona w Javie 7. Jak ktoś nie lubi czytać to więcej można się dowiedzieć z serwisu parleys.com, jest tam prezencja JSR-277 Java Module System
Z kolei specyfikacja JSR 291 "Dynamic Component Support for Java" została opublikowana w lutym 2006 roku przez firmę IBM. Określa ona standaryzację centralnych modułów frameworka OSGi w ramach JCP i osadzenie ich w platformie Java Standard Edition. Jako przykład służy tutaj obowiązująca w przypadku platformy JavaME specyfikacja JSR 232 "Mobile Operational Management". Celem JSR 291 jest zdefiniowanie dynamicznego frameworka, który obsługiwałby istniejące środowiska Java SE bazujące na dynamicznym modelu komponentów OSGi. Sun od samego początku podawał w wątpliwość konieczność wprowadzania tej specyfikacji, ponieważ koncepcja osadzenia podobna do JSR 291 została już opisana w specyfikacji wydanej przez konsorcjum OSGi. Mimo że pomysł OSGi został pierwotnie opracowany na platformie Javy, istnieją komponenty OSGi niezintegrowane z tym językiem. Ponieważ Reinhold nie wspomina o tej specyfikacji JSR 291, nie należy przypuszczać, aby została ona uwzględniona w Javie 7.
Jeżeli interesuje was problem modularności oprogramowania polecam linki (najlepiej oglądać w kolejności :P):
JSR 294 określa wprowadzenie tzw. superpakietów, a także rozszerzenie języka Java oraz wirtualnej maszyny Javy (JVM), w celu zagwarantowania możliwości tworzenia modularnego oprogramowania w Javie. Reinhold zamierza uwzględnić JSR 294 w Javie 7.
Kolejnymi specyfikacjami odnoszącymi się do tej tematyki są JSR 277 i JSR 291.
JSR 277 "Java Module System" wprowadza format dystrybucyjny oraz repozytorium dla pakietów Javy oraz przynależnych zasobów. Oprócz tego specyfikacja opisuje mechanizmy ładowania i integracji klas w czasie działania programu. Specyfikacja ta jest jednak krytykowana za zbyt małą elastyczność. JSR 277 nie będzie uwzględniona w Javie 7. Jak ktoś nie lubi czytać to więcej można się dowiedzieć z serwisu parleys.com, jest tam prezencja JSR-277 Java Module System
Z kolei specyfikacja JSR 291 "Dynamic Component Support for Java" została opublikowana w lutym 2006 roku przez firmę IBM. Określa ona standaryzację centralnych modułów frameworka OSGi w ramach JCP i osadzenie ich w platformie Java Standard Edition. Jako przykład służy tutaj obowiązująca w przypadku platformy JavaME specyfikacja JSR 232 "Mobile Operational Management". Celem JSR 291 jest zdefiniowanie dynamicznego frameworka, który obsługiwałby istniejące środowiska Java SE bazujące na dynamicznym modelu komponentów OSGi. Sun od samego początku podawał w wątpliwość konieczność wprowadzania tej specyfikacji, ponieważ koncepcja osadzenia podobna do JSR 291 została już opisana w specyfikacji wydanej przez konsorcjum OSGi. Mimo że pomysł OSGi został pierwotnie opracowany na platformie Javy, istnieją komponenty OSGi niezintegrowane z tym językiem. Ponieważ Reinhold nie wspomina o tej specyfikacji JSR 291, nie należy przypuszczać, aby została ona uwzględniona w Javie 7.
Jeżeli interesuje was problem modularności oprogramowania polecam linki (najlepiej oglądać w kolejności :P):
czwartek, listopada 6
IoC, a prelekcja Sławka
witam;
no to jesteśmy po spotkaniu Lublin JUG które to odbyło się 4 listopada 2008 w godzinach 18-20; jak zwykle Sławek Sobótka w swój unikalny i porywający sposób wygłosił prelekcję pod tytułem: 'IoC/Dependency Injection na przykładzie Spring';
nie będę się rozpisywał na temat prelekcji, jeżeli chcecie się dowiedzieć coś więcej to odsyłam na blog autora art-of-software.blogspot.com, obiecał on umieścić małe streszczenie prelekcji; slajdy oraz kod z prezentacji można znaleźć na stronie LJUG;
ps. w momencie pisania posta streszczenia nie było, ale znając Sławka w najbliższym czasie powinno się pojawić;
no to jesteśmy po spotkaniu Lublin JUG które to odbyło się 4 listopada 2008 w godzinach 18-20; jak zwykle Sławek Sobótka w swój unikalny i porywający sposób wygłosił prelekcję pod tytułem: 'IoC/Dependency Injection na przykładzie Spring';
nie będę się rozpisywał na temat prelekcji, jeżeli chcecie się dowiedzieć coś więcej to odsyłam na blog autora art-of-software.blogspot.com, obiecał on umieścić małe streszczenie prelekcji; slajdy oraz kod z prezentacji można znaleźć na stronie LJUG;
ps. w momencie pisania posta streszczenia nie było, ale znając Sławka w najbliższym czasie powinno się pojawić;
wtorek, sierpnia 5
warstwowy model aplikacji
Postaram się w bardzo przystępny sposób przedstawić
warstwowy model aplikacji. Warstwy stanowią logiczny podział systemu. Każda z warstw posiada właściwy zakres odpowiedzialności, co gwarantuję, że będą od siebie oddzielone logicznie. Przy implementowaniu warstw musimy dopilnować by miały pomiędzy sobą bardzo luźne powiązania.
Po pięknym teoretycznym wstępie :P, napiszę kilka słów jak taki model osiągnąć. Proces budowania podziału przedstawię na przykładzie niepoprawnie zbudowanego podziału na warstwy. Na koniec przedstawię korzyści jakie płyną z podziału warstwowego. Wysiłek jaki trzeba włożyć w programowanie nie powinien być tylko poniesiony dla faktu posiadania modelu warstwowego. Wykonanie wszystkich czynności oraz za modelowanie aplikacji przynosi bardzo wiele wymiernych korzyści.
Refaktoryzacja architektury.
Należy przenieść kod dostępu do danych bliżej rzeczywistego źródła danych, a logikę przetwarzania z warstwy klienta do warstwy biznesowej. W drugim kroku zostanie przedstawiony model poprawnego rozbicia na warstwy. Na koniec refaktoryzacji przeprowadzone zostanie rozbicie w warstwie biznesowej na komponenty sesyjne zajmujące się logiką biznesową, oraz na komponenty entity stanowiące model trwałych transakcyjnych obiektów.
Podział taki zapewnia bardzo wyraźne rozdzielenie, a w przyszłości zagwarantuje jak największą skalowalność, elastyczność, bezpieczeństwo...
W miarę upływu czasu projekt musi sobie coraz lepiej radzić z elementami związanymi z trwałością danych, transakcjami i skalowalnością usług. Podejście gwarantuje łatwość osiągnięcia tego założenia:
Funkcje potrzebne do zbudowani modelu warstwowego:
do poczytania.
warstwowy model aplikacji. Warstwy stanowią logiczny podział systemu. Każda z warstw posiada właściwy zakres odpowiedzialności, co gwarantuję, że będą od siebie oddzielone logicznie. Przy implementowaniu warstw musimy dopilnować by miały pomiędzy sobą bardzo luźne powiązania.
Po pięknym teoretycznym wstępie :P, napiszę kilka słów jak taki model osiągnąć. Proces budowania podziału przedstawię na przykładzie niepoprawnie zbudowanego podziału na warstwy. Na koniec przedstawię korzyści jakie płyną z podziału warstwowego. Wysiłek jaki trzeba włożyć w programowanie nie powinien być tylko poniesiony dla faktu posiadania modelu warstwowego. Wykonanie wszystkich czynności oraz za modelowanie aplikacji przynosi bardzo wiele wymiernych korzyści.
Refaktoryzacja architektury.
Należy przenieść kod dostępu do danych bliżej rzeczywistego źródła danych, a logikę przetwarzania z warstwy klienta do warstwy biznesowej. W drugim kroku zostanie przedstawiony model poprawnego rozbicia na warstwy. Na koniec refaktoryzacji przeprowadzone zostanie rozbicie w warstwie biznesowej na komponenty sesyjne zajmujące się logiką biznesową, oraz na komponenty entity stanowiące model trwałych transakcyjnych obiektów.
Podział taki zapewnia bardzo wyraźne rozdzielenie, a w przyszłości zagwarantuje jak największą skalowalność, elastyczność, bezpieczeństwo...
W miarę upływu czasu projekt musi sobie coraz lepiej radzić z elementami związanymi z trwałością danych, transakcjami i skalowalnością usług. Podejście gwarantuje łatwość osiągnięcia tego założenia:
Funkcje potrzebne do zbudowani modelu warstwowego:
- zbudowanie GUI w oparciu o model MVC
- podział logiki na niezależne fragmenty
- ukrycie szczegółów warstwy prezentacji przed warstwą biznesową
- usunięcie konwersji z widoku
- wydzielenie kodu dostępu do danych z warstwy prezentacji (DAO)
- oddzielenie przetwarzania prezentacyjnego od przetwarzania biznesowego (Business Delegate), zastosowania logiki biznesowej pozwoli zastosować usługi nie tylko w warstwie prezentacji, podejście takie gwarantuje dużo większą re - używalność kodu biznesowego
- redukcja komunikacji pomiędzy komponentami
- przy takim układzie bardzo ułatwione jest zarządzanie deklaracyjne transakcjami
do poczytania.
piątek, czerwca 27
wzorzec do wzorców :P
Witam, postaram się w skrócie napisać jaka formę będą przyjmowały opisywane wzorce, niezły ze mnie maniak właśnie przedstawię wzorzec, przy pomocy którego będę opisywał wzorce :P
A o to i struktura składająca się z nazwy, oraz 10 akapitów:
Example
Cel, zawiera krótki opis funkcji wzorca. Inaczej mówiąc, jest to definicja bardziej lub mniej formalna;
Motywacja, zawiera opis pewnej sytuacji lub problemu, oraz sposób rozwiązania; czyli kawałek tekstu umoralniającego który ma przekonać czytelnika by zapamiętał wzorzec;
Zastosowanie, zawiera bardziej szczegółowe omówienie sytuacji, w których wzorzec można zastosować.
Struktura, zawiera diagram ilustrujący związki między klasami wzorca, jak ktoś lubi to mu się spodoba ten kawałek UML'a.
Uczestnicy, zawiera klasy i obiekty tworzące dany wzorzec. Tu znajdziemy opis ich zakresów odpowiedzialności i ról.
Współpraca, zawiera omówienie współpracy obiektów lub/i klas wzorca.
Konsekwencje, omawia potencjalne skutki użycia wzorca – pożądane i niepożądane.
Implementacja, to co lubię najbardziej kawałek kodu;
Wcześniejsze zastosowania, trochę to ambitne , ale jak będę wiedział o zastosowaniu danego wzorca postaram się to napisać;
Powiązane wzorce, opis związków i zależności między opisanym właśnie wzorcem, a innymi wzorcami; coś tu napiszę jeśli tylko będę świadom tych związków;
No to mamy wzorzec dla wzorców;
A o to i struktura składająca się z nazwy, oraz 10 akapitów:
Example
Cel, zawiera krótki opis funkcji wzorca. Inaczej mówiąc, jest to definicja bardziej lub mniej formalna;
Motywacja, zawiera opis pewnej sytuacji lub problemu, oraz sposób rozwiązania; czyli kawałek tekstu umoralniającego który ma przekonać czytelnika by zapamiętał wzorzec;
Zastosowanie, zawiera bardziej szczegółowe omówienie sytuacji, w których wzorzec można zastosować.
Struktura, zawiera diagram ilustrujący związki między klasami wzorca, jak ktoś lubi to mu się spodoba ten kawałek UML'a.
Uczestnicy, zawiera klasy i obiekty tworzące dany wzorzec. Tu znajdziemy opis ich zakresów odpowiedzialności i ról.
Współpraca, zawiera omówienie współpracy obiektów lub/i klas wzorca.
Konsekwencje, omawia potencjalne skutki użycia wzorca – pożądane i niepożądane.
Implementacja, to co lubię najbardziej kawałek kodu;
Wcześniejsze zastosowania, trochę to ambitne , ale jak będę wiedział o zastosowaniu danego wzorca postaram się to napisać;
Powiązane wzorce, opis związków i zależności między opisanym właśnie wzorcem, a innymi wzorcami; coś tu napiszę jeśli tylko będę świadom tych związków;
No to mamy wzorzec dla wzorców;
piątek, czerwca 6
edytowany I-szy post
Coś na poważnie, chyba czas rozpocząć pisanie czegoś poważniejszego; miał to być blog o JavaEE, frameworkach apache, jboss, ale nie będzie, pierwsze kilkanaście postów będzie opisywało wzorce projektowe;
Z wzorcami wiąże się bardzo ciekawa historia, gdy pierwszy raz miałem okazje opowiadać o nich na uczelni słuchało mnie 6 osób, jedyny komentarz jaki dostałem na koniec brzmiał: "stary ale kat"; nie wiem co mam o tym sądzić, ale chyba był pozytywny :P
Postaram sie poopowiadać o wzorcach rozpocznę od mniej ambitnych lub bardziej będzie to zależało od tego kto będzie czytał tekst...
... mam nadzieję że nikt nie napisze, ale kat :P
Z wzorcami wiąże się bardzo ciekawa historia, gdy pierwszy raz miałem okazje opowiadać o nich na uczelni słuchało mnie 6 osób, jedyny komentarz jaki dostałem na koniec brzmiał: "stary ale kat"; nie wiem co mam o tym sądzić, ale chyba był pozytywny :P
Postaram sie poopowiadać o wzorcach rozpocznę od mniej ambitnych lub bardziej będzie to zależało od tego kto będzie czytał tekst...
... mam nadzieję że nikt nie napisze, ale kat :P
Subskrybuj:
Posty (Atom)