What do you think?
A Kent Beck Signature Book
Implementation Patterns (Addison-Wesley Signature Series
Kent is a master at creating code that communicates well, is easy to understand, and is a pleasure to read. Every chapter of this book contains excellent explanations and insights into the smaller but important decisions we continuously have to make when creating quality code and classes. Erich Gamma, IBM Distinguished Engineer Many teams have a master developer who makes a rapid stream of good decisions all day long. Their code is easy to understand, quick to modify, and feels safe and comfortable to work with. If you ask how they thought to write something the way they did, they always have a good reason. This book will help you become the master developer on your team. The breadth and depth of topics will engage veteran programmers, who will pick up new tricks and improve on old habits, while the clarity makes it accessible to even novice developers. Russ Rufer, Silicon Valley Patterns Group Many people don t realize how readable code can be and how valuable that readability is. Kent has taught me so much, I m glad this book gives everyone the chance to learn from him. Martin Fowler, chief scientist, ThoughtWorks Code should be worth reading, not just by the compiler, but by humans. Kent Beck distilled his experience into a cohesive collection of implementation patterns. These nuggets of advice will make your code truly worth reading. Gregor Hohpe, author of Enterprise Integration Patterns In this book Kent Beck shows how writing clear and readable code follows from the application of simple principles. Implementation Patterns will help developers write intention revealing code that is both easy to understand and flexible towards future extensions. A must read for developers who are serious about their code. Sven Gorts Implementation Patterns bridges the gap between design and coding. Beck introduces a new way of thinking about programming by basing his discussion on values and principles. Diomidis Spinellis, author of Code Reading and Code Quality Software Expert Kent Beck Presents a Catalog of Patterns Infinitely Useful for Everyday Programming Great code doesn t just function: it clearly and consistently communicates your intentions, allowing other programmers to understand your code, rely on it, and modify it with confidence. But great code doesn t just happen. It is the outcome of hundreds of small but critical decisions programmers make every single day. Now, legendary software innovator Kent Beck known worldwide for creating Extreme Programming and pioneering software patterns and test-driven development focuses on these critical decisions, unearthing powerful implementation patterns for writing programs that are simpler, clearer, better organized, and more cost effective. Beck collects 77 patterns for handling everyday programming tasks and writing more readable code. This new collection of patterns addresses many aspects of development, including class, state, behavior, method, collections, frameworks, and more. He uses diagrams, stories, examples, and essays to engage the reader as he illuminates the patterns. You ll find proven solutions for handling everything from naming variables to checking exceptions. This book covers
The value of communicating through code and the philosophy behind patterns How and when to create classes, and how classes encode logic Best practices for storing and retrieving state Behavior: patterns for representing logic, including alternative paths Writing, naming, and decomposing methods Choosing and using collections Implementation pattern variations for use in building frameworks Implementation Patterns will help programmers at all experience levels, especially those who have benefited from software patterns or agile methods. It will also be an indispensable resource for development teams seeking to work together more efficiently and build more maintainable software. No other programming book will touch your day-to-day work more often. "
The value of communicating through code and the philosophy behind patterns How and when to create classes, and how classes encode logic Best practices for storing and retrieving state Behavior: patterns for representing logic, including alternative paths Writing, naming, and decomposing methods Choosing and using collections Implementation pattern variations for use in building frameworks Implementation Patterns will help programmers at all experience levels, especially those who have benefited from software patterns or agile methods. It will also be an indispensable resource for development teams seeking to work together more efficiently and build more maintainable software. No other programming book will touch your day-to-day work more often. "
176 pages, Paperback
First published November 2, 2006
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 2 of 2 reviews
February 26, 2017
Książka przede wszystkim jest stara i to widać jak się czyta, mimo że autor wspomina JUnit 4. Zacząłem to czytać bo autor jest znaną Java Rock Star. I mimo, że część spostrzeżeń jest interesująca , warta cytowania i poleciłbym te fragmenty innym niemniej jako całość szału nie robi. Jakby wyciąć mniej interesującą część tak z 50% to było by must read.
Kiedy pracuję dobrze, zwracam uwagę na znaczenie komunikacji z innymi osobami, by dbać o zachowanie możliwie jak największej prostoty kodu i by zapewnić możliwie dużą liczbę potencjalnych rozwiązań. Te wartości — komunikatywność, prostota oraz elastyczność — nadają barw wszystkim decyzjom, które podejmuję podczas tworzenia kodu.
Te trzy elementy — wartości, zasady oraz wzorce — stanowią zrównoważony wyraz stylu programowania. Wzorce określają, co należy zrobić. Wartości tłumaczą motywacje. A zasady pomagają w przekształceniu pobudek na działania.
Jest to właśnie ta nadmierna złożoność, która prowadzi do zmniejszenia wartości oprogramowania, gdyż zmniejsza prawdopodobieństwo prawidłowego działania programu, a w przyszłości utrudni wprowadzanie w nim modyfikacji. Jednym z elementów programowania jest spojrzenie na wykonaną pracę i oddzielenie ziarna od plew.
Rozszerzanie możliwości komunikacji za pośrednictwem kodu poprawia także jego elastyczność. Im więcej będzie osób, które będą w stanie szybko przeczytać, zrozumieć i zmodyfikować kod, tym firma będzie mieć większe możliwości zaktualizowania oprogramowania w przyszłości.
Kod powinien mieć taką strukturę, by wprowadzane zmiany miały jedynie lokalne konsekwencje. Jeśli zmiana tutaj może spowodować problemy gdzie indziej, to koszt takich zmian drastycznie wzrasta.
Szybkość zmian odnosi się do danych. Wszystkie pola obiektu powinny zmieniać się w mniej więcej tym samym tempie. Na przykład pola modyfikowane wyłącznie w trakcie działania konkretnej metody powinny być zmiennymi lokalnymi. Dwa pola obiektu, które zmieniają się jednocześnie, lecz w innym tempie niż pozostałe, najprawdopodobniej należałoby umieścić w obiekcie pomocniczym.
Utrzymanie oprogramowania jest kosztowne, gdyż zrozumienie istniejącego kodu jest czasochłonne i podatne na błędy.
Wprowadzanie zmian jest zazwyczaj proste, o ile tylko wiadomo, co trzeba zmienić. Kosztowne jest natomiast zrozumienie, jak kod działa.
kosztutrzymania = kosztzrozumienia + kosztmodyfikacji + koszttestowania + kosztwdrożenia
Przedwczesne próby napisania kodu na tyle ogólnego, by zaspokoił wszystkie przyszłe potrzeby, niejednokrotnie utrudniają wprowadzanie nieoczekiwanych, acz koniecznych zmian.
Narzędziem, które nieodmiennie ułatwia znajdowanie lepszych nazw, są rozmowy. Próby wyjaśnienia innym przeznaczenia obiektu pozwalają mi wyobrazić sobie bogate i ekspresyjne obrazy umożliwiające jego opisanie. Te obrazy mogą się przyczynić do wskazania nowych nazw.
Jest to właśnie ta nadmierna złożoność, która prowadzi do zmniejszenia wartości oprogramowania, gdyż zmniejsza prawdopodobieństwo prawidłowego działania programu, a w przyszłości utrudni wprowadzanie w nim modyfikacji. Jednym z elementów programowania jest spojrzenie na wykonaną pracę i oddzielenie ziarna od plew.
Przedwczesne próby napisania kodu na tyle ogólnego, by zaspokoił wszystkie przyszłe potrzeby, niejednokrotnie utrudniają wprowadzanie nieoczekiwanych, acz koniecznych zmian.
Dlatego zamiast bezmyślnie dodawać modyfikatory do nazwy bezpośredniej klasy bazowej, warto przyjrzeć się potencjalnej nazwie z punktu widzenia osoby analizującej kod.
nazwa klasy równie dobrze mogłaby być liczbą. Zbyt długie nazwy klas utrudniają czytanie oraz formatowanie kodu. Zbiory klas, których nazwy nie są ze sobą w żaden sposób powiązane, będzie trudno zrozumieć i zapamiętać. Nazwy klas powinny opowiadać historię, którą nasz kod opisuje.
Połączenie tych wszystkich czynników — konieczność zapewnienia elastyczności, koszty jej uzyskania oraz brak możliwości przewidzenia, czy ta elastyczność faktycznie będzie potrzebna — doprowadziło mnie do przekonania, że elastyczność należy wprowadzać wtedy, kiedy okazuje się niezbędna.
Jedną z interesujących cech klas wewnętrznych jest to, że do ich instancji w ukryty sposób są przekazywane kopie obiektów, w których zostały one utworzone. Rozwiązanie to jest bardzo wygodne, gdy chcemy skorzystać z danych obiektu zewnętrznego bez jawnego określania ich wzajemnej relacji:
Każda ścieżka realizacji programu wiąże się z prawdopodobieństwem tego, że będzie poprawna. Zakładając, że prawdopodobieństwo poprawności każdej ze ścieżek jest niezależne, im więcej ścieżek będzie istnieć w programie, tym mniejsze będą szanse na to, że będzie on poprawny.
Choć klasy biblioteczne są dosyć często stosowane, to jednak nie zapewniają dobrych możliwości skalowania. Umieszczenie logiki w metodach statycznych przekreśla największą zaletę programowania obiektowego: istnienie prywatnej przestrzeni nazw, w której można umieszczać dane i która pomaga uprościć logikę. Dlatego zawsze, gdy to tylko możliwe, należy starać się zastępować klasy biblioteczne normalnymi obiektami.
Programiści cały czas muszą myśleć, komunikować intencje i się uczyć. To nieodłączne elementy bycia profesjonalistą.
Gromadzenie — zmienna gromadzi informacje przeznaczone do późniejszego wykorzystania. Często zdarza się, że wartość takiej zmiennej jest zwracana jako wynik wywołania funkcji. W takich przypadkach warto nadać zmiennej nazwę result lub results.
Kiedy już wykształcimy w sobie dążenie do estetyki kodu, to wrażenia estetyczne, które kod będzie nam zapewniał, okażą się cenną informacją o jego jakości. Te odczucia wydostające się spod powierzchni symbolicznych myśli mogą być równie cenne, jak jawnie nazwane i uzasadnione wzorce.
Niegdyś istniało pewne przykazanie programistyczne, nakazujące, by każdy podprogram miał tylko jeden punkt wejścia i jeden punkt wyjścia. Sformułowano go, by zapobiec zamieszaniu, które mogłoby wystąpić, gdyby realizacja podprogramu mogła się zaczynać w wielu miejscach jego kodu i w wielu miejscach sterowanie mogłoby go opuszczać. Takie rozwiązanie było sensowne w języku FORTRAN oraz w programach pisanych w języku asemblera, które w dużym stopniu korzystały z danych globalnych i w których już samo wskazanie wykonywanych instrukcji było trudnym zadaniem. Natomiast w języku Java, w którym tworzone metody są niewielkie i korzystają przeważnie z danych lokalnych, takie podejście jest niepotrzebnie konserwatywne. Niemniej jeśli ten swoisty programistyczny folklor będzie rygorystycznie przestrzegany, uniemożliwi stosowanie wzorca klauzuli strażnika.
Metody dostępne w pakiecie — tworzenie metod dostępnych w pakiecie stanowi komunikat, że przydadzą się obiektom wchodzącym w skład tego pakietu, a jednocześnie że nie mamy zamiaru udostępniać ich obiektom spoza pakietu. Ten komunikat jest dosyć dziwny — takie metody mogą być potrzebne innym obiektom, lecz nie wszystkim, a jedynie napisanym przez twórcę metody. Występowanie tego rodzaju widoczności należy potraktować jako informację bądź to o konieczności przeniesienia funkcjonalności, tak by metody były mniej widoczne, bądź o tym, że metoda jest bardziej użyteczna, niż początkowo sądzono, i warto udostępnić ją publicznie, ponosząc związane z tym koszty.
Zachowanie słowa kluczowego final na te okazje, kiedy jego użycie faktycznie się nam opłaci, a przy tym nie przysporzy problemów klientom, pozwoli poprawić wzajemne relacje między twórcami platformy i jej użytkownikami.
Jedną z bardzo ważnych umiejętności programistycznych jest dostosowywanie wysiłku do celu, który chcemy osiągnąć.
Kiedy pracuję dobrze, zwracam uwagę na znaczenie komunikacji z innymi osobami, by dbać o zachowanie możliwie jak największej prostoty kodu i by zapewnić możliwie dużą liczbę potencjalnych rozwiązań. Te wartości — komunikatywność, prostota oraz elastyczność — nadają barw wszystkim decyzjom, które podejmuję podczas tworzenia kodu.
Te trzy elementy — wartości, zasady oraz wzorce — stanowią zrównoważony wyraz stylu programowania. Wzorce określają, co należy zrobić. Wartości tłumaczą motywacje. A zasady pomagają w przekształceniu pobudek na działania.
Jest to właśnie ta nadmierna złożoność, która prowadzi do zmniejszenia wartości oprogramowania, gdyż zmniejsza prawdopodobieństwo prawidłowego działania programu, a w przyszłości utrudni wprowadzanie w nim modyfikacji. Jednym z elementów programowania jest spojrzenie na wykonaną pracę i oddzielenie ziarna od plew.
Jedną z bardzo ważnych umiejętności programistycznych jest dostosowywanie wysiłku do celu, który chcemy osiągnąć.
Kiedy pracuję dobrze, zwracam uwagę na znaczenie komunikacji z innymi osobami, by dbać o zachowanie możliwie jak największej prostoty kodu i by zapewnić możliwie dużą liczbę potencjalnych rozwiązań. Te wartości — komunikatywność, prostota oraz elastyczność — nadają barw wszystkim decyzjom, które podejmuję podczas tworzenia kodu.
Te trzy elementy — wartości, zasady oraz wzorce — stanowią zrównoważony wyraz stylu programowania. Wzorce określają, co należy zrobić. Wartości tłumaczą motywacje. A zasady pomagają w przekształceniu pobudek na działania.
Jest to właśnie ta nadmierna złożoność, która prowadzi do zmniejszenia wartości oprogramowania, gdyż zmniejsza prawdopodobieństwo prawidłowego działania programu, a w przyszłości utrudni wprowadzanie w nim modyfikacji. Jednym z elementów programowania jest spojrzenie na wykonaną pracę i oddzielenie ziarna od plew.
Rozszerzanie możliwości komunikacji za pośrednictwem kodu poprawia także jego elastyczność. Im więcej będzie osób, które będą w stanie szybko przeczytać, zrozumieć i zmodyfikować kod, tym firma będzie mieć większe możliwości zaktualizowania oprogramowania w przyszłości.
Kod powinien mieć taką strukturę, by wprowadzane zmiany miały jedynie lokalne konsekwencje. Jeśli zmiana tutaj może spowodować problemy gdzie indziej, to koszt takich zmian drastycznie wzrasta.
Szybkość zmian odnosi się do danych. Wszystkie pola obiektu powinny zmieniać się w mniej więcej tym samym tempie. Na przykład pola modyfikowane wyłącznie w trakcie działania konkretnej metody powinny być zmiennymi lokalnymi. Dwa pola obiektu, które zmieniają się jednocześnie, lecz w innym tempie niż pozostałe, najprawdopodobniej należałoby umieścić w obiekcie pomocniczym.
Utrzymanie oprogramowania jest kosztowne, gdyż zrozumienie istniejącego kodu jest czasochłonne i podatne na błędy.
Wprowadzanie zmian jest zazwyczaj proste, o ile tylko wiadomo, co trzeba zmienić. Kosztowne jest natomiast zrozumienie, jak kod działa.
kosztutrzymania = kosztzrozumienia + kosztmodyfikacji + koszttestowania + kosztwdrożenia
Przedwczesne próby napisania kodu na tyle ogólnego, by zaspokoił wszystkie przyszłe potrzeby, niejednokrotnie utrudniają wprowadzanie nieoczekiwanych, acz koniecznych zmian.
Narzędziem, które nieodmiennie ułatwia znajdowanie lepszych nazw, są rozmowy. Próby wyjaśnienia innym przeznaczenia obiektu pozwalają mi wyobrazić sobie bogate i ekspresyjne obrazy umożliwiające jego opisanie. Te obrazy mogą się przyczynić do wskazania nowych nazw.
Jest to właśnie ta nadmierna złożoność, która prowadzi do zmniejszenia wartości oprogramowania, gdyż zmniejsza prawdopodobieństwo prawidłowego działania programu, a w przyszłości utrudni wprowadzanie w nim modyfikacji. Jednym z elementów programowania jest spojrzenie na wykonaną pracę i oddzielenie ziarna od plew.
Przedwczesne próby napisania kodu na tyle ogólnego, by zaspokoił wszystkie przyszłe potrzeby, niejednokrotnie utrudniają wprowadzanie nieoczekiwanych, acz koniecznych zmian.
Dlatego zamiast bezmyślnie dodawać modyfikatory do nazwy bezpośredniej klasy bazowej, warto przyjrzeć się potencjalnej nazwie z punktu widzenia osoby analizującej kod.
nazwa klasy równie dobrze mogłaby być liczbą. Zbyt długie nazwy klas utrudniają czytanie oraz formatowanie kodu. Zbiory klas, których nazwy nie są ze sobą w żaden sposób powiązane, będzie trudno zrozumieć i zapamiętać. Nazwy klas powinny opowiadać historię, którą nasz kod opisuje.
Połączenie tych wszystkich czynników — konieczność zapewnienia elastyczności, koszty jej uzyskania oraz brak możliwości przewidzenia, czy ta elastyczność faktycznie będzie potrzebna — doprowadziło mnie do przekonania, że elastyczność należy wprowadzać wtedy, kiedy okazuje się niezbędna.
Jedną z interesujących cech klas wewnętrznych jest to, że do ich instancji w ukryty sposób są przekazywane kopie obiektów, w których zostały one utworzone. Rozwiązanie to jest bardzo wygodne, gdy chcemy skorzystać z danych obiektu zewnętrznego bez jawnego określania ich wzajemnej relacji:
Każda ścieżka realizacji programu wiąże się z prawdopodobieństwem tego, że będzie poprawna. Zakładając, że prawdopodobieństwo poprawności każdej ze ścieżek jest niezależne, im więcej ścieżek będzie istnieć w programie, tym mniejsze będą szanse na to, że będzie on poprawny.
Choć klasy biblioteczne są dosyć często stosowane, to jednak nie zapewniają dobrych możliwości skalowania. Umieszczenie logiki w metodach statycznych przekreśla największą zaletę programowania obiektowego: istnienie prywatnej przestrzeni nazw, w której można umieszczać dane i która pomaga uprościć logikę. Dlatego zawsze, gdy to tylko możliwe, należy starać się zastępować klasy biblioteczne normalnymi obiektami.
Programiści cały czas muszą myśleć, komunikować intencje i się uczyć. To nieodłączne elementy bycia profesjonalistą.
Gromadzenie — zmienna gromadzi informacje przeznaczone do późniejszego wykorzystania. Często zdarza się, że wartość takiej zmiennej jest zwracana jako wynik wywołania funkcji. W takich przypadkach warto nadać zmiennej nazwę result lub results.
Kiedy już wykształcimy w sobie dążenie do estetyki kodu, to wrażenia estetyczne, które kod będzie nam zapewniał, okażą się cenną informacją o jego jakości. Te odczucia wydostające się spod powierzchni symbolicznych myśli mogą być równie cenne, jak jawnie nazwane i uzasadnione wzorce.
Niegdyś istniało pewne przykazanie programistyczne, nakazujące, by każdy podprogram miał tylko jeden punkt wejścia i jeden punkt wyjścia. Sformułowano go, by zapobiec zamieszaniu, które mogłoby wystąpić, gdyby realizacja podprogramu mogła się zaczynać w wielu miejscach jego kodu i w wielu miejscach sterowanie mogłoby go opuszczać. Takie rozwiązanie było sensowne w języku FORTRAN oraz w programach pisanych w języku asemblera, które w dużym stopniu korzystały z danych globalnych i w których już samo wskazanie wykonywanych instrukcji było trudnym zadaniem. Natomiast w języku Java, w którym tworzone metody są niewielkie i korzystają przeważnie z danych lokalnych, takie podejście jest niepotrzebnie konserwatywne. Niemniej jeśli ten swoisty programistyczny folklor będzie rygorystycznie przestrzegany, uniemożliwi stosowanie wzorca klauzuli strażnika.
Metody dostępne w pakiecie — tworzenie metod dostępnych w pakiecie stanowi komunikat, że przydadzą się obiektom wchodzącym w skład tego pakietu, a jednocześnie że nie mamy zamiaru udostępniać ich obiektom spoza pakietu. Ten komunikat jest dosyć dziwny — takie metody mogą być potrzebne innym obiektom, lecz nie wszystkim, a jedynie napisanym przez twórcę metody. Występowanie tego rodzaju widoczności należy potraktować jako informację bądź to o konieczności przeniesienia funkcjonalności, tak by metody były mniej widoczne, bądź o tym, że metoda jest bardziej użyteczna, niż początkowo sądzono, i warto udostępnić ją publicznie, ponosząc związane z tym koszty.
Zachowanie słowa kluczowego final na te okazje, kiedy jego użycie faktycznie się nam opłaci, a przy tym nie przysporzy problemów klientom, pozwoli poprawić wzajemne relacje między twórcami platformy i jej użytkownikami.
Jedną z bardzo ważnych umiejętności programistycznych jest dostosowywanie wysiłku do celu, który chcemy osiągnąć.
Kiedy pracuję dobrze, zwracam uwagę na znaczenie komunikacji z innymi osobami, by dbać o zachowanie możliwie jak największej prostoty kodu i by zapewnić możliwie dużą liczbę potencjalnych rozwiązań. Te wartości — komunikatywność, prostota oraz elastyczność — nadają barw wszystkim decyzjom, które podejmuję podczas tworzenia kodu.
Te trzy elementy — wartości, zasady oraz wzorce — stanowią zrównoważony wyraz stylu programowania. Wzorce określają, co należy zrobić. Wartości tłumaczą motywacje. A zasady pomagają w przekształceniu pobudek na działania.
Jest to właśnie ta nadmierna złożoność, która prowadzi do zmniejszenia wartości oprogramowania, gdyż zmniejsza prawdopodobieństwo prawidłowego działania programu, a w przyszłości utrudni wprowadzanie w nim modyfikacji. Jednym z elementów programowania jest spojrzenie na wykonaną pracę i oddzielenie ziarna od plew.
Jedną z bardzo ważnych umiejętności programistycznych jest dostosowywanie wysiłku do celu, który chcemy osiągnąć.
April 3, 2018
Żart jakiś, jako wzorce przedstawione tak trywialne rzeczy jak getter czy setter? Autor dotarł w swoich rozważaniach do tak porażająco wyrafinowanych pojęć jak Factory method...
Displaying 1 - 2 of 2 reviews