See Part 1 of this series on how the SOLID principles can help us follow emergent design without the Big Up Front Design and without the code rot.

Single Responsibility Principle

"A class should have one, and only one, reason to change"

In software, we tend to enjoy grouping things together, but really what we should be doing is splitting them apart. This really gets back to the notion of cohesion.

Every time a class has multiple responsibilities, you’re creating unecessary dependencies that can lead to code rot. You know the problem, you change one part of your code, only to find it has completely unintended effects on a completely different part of your application. What we want instead is to make sure code never gets touched, heck never even has to go through a recompile, unless we really do intend to change it’s behavior.

How can we fix this? By limiting each class to a Single Responsibility. Every time you place more than one responsibility into a single class, those two responsibilities become coupled together and every time you change one responsibility, you risk impairing the class’s ability to meet its other responsibilities. Again, you risk changing one area of the code only to inadvertently break another area.

Okay, but what is a responsibility?

Read More…..

Emergent design can quickly degrade into un-maintainable hack & slash yuckness without a set of guiding principles to keep you in check. Fortunately, Robert Martin’s SOLID Principles are just what the doctor ordered for saving your app from an early demise. By making sure your code continues to conform to these principles with each new refactor, you can make sure that your code is staying… well, solid and can live a long and healthy life to pave the way for many a developer’s employment long after you’ve moved on to newer and more exciting projects.

In Agile, we don’t have no stinkin’ time for Big Design Up Front. We want to start delivering as early and often as possible. It makes the customer happy and, if done right, it makes us developers happy too because it’s way more fun building stuff then sitting around pontificating the perfect method of yet-another-persistence layer.

But, it’s also pretty scarey because if you don’t do the design up front, it means you have to do it continuously - every time you touch the code - or else, well, that’s going to become some really nasty code that isn’t going to be making anyone happy. So, every time you make a change to your code, you do some refactoring to keep the design from degrading. Great idea! But how do you know how or even what needs to be refactored? And how do you know when you’re done?

Read More…..