This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Back to Basics: Agile Object-Oriented Design
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
A few weeks ago I went to a talk that covered some basic object-oriented design principles and how they can improve agility. I've been in software development for over 15 years, but I found that a review of these fundamentals was refreshing.
If you've been involved in OO design, you'll be familiar with these, but maybe you'll benefit from seeing them once more.
1. Single Responsibility Principle. This principle states that an object should have only one reason to change. Example: A Customer class might know about it's address and phone number as a core responsibility, but shouldn't be trying to ship packages simply because it has an address. That would mean that when shipping rules change, or when we want to add a cell phone, both kind of changes would mean modifying the class.
2. Open/Closed Principle. An object should be open for extension, but closed to modification. Simply put, you want to be able to extend the behavior of a class in the future without changing it's source code. For example, if you create a DataStore class that accepts 3 different types of objects and stores them, you want to be able to add a fourth in the future without modifying the class. One way to do this is to define an abstraction for the objects you pass in so that the DataStore class can generically get the information it needs to save them. This approach also enables simple unit-testing by allowing you to stub or mock out other classes that collaborate with a class under test.
3. Liskov Substitution Principle. This is the golden rule of inheritance. It says that a subclass should always be directly substitutable for it's superclass. Personally I prefer interfaces and composition to inheritance, but in the rare cases you might need to use it, this is an important rule to follow.
A good source for more information on these practices is Robert Martin's book The Principles, Patterns, and Practices of Agile Software Development.
Experts in all sort of fields will tell you that the key to improving your skill is working on the fundamentals, no matter what level you're on. Why should software development be any different?
Previous Topic
