This blog is no longer being maintained, please go to The missing link of Agile instead

Tuesday, April 28, 2009

OO design, reuse and serendipity

Steve Vinoski said pretty wise stuff about reusability of REST-based systems. He said that powerful stuff as Unix small languages was probably incidental just because the design (unix pipe) was based on modularity and simplicity.

It is entirely the same for Object Oriented design. Keep your interfaces simple (ie. make them have clear boundaries [PDF warning!]) and your abstractions simple (ie. having clear and sharp definitions [PDF warning!]* - and modularity comes for free. Simplicity enables modularity!

The important part is that, what is easily forgotten, reuse is not only about using parts of the code on different projects - this should actually be quite rare - I mean most of the time you use external frameworks to do generic stuff.. don't you?. But you should constantly reuse domain classes by using them second, third and nth time in different contexts. And by different contexts I mean implementation of the most exotic requirements of your clients. It's definitely not a good sign if you catch yourself saying "naahh.. we can't use that method for the new requirement, 'cause it's doing this thing and the other thing to do that stuff here.. here.. and over theeeere.. we gotta write a new one".

What you might rather try is:
- refactor (decouple),
- test,
- reuse.

Do it KISS, don't strive for too much generality, but do it right! After the umpteen requirement (and refactoring) you'll be amazed that you have evolved a very sharp abstraction with clear boundaries. Moreover you gained a fair amount of domain knowledge because you kept on building larger coherent structure and not only solving single problems. Always remember about GPS** (Gain Perspective Stupid).

"Serendipitous reuse" is definitely a good sign and if you do OO right it'll come for free.

* The rule of a thumb is that if you have to use two metaphors (or more, sic!) to explain a role of an abstraction to the person from outside the project it means that your domain model stinks in that particular area.
** Coined by my good colleague and great software developer Piotr Wójcicki.

No comments:

Post a Comment