Chapter 5: Head First object-Oriented Analysis and Design

Change is inevitable. No matter how much time you spend and how much you like your software right now, it’s probably going to have to make updates/changes in the future. The harder you make it for your software to be changeable the more difficult its going to be to respond to your customer’s needs of change. That is was the topic is about today and how small changes can turn into big problems.

Adding abstract classes, subclasses and new kinds of association help making your code accessible for changes and expand. But there is a lot more to it, by abstracting common properties and behaviour into classes. By doing this you can make the classes more independent whish is a significant improvement in design.

Anytime you are writing code that interacts with these classes, you have two choices. You an write code that interacts directly with a subclass, like a subclass called TennisPlayer interacts with a class called Athlete. Write code like this to the interface is always better then to the implementation. Why is this so important? Because it adds flexibility to your app. Instead of the code being able to work with only one specific subclass. That means that the code will work with any subclass of Athlete, like FootballPlayer, Dancer and even subclasses that not yet have been designed.

Lets talk more about encapsulation whish we talked about in another post. It is used to prevent duplicate code. But there’s it does do more than just that, it also help to protect the classes from unnecessary changes. Anytime you have behaviour in an application that you think is likely to change, you want to move that behaviour away from parts of you application that probably won’t change very frequently.