Whenever I start on any new project, I have this uber-abstract mindset that spins off all manner of what-if things it could do. It's a matter of combinatorics: you know it has to read, will it have to write? you know it has to add, will it have to subtract? And so on. Most such ideas are not practical. This drives my boss nuts.
But this what-if thinking occasionally pulls my chestnuts out of the fire when someone breaks the promise that they'll never ever need so-and-so (but they do).
Thus, I set my course between Scylla and Charybdis. On one hand, I build something inadequate that must be carefully rewritten to be extended. On the other hand, I build something over-engineered and/or bloated. The principles of Object Oriented offer a path between them. One principle is "program to interfaces."
For the last couple years, I've been doing a lot of Test-Driven development. This week, I put Test-Driven to work in conjunction with "programming to interfaces." I created the interfaces for my current project, and before I had anything more than method signatures and parameter lists, I immediately wrote unit tests to thrash out the interfaces.
My intent was to code up just enough to get Visual Studio reverse-engineer it and thereby get UML class diagrams to use. However, it came together so very well, that the next steps were trivial. Before the day was out, I had gotten much further, much faster than I could have possibly dared to think.
There's one thing to understand OO and what it can do for you. It's another thing to take it to the next level. I'm quite pleased with what I've applied today.
reverse engineered from
These unit tests served to give me an immediate feel for how the software would work and this let me tweak the design so as to get the maximum functionality out of the minimum code.
There is in the principals of Object Oriented software development, a Now, when you have a righteous OO design, it'll manifest open-closed characteristics. The design will be closed to modification and open to extension.