SOLID Code with Emergent Design – Part 1
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?
That’s where the principles of object oriented class design come in (acronym: SOLID). Each time you touch your code, ask yourself if it is still going to conform to these principles after your changes. If so, great, you’re all done! If not, refactor your classes according to the these principles:
But wait, what if that requires some really big changes? Won’t the risk of these changes breaking something outweigh the risk of my sloppy design breaking something? Well, no, silly, that’s where your unit tests come in.
Stay tuned, I’ll cover each of these principles in my blogs to follow.