The recent rounds of conversation about DP and OO have been very
enlightening to me. I really appreciate the effort Mark, Jim W. and the rest
put into there thoughtful responses.
Jim's rules of thumb for determining DP designs is pretty sweet:
* UML diagrams with lots of attributes and few methods (I see lots of
these).
* Classes with lots of getters/setters and little else (Beans anyone?).
* The tendency to pull data out of an object in order to do something with
it.
along with Mark's corollary that kicked off much of the disussion:
* constants used in conditional logic are DP
A really nice example of DP is the movie rental example Fowler uses in
chapter 1 of his Refactoring book. One in which he takes a small program
which he calls "not object oriented" and refactors it into something which
is.
I will be giving a lecture on refactoring later this month and was reviewing
the book today. As I was looking at his example I noticed that his original
code was using constants in a switch statement. And then I notice that he
has a bean! Then I noticed that he has the tendency to pull data out of an
object in order to do something with it. Oh my, this all sounds familiar.
Some remaining questions in my mind are?
(1) Is it a dichotomized space of DP or OO only? Are there other
classifications?
(2)Is it really an one-or-the-other condition or more of a continuum where
OO is on one end and DP is on the other.
(3) If it is either/or, then if you have a program that is in need of
refactoring because of a bad code smell, does that mean it is DP?
|