Blogging Ottinger (tim)Save Us From Needless Abstractions
Every OOD class seems to have the same struggle. Everyone wants to rush to class design first, without working out objects and interactions. Time after time we see designs bursting at the seams with abstract classes which represent some truth of the problem space, but which are not used in the application at all.
I have often wondered how to encourage people to work in a less abstract way, solving their problem first and then using class design principles as a way to clean up their software’s structure. I interrupted them and provided a simple object structure that solved the problem. They considered my model and returned to their work, many of them still drawn by the siren’s song of class diagrams.
I understand it. Class diagrams are mighty expressive. They show functions and data members, and you feel like you could write code directly to the class design. It’s compelling.
I realized that they were legitimately struggling with the time pressure of getting work done in class, and with the newness of the principles and patterns of OOD. I looked for a new way to make the point. After some consideration, I approached the big easel, and wrote “God save us from needless distractions.” After giving the class a few silent minutes to ponder (or laugh, since the writing of it seemed to be a needless distraction) I reached for the red marker and returned. I crossed out “dis” and wrote in “abs” above it, changing “distraction” to “abstraction. Now I had a point to speak about.
“God save us from needless abstractions” reminds us that software is first and foremost about algorithm and behavior, and that interfaces and
abstract classes are ways to manage the dependencies which would wreck a less-advantageously-structured system. It reminds us to use them
intentionally, and not incidentally or accidentally. Did I make the point understood? The next exercise seemed to indicate that I did.
And now I have one more entry for my “wall of platitudes”.
Where do the requirements play into this?
Thinking out things are good but alot of the time, those who want what you are going to build for them, they like to see a demo. To achieve this, coding seems to start almost immediately.
It seems that today, things are rush rush rush. Thought costs the company more money. However, in the long run, without thought, this could cost the company more money…
Comment by Steve — 2005-September-24 @ 12:34
Requirements would precede this. This is really about OOD, not requirements analysis. I’ve been increasingly leaning toward building a more concrete model (code or object stucture) and proceeding into abstractions (class structures) intentionally.
When people dive into abstractions first, they often start adding facts instead of needed interfaces. I think it’s a natural human tendency that just happens to be the wrong way to go about things.
A friend of mine specialized in RAD. John told me that the secret to moving quickly is to not make mistakes. False starts and bad ideas take time to correct. I think that starting with an object diagram or collaboration diagram first is probably in line with that.
With regards to hurry, I don’t think you can think through a whole system at once anymore, but you have to kinda get a sense of what you are doing. You can work through the design in baby steps.
It’s a tough game. I’ve seen where looking ahead a bit invalidated technology decisions made early on, and cause some thrash. Not looking ahead would have been the bigger problem in that case. In other cases, people put a lot of diagrams together and base further design on them before they know if they’re right. That can be a problem too.
I don’t think that thinking about the baby step you’re about to take is a bad thing, even in a hurried setting. I wonder if it’s not generally worse not to.
Comment by Administrator — 2005-September-24 @ 10:36