What Not How: The Business Rules Approach to Application Development
by Chris Date (ISBN 0201708507
are other terms for this.
Ever since I had heard the term "Object Orientation", I had been trying to get a workable handle on the concept. I like little verbal guidelines. Like "Do it once" or OnceAndOnlyOnce
. I like anything which encourages clarity out of intricacy naturally.
When I asked a recent graduate on the team at the time, still fired with enthusiasm for the art, what Object Orientation is, he replied "What, not how".
I really like that as a short-hand of the essence of OO. Asking yourself "What, not how" when contemplating almost any facet of design or implementation will nearly always return you to positive consideration of the task. I can only talk from experience - this stuff really belongs in the domain of psychology, and I am no psychologist.
The next time you find yourself in that terrible place where the current task is becoming too difficult, too controversial, too complicated to understand, stop thinking along the lines you are currently, and ask yourself the question "What is it we are trying to achieve?", and act only on the answer to that. Just try it!
This is basically the definition of AbstractDataTypes, not OO, although certainly OO is best based on AbstractDataTypes.
Well not really - at least I was not intending to redefine OO. I would call WhatNotHow
a guideline. It
helps to produce apt designs, regardless of technology. I use MultiValue
technology mostly, and find WhatNotHow
very helpful. -- PeterLynch
"A good programming language should give assistance in expressing not only how the program is to run, but what it is intended to accomplish" ~ CarHoare
, 1973 SIGPLAN keynote