Home > Work > Implementation Patterns

Implementation Patterns QUOTES

Implementation Patterns QUOTES

1 " Actually this book is built on a rather fragile premise: that good code matters. I have seen too much ugly code make too much money to believe that quality of code is either necessary or sufficient for commercial success or widespread use. "

― Kent Beck , Implementation Patterns

2 " Another way to look at implementation patterns is as a way of thinking “What do I want to tell a reader about this code? "

― Kent Beck , Implementation Patterns

3 " Even if there was no long-term economic impact from careful coding I would still choose to write the best code I could. "

― Kent Beck , Implementation Patterns

4 " Exceptions occur at different levels of abstraction. Catching and reporting a low-level exception can be confusing to someone who is not expecting it. When a web server shows me an error page with stack trace headed by a NullPointerException, I’m not sure what I’m supposed to do with the information. I’d rather see a message that said, “The programmer did not consider the scenario you have just presented.” I wouldn’t mind if the page also provided a pointer to further information that I could send to a programmer so he could diagnose the problem, but presenting me with untranslated details isn’t helpful. "

― Kent Beck , Implementation Patterns

5 " Readers need to understand programs in detail and in concept. Sometimes they move from detail to concept, sometimes from concept to detail. "

― Kent Beck , Implementation Patterns

6 " Flexibility can come at the cost of increased complexity. "

― Kent Beck , Implementation Patterns

7 " Unlike the names at the roots of hierarchies, subclass names aren’t used nearly as often in conversation, so they can be expressive at the cost of being concise. "

― Kent Beck , Implementation Patterns

8 " When objects first became popular, subclassing seemed like a magic pill. First, subclasses were used for classification—a Train was a subclass of Vehicle regardless of whether they shared any implementation. In time, some people saw that since what inheritance did was share implementation, it could most effectively be used to factor out common bits of implementation. Quickly, though, the limitations of subclassing became apparent. "

― Kent Beck , Implementation Patterns

9 " The majority of the cost of software is incurred after the software has been first deployed. Thinking about my experience of modifying
code, I see that I spend much more time reading the existing code than I do writing new code. If I want to make my code cheap, therefore, I should make it easy to read. "

― Kent Beck , Implementation Patterns

10 " Sometimes I feel silly introducing methods “just” to satisfy an “aesthetic” urge like symmetry. Aesthetics go deeper than that. Aesthetics engage more of your brain than strictly linear logical thought. Once you have cultivated your sense of the aesthetics of code, the aesthetic impressions you receive of your code is valuable feedback about the quality of the code. "

― Kent Beck , Implementation Patterns

11 " In the olden days (half a century ago), programs were big, undifferentiated masses of code and data. Control could flow from anywhere to anywhere. Data could be accessed from anywhere. Calculations, the original purpose of computers, occurred with (relatively speaking) lightning speed and perfect accuracy. Then people discovered an awkward fact: programs are written as much to be changed as to be run. All this control jumping around and self-modifying code and data accessed from everywhere was great for execution, but it was terrible if you wanted to change the program later. And so began the long and halting road to find models of computation so a change here doesn’t cause an unanticipated problem there. "

― Kent Beck , Implementation Patterns

12 " Call-by-reference went out of fashion in language design a couple of decades ago because of the possibility for unintended consequences. "

― Kent Beck , Implementation Patterns

13 " When we released JUnit 4 recently we spent nearly half of our engineering budget on reducing the cost of deployment for our clients. We tried to make sure that new-style tests would work with old tools and old-style tests would work with new tools. We also worked to make sure we had the freedom to make future changes to JUnit without breaking client code. "

― Kent Beck , Implementation Patterns

14 " At some point, the cost of maintaining perfect compatibility outweighs the value to clients. "

― Kent Beck , Implementation Patterns

15 " A framework with all protected fields would be more immediately usable but harder to evolve later. "

― Kent Beck , Implementation Patterns

16 " Packages can provide a way to offer clients incremental access to upgrades. By introducing new classes in a new package, you can give them the same name as the old classes. For example, if I can upgrade org.junit.Assert in org.junit.newandimproved.Assert, then clients need only change the import statements to be using the new class. Changing imports is less risky and intrusive than changing code. "

― Kent Beck , Implementation Patterns

17 " Versioned interfaces are a reasonable compromise when you absolutely must introduce new operations to an existing interface-based abstraction without affecting client code. They are not a long-term solution for frequently changing abstraction, because of the complexity they create both for client and framework developers. "

― Kent Beck , Implementation Patterns

18 " The purposes of two constructors with different sets of parameters are not always obvious, but the name of the factory methods can suggest the reason clients might want to create an object each way. "

― Kent Beck , Implementation Patterns

19 " It is the framework developer’s job to ensure that clients can extend the framework to solve the remainder of their problems. It’s tempting to try to solve a broad range of problems with a framework. The conflict is that the added functionality makes the framework that much more difficult to learn and use for all clients. "

― Kent Beck , Implementation Patterns