With the advent of agile methods, Test-Driven Development (TDD) has been gaining momentum. A mantra of agile is that stories are completed, not merely written, every iteration. This means they have to go through testing to be considered “done, done, done.” Many teams have experienced the productivity gains and value of TDD. Many teams have, unfortunately, shied away from it as well. We believe that the value and reason that TDD works is not fully appreciated. This chapter discusses both why TDD works, and why it isn’t really testing up-front.

For each quality we will describe it generally, mention any principles that it adheres to or promotes, suggest practices that will help you to enhance the quality, note any indicators that might tell you that your code is lacking in the quality (pathologies), and any testing issues that might help you to see how well you are achieving them. First, however, we’ll start with an analogy.

In this summary we will examine one way of dealing with change: to prepare for it without creating unnecessary complexity. Even if you understand this, you’re quite likely going to find yourself in the position of having to convince someone else, so this argument is one it may be useful for you to have in mind.

Creating software is more than one activity. The software that we create does more than one thing, and does most of the things it does in more than one way. Software has to be changed for more than one reason, and these changes are of various types. Clarity, consistency, and efficiency can be fundamentally increased by adhering to the notion of the Separation of Concerns. In this summary, we will examine this principle and how we are promoting it by recommending specific practices in this book.

Solving tricky problems can often involve changing your point of view. In this chapter we’ll examine one particularly tricky problem – how to avoid overdesign without suffering the problems that often accompany an insufficient or naïve design – by rethinking two arguably well known aspects of development: the Open-Closed Principle, and the discipline of Refactoring. We’ll begin by examining these aspects as they are traditionally understood, and then repurpose them in a more agile way.

The mechanism of inheritance is provided in some form by most modern programming languages. However, its improper use can lead to brittle, unnecessarily inflexible architectures that sacrifice encapsulation for little or no gain. This should not, however, lead a developer to conclude that inheritance is bad, or even that it should be used in a minimal, last-resort way. The real question is: what is inheritance good for, and when should it be used?

Encapsulation is a word that’s been with us in software development for a long time; but if you asked people what it means, many would say something like “hiding data”. In fact, there are quite a few books and websites that would use that as the definition of the word. However, we have found that an examination of the true meaning of encapsulation can be enormously beneficial and can make many other aspects of Object-Oriented design (design patterns, for instance) easier to understand and to use.
 read more »