What do you think?
Rate this book
A Kent Beck Signature Book
Padrões de Implementação
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 identifies 77 new patterns for handling everyday programming tasks and writing more readable code. These new patterns address many areas of development, including class, state, behavior, method, collections, frameworks, and more. You’ll find better solutions for handling everything from naming variables to checking exceptions. He uses diagrams, stories, examples, and essays to present each pattern in the most illuminating way possible.
The 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 software engineering book will touch your day-to-day work more often, and no other book will prove more useful.
Paperback
First published November 2, 2006
70 people are currently reading
1465 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 59 reviews
March 29, 2017
As with everything Kent Beck writes, this book is amazing.
You can either gloss over the details and perceive it as common sense, or you can think deeply about his ideas and how he arrives at them and then develop a similar mindset when it comes about the design. The first approach will yield a boring book at best, while the second will teach you stuff, even if you consider yourself quite adept at this already.
You can either gloss over the details and perceive it as common sense, or you can think deeply about his ideas and how he arrives at them and then develop a similar mindset when it comes about the design. The first approach will yield a boring book at best, while the second will teach you stuff, even if you consider yourself quite adept at this already.
December 24, 2016
Na knihu jsem narazil v podstatě náhodou, když jsem si objednával Test Driven Development: By Example, tak jsem si přihodil do košíku, ať není poštovné příliš velkým podílem na ceně. :)
Tato kniha vyšla ve stejný čas jako Clean Code: A Handbook of Agile Software Craftsmanship, ale není tak známá. Já ji však považuji za mnohem kvalitnější knihu věnující se stejné problematice - čistému kódu. Možná je to absencí Uncle Bobovy agitky, možná Kentovou rozvážností a schopností zamýšlet se nad tím, co, proč a jak dělá.
Skvěle jsou ukázány rozdíly v přemýšlení při návrhu aplikačního kódu a knihoven/frameworků.
Doporučuji jako povinnou četbu.
Tato kniha vyšla ve stejný čas jako Clean Code: A Handbook of Agile Software Craftsmanship, ale není tak známá. Já ji však považuji za mnohem kvalitnější knihu věnující se stejné problematice - čistému kódu. Možná je to absencí Uncle Bobovy agitky, možná Kentovou rozvážností a schopností zamýšlet se nad tím, co, proč a jak dělá.
Skvěle jsou ukázány rozdíly v přemýšlení při návrhu aplikačního kódu a knihoven/frameworků.
Doporučuji jako povinnou četbu.
October 22, 2013
I'm not quite sure where to start this review because the dichotomy in my thinking is so stark. However for the purpose of getting over the sad out of the way first I'll start with that. This book was published about five years too late and I've managed to read it about ten years too late. There's no hiding from the fact this book collects advice on a language that resembles a model T ford at a V8 race event. It's not so far removed from the cars on the track that it's unrecognisable but no one is expecting this thing to win anything. If I'd read this when it was published I would have been wowed by it and given it a 5. Significant portions of this book (for instance much of the advice about collections, interfaces and factories) is simply inapplicable to other languages. There's a sense in a number of parts of this book that this (as in Java) is where we are and we'd best get on with it, which reflects an industry in dormancy (at the time of writing).
Having said that I should be clear here. You should read a lot of Kent Beck if you work in technology. None of the advice is frivolous and the book feels like the distillation of a large amount of thought and practice in development. More than that it's a ripping read. I love Kent Beck's writing. It's clarity and poise are lovely and there are no flat spots in the writing. The authority inherent in the work is clear and never overplayed. Mr Beck practiced Java till he was good at it and then wrote a book. This book wouldn't have even made it to my hands had it not been written by Kent Beck and I do appreciate the advice in the book. I thought the chapter on framework writing was excellent, I loved the discussion of economics in framework development and the tradeoffs inherent in the approaches to framework delivery.
If you're a programmer of OO languages you'll still get value out of this. If you work in technology pick this up and at least sample the writing. Sadly time has not been kind to the subject matter so you may find portions of the advice unusable. Which is a sad thing to say indeed.
Having said that I should be clear here. You should read a lot of Kent Beck if you work in technology. None of the advice is frivolous and the book feels like the distillation of a large amount of thought and practice in development. More than that it's a ripping read. I love Kent Beck's writing. It's clarity and poise are lovely and there are no flat spots in the writing. The authority inherent in the work is clear and never overplayed. Mr Beck practiced Java till he was good at it and then wrote a book. This book wouldn't have even made it to my hands had it not been written by Kent Beck and I do appreciate the advice in the book. I thought the chapter on framework writing was excellent, I loved the discussion of economics in framework development and the tradeoffs inherent in the approaches to framework delivery.
If you're a programmer of OO languages you'll still get value out of this. If you work in technology pick this up and at least sample the writing. Sadly time has not been kind to the subject matter so you may find portions of the advice unusable. Which is a sad thing to say indeed.
August 8, 2024
It's a highly pragmatic Kent Beck book. I'd even go as far as to say that it's his most valuable book to me.
As Kent Beck describes, "there is no magic to writing code other people can read. It’s like all writing—know your audience, have a clear overall structure in mind, express the details so they contribute to the whole story". 💡
As a very light read, "Implementation Patterns" is wrapped around the pragmatism of writing understandable Java code. Is this book useful if you're not writing Java and not using abstract interfaces and abstract classes, for example? Unfortunately, not. "Implementation Patterns" is dated in its specific approach to "teaching" Java engineers how to write more understandable Java code. 🤔
I truly believe the book didn't stand the test of time. It's not a book you should go for. 😕
What book should you read instead? Kent Beck's Tidy First. I have only quickly skimmed through it. It's written for the more modern audience with less theory and more examples and comparisons.
As Kent Beck describes, "there is no magic to writing code other people can read. It’s like all writing—know your audience, have a clear overall structure in mind, express the details so they contribute to the whole story". 💡
As a very light read, "Implementation Patterns" is wrapped around the pragmatism of writing understandable Java code. Is this book useful if you're not writing Java and not using abstract interfaces and abstract classes, for example? Unfortunately, not. "Implementation Patterns" is dated in its specific approach to "teaching" Java engineers how to write more understandable Java code. 🤔
I truly believe the book didn't stand the test of time. It's not a book you should go for. 😕
What book should you read instead? Kent Beck's Tidy First. I have only quickly skimmed through it. It's written for the more modern audience with less theory and more examples and comparisons.
October 31, 2010
Implementations patterns is about all those small-scale patterns that you use during programming, usually on a one class/object level (in contrast to design patterns, that are about the interactions of numerous objects). It specifically focusses on code readability. This is a book about Java (also this is not very visible). Concepts might be transferable to other similar languages like C++ or C#.
The book is well written and relatively well edited. I found one error in the code that is not problematic to understanding. Besides from that it repeats important concepts several times (which is ok) and makes references to patterns that haven't been introduced jet, without referencing the pages (really annoying). The book is well structured, but this structure could be more visible at first glance, for example by better distinguishing or numbering different headings.
All in all the book has useful insight and is an easy read. Nothing in here is rocket-science or very surprising, but often a useful point to start thing about your own implementation patterns (everybody has his own). I recommend it to Java programmers looking for an educational and easy read.
I can only give 3.5 stars as I expected a lot more, especially for the advanced programmer (as the book claims to offer insight for everyone). People that are very experienced and used to using Java libraries will not profit a lot from this.
The book is well written and relatively well edited. I found one error in the code that is not problematic to understanding. Besides from that it repeats important concepts several times (which is ok) and makes references to patterns that haven't been introduced jet, without referencing the pages (really annoying). The book is well structured, but this structure could be more visible at first glance, for example by better distinguishing or numbering different headings.
All in all the book has useful insight and is an easy read. Nothing in here is rocket-science or very surprising, but often a useful point to start thing about your own implementation patterns (everybody has his own). I recommend it to Java programmers looking for an educational and easy read.
I can only give 3.5 stars as I expected a lot more, especially for the advanced programmer (as the book claims to offer insight for everyone). People that are very experienced and used to using Java libraries will not profit a lot from this.
December 3, 2018
The best part is the introduction where Kent Beck presents the Values behind all the patterns
- Communication (to other developers)
- Simplicity
- Flexibility
and most importantly the principles that are devised from those values
- Local consequences
- Minimize repetition
- Logic and data together (Object orientation)
- Symmetry
- Declarative expression
- Rate of change
His reasoning is always very balanced and focuses on the essence of the trade-offs.
But the rest of the book would be hard to read this book from cover to cover. While there's useful information like his procedure of refactoring to Method Object, it's basically a list of all minor patterns that constitute our code, in which I don't find much value. It looks like a brain-dump with the main purpose to be complete (for the java language) than to actually be useful information.
- Communication (to other developers)
- Simplicity
- Flexibility
and most importantly the principles that are devised from those values
- Local consequences
- Minimize repetition
- Logic and data together (Object orientation)
- Symmetry
- Declarative expression
- Rate of change
His reasoning is always very balanced and focuses on the essence of the trade-offs.
But the rest of the book would be hard to read this book from cover to cover. While there's useful information like his procedure of refactoring to Method Object, it's basically a list of all minor patterns that constitute our code, in which I don't find much value. It looks like a brain-dump with the main purpose to be complete (for the java language) than to actually be useful information.
November 27, 2021
Kent Beck is known for Extreme Programming Explained: Embrace Change and as the author of JUnit. It is not fair, that this book is neglected. I could avoid some my mistakes. But who knows, I might not have appreciated it enough years ago.
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ąć.
February 29, 2016
The worst technical book I have ever read. The author is having very few outdated concepts to communicate, and he just keep beating around the bush for doing that.
While choosing this book to read, I was quite happy thinking at last somebody tried to communicate how important is that code written is easily understandable not only to the computers but also to the humans reading it.
But after reading few pages, I got completely disappointed and bored and stopped reading it after 50 pages.
While choosing this book to read, I was quite happy thinking at last somebody tried to communicate how important is that code written is easily understandable not only to the computers but also to the humans reading it.
But after reading few pages, I got completely disappointed and bored and stopped reading it after 50 pages.
February 5, 2022
I enjoy reading all of Kent Beck's books. Kent is a remarkable developer and following his thoughts on software design is both enjoyable and rewarding.
Although this book is not groundbreaking, it contains some solid patterns, especially useful if you are writing Java code. If you're looking for patterns, probably you'll find this book boring. The biggest value of this book is not in the offered patterns. The value is in understanding what's in Kent's head, how Kent is reasoning about code, coding, and design trade-offs.
Although this book is not groundbreaking, it contains some solid patterns, especially useful if you are writing Java code. If you're looking for patterns, probably you'll find this book boring. The biggest value of this book is not in the offered patterns. The value is in understanding what's in Kent's head, how Kent is reasoning about code, coding, and design trade-offs.
November 5, 2017
While the premises are great, the book itself results very dry and many of the patterns were too abstract for me.
December 21, 2022
I do like Kent Beck. I saw him speak once and he had a very interesting mind which was very enjoyable to see unfurl.
Unfortunately this book hasn't aged so well, and was often a struggle to read. However it does still have some important information in it.
I do think that the first 4 chapters are worth reading for any new or improving programmer. These chapters briefly examine both the social and economic qualities of good vs bad code, and what values as a programmer you should try to adhere to. After 20 years in the industry I still found this of use, even just to clarify my own thoughts.
The chapters on classes and state are worth visiting. The chapters on behaviour and methods less so but still contain some useful information. The chapter on collections is probably worth reading, mainly for the clarification of the relative performance trade-off.
The fact that the book is centered around OO and Java felt a bit restrictive to me, especially now we are in an age of more functional styles and 'optional' OO. The OO focus in the book does mean that it becomes clearer to understand when to use OO, but it is a bit harder to understand when to not use it, and in the current age of software I think this is an important subject.
So this is probably worth having on a shelf for new and intermediate programmers - it will benefit both to reference it but to varying degrees. However there are probably more modern books that are easier to digest than this one.
Unfortunately this book hasn't aged so well, and was often a struggle to read. However it does still have some important information in it.
I do think that the first 4 chapters are worth reading for any new or improving programmer. These chapters briefly examine both the social and economic qualities of good vs bad code, and what values as a programmer you should try to adhere to. After 20 years in the industry I still found this of use, even just to clarify my own thoughts.
The chapters on classes and state are worth visiting. The chapters on behaviour and methods less so but still contain some useful information. The chapter on collections is probably worth reading, mainly for the clarification of the relative performance trade-off.
The fact that the book is centered around OO and Java felt a bit restrictive to me, especially now we are in an age of more functional styles and 'optional' OO. The OO focus in the book does mean that it becomes clearer to understand when to use OO, but it is a bit harder to understand when to not use it, and in the current age of software I think this is an important subject.
So this is probably worth having on a shelf for new and intermediate programmers - it will benefit both to reference it but to varying degrees. However there are probably more modern books that are easier to digest than this one.
October 24, 2017
I learned about this book while reading Clean Code by Robert C. Martin. Since it is written by Kent Beck, I just had to read it.
This book and Clean Code by Robert C. Martin have a lot in common but address it in different ways. While the later is more practical with lots of examples and case studies, this one reads more like The Book of Five Rings: here's a piece of advice, go think about it carefully.
This book and Clean Code by Robert C. Martin have a lot in common but address it in different ways. While the later is more practical with lots of examples and case studies, this one reads more like The Book of Five Rings: here's a piece of advice, go think about it carefully.
December 5, 2022
Interesting perspectives and teachings. As a seasoned developer myself, most of the practices described in this book were already known, however having a formal definition and sound reasoning for all these points is really good.
The way Kent treats writing software as an art, with several parallels, recognizing a programmer's innate urge to be productive, to be good with their craft, and to take it to the next level, is something that really resonated with me. Also he is constantly saying that there is no universal rule, it is your job as a programmer to use all the tools, knowledge and experience at your disposal to choose the best alternative. He doesn't treat his sayings as the absolute truth, as is the case in a lot of software development content.
One of the books highest points is the in-depth dive at the Java language, regarding classes, methods, state, behavior and collections. Lots of interesting remarks and suggestions that aren't obvious, but are interesting.
The way Kent treats writing software as an art, with several parallels, recognizing a programmer's innate urge to be productive, to be good with their craft, and to take it to the next level, is something that really resonated with me. Also he is constantly saying that there is no universal rule, it is your job as a programmer to use all the tools, knowledge and experience at your disposal to choose the best alternative. He doesn't treat his sayings as the absolute truth, as is the case in a lot of software development content.
One of the books highest points is the in-depth dive at the Java language, regarding classes, methods, state, behavior and collections. Lots of interesting remarks and suggestions that aren't obvious, but are interesting.
January 14, 2018
С одной стороны, книга описывает ряд важных в разработке ПО принципов (программируйте так, чтобы код было проще читать, держите данные и данные вместе, не злоупотребляйте гибкостью и т.п.), а так же дает полезные рекомендации о том, какие решения принимать в коде при возникновении стандартных, будничных проблем. То есть это не паттерны проектирования, здесь задумка автора направлена на более низкий уровень.
Но для опытного разработчика почти все это будет не в новинку, плюс некоторые шаблоны выглядят довольно мутно, и не совсем понятно, зачем было пытаться их вводить. Плюс книги - в формализации тех решений, которые программисты принимают интуитивно. А глава про коллекции будет полезна новичкам - довольно неплохо описаны основные классы из стандартной библиотеки Java с указанием их главных особенностей. Кратко, по существо, без лишних подробностей
Но для опытного разработчика почти все это будет не в новинку, плюс некоторые шаблоны выглядят довольно мутно, и не совсем понятно, зачем было пытаться их вводить. Плюс книги - в формализации тех решений, которые программисты принимают интуитивно. А глава про коллекции будет полезна новичкам - довольно неплохо описаны основные классы из стандартной библиотеки Java с указанием их главных особенностей. Кратко, по существо, без лишних подробностей
October 4, 2025
I'm a big fan of Kent Beck; I've read many of his books; watched hours of videos and listened to hours of podcasts. And yet I didn't like this book.
First of all, this is a book about communicating with code, but there's almost no code in it. I was a little worried in the Introduction when Beck emphasizes that his focus is Java, which is not my main language - but I shouldn't be worried at all, because there are so few code samples that it doesn't make a difference.
Implementation patterns feels like (and might as well have been originated as) a lecture, where the author just states his general principles: how he writes classes, how he divides methods, how he differentiates between lists and arrays. It just feels... generic.
First of all, this is a book about communicating with code, but there's almost no code in it. I was a little worried in the Introduction when Beck emphasizes that his focus is Java, which is not my main language - but I shouldn't be worried at all, because there are so few code samples that it doesn't make a difference.
Implementation patterns feels like (and might as well have been originated as) a lecture, where the author just states his general principles: how he writes classes, how he divides methods, how he differentiates between lists and arrays. It just feels... generic.
August 25, 2017
Nem tudom, nem ezt vártam ettől a könyvtől. Igaz, hogy megvan már egy ideje és csak most olvastam el, de kicsit többre számítottam.
Túl sok volt a szöveg, kevés példával. Szerintem példák többet mondanak minden díszes leírásnál -- ám ez a könyv valahogy mellé lőtt. Lehet, hogy 10 éve még jó volt a tartalom és sok tapasztalatot megosztott Kent Beck másokkal, de mára ez elavult a számomra. Talán egy kezdő Java fejlesztő sok ötletet meríthet az információból, de jó környezetben e könyv nélkül is megtanulja.
Túl sok volt a szöveg, kevés példával. Szerintem példák többet mondanak minden díszes leírásnál -- ám ez a könyv valahogy mellé lőtt. Lehet, hogy 10 éve még jó volt a tartalom és sok tapasztalatot megosztott Kent Beck másokkal, de mára ez elavult a számomra. Talán egy kezdő Java fejlesztő sok ötletet meríthet az információból, de jó környezetben e könyv nélkül is megtanulja.
October 12, 2020
Mostly great because I can use the word "hodgepodge" in a review. For Java this been done better in Effective Java which I'd recommend instead of this hodgepodge.
December 31, 2023
A disappointing book for me. The first three chapters are great. Here we can tap into the great knowledge of Kent Beck and get many useful insights. The rest of the book, where it goes about doing the work, is too shallow. It only helps you if you are already familiar with the topics and otherwise you only get some basic keywords you can use to try to understand what it is about somewhere else.
February 19, 2018
Basic and somewhat dated in details (written before Java 8 and default interface implementations), but still very useful and worth reading. Good review even for experienced software developers. Mostly utilizes Java, but the concepts will carry into other languages well.
October 8, 2018
Nice and concise book for developer
Covers day to day aspect of programming and give useful suggestions to developer.this is highly recommended book for developer at all experience level.
Covers day to day aspect of programming and give useful suggestions to developer.this is highly recommended book for developer at all experience level.
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...
October 5, 2018
Although a bit aged by now and heavily oriented towards Java and object oriented style it is still a very enlightening reading.
December 4, 2018
It's hard to read.
August 9, 2019
It has a lot of powerfull and usefull ideas. But very frequenly I found others trivial.
The first 20 pages are fundamental, about values and principles.
I bit boring sometimes.
The first 20 pages are fundamental, about values and principles.
I bit boring sometimes.
February 19, 2020
One of those books full of small gems. Push it at new and inexperienced collegues.
May 3, 2020
Basic OOP but a bit boring to read IMO
July 24, 2021
- Provides a good understandings around when to use which constructs in Java
- Explains the forces involved, and how to resolve them in a way to communicate the intent clearly via code.
- Explains the forces involved, and how to resolve them in a way to communicate the intent clearly via code.
August 2, 2021
This book is good to revisit some development techniques, but it's just an introduction.
March 13, 2022
This book is not very long.
Similar patterns (with examples) are also included in "Refactoring: Improving the Design of Existing Code".
Similar patterns (with examples) are also included in "Refactoring: Improving the Design of Existing Code".
Displaying 1 - 30 of 59 reviews