Re: Whose Fish?


Jordan Marr wrote:
I don't write drivers, but writing reusable frameworks is basically
the same, and I do write those all the time. The idea is, instead of
solving a problem once in a very app specific way, you abstract and
encapsulate the solution to the problem in a OO way that is reusable
for ANY problem (especially including business domain problems!).

"Reuse" has seemed to fall out of favor as a top claim of OOP.
("Making programs easier to change" seems to be the top claim by my
observation in many debates, closely followed by "models human
thinking better"[1].) Even OO proponents generally don't claim reuse
improvement much anymore. If you wish to show OO being better reuse,
be my guest.

These days every program consists of two or three parts:
Language Framework: the framework of preexisting *reusable* classes
provided by the language developer. This framework is OO and
excercises the *reuse* that I am touting.

User Frameworks: frameworks created by users. These can be pre-
existing frameworks that were created before the project that are
generic and abstract enough to be reused to solve the same kinds of
problems continually. An example would be a business framework that
encapsulates dealing with business validation rules. In my mind this
also includes the business domain layer, which can serve multiple apps
(but usually only serves one).

The Application itself: This is where the procedural programming
comes into play. This layer calls upon all the framework objects it
needs to solve the needs of the application at hand.
When I start an app I first check to see if the tools I need to solve
the problem already exist in the language framework. If I need more
tools, my next stop is to look in the public domain arena for well
abstracted classes that are generic enough to be resued in my app.
Finally, if none exist, I create my own reusable object.

As an example, say my app requires that I pick a random number between
1 and 10,000. First I would look to the language framework for a
random number generator (which .net has one already). An object
should have one purpose, and .net's random number generator does just
that.. this allows it to be used in many projects.

If a random generator did not exist, I would create my own reusable
random generator class, and then plug it into my app.

Now, what many non OO people would do is to write the random number
generator algorithm directly inside their application layer
somewhere... perhaps they parameterize it and put it in a method
somewhere, or even worse, maybe they integrate the algorithm right in
with the button even where it is required.

What is wrong with putting such in a function? An entire class is
overkill. Also, as far as reuse, I lean toward mix-and-match "helpers
instead of wrappers" because one-size-fits-all genericy is not a
realizable goal I've found out the hard way. More on this:

http://c2.com/cgi/wiki?HelpersInsteadOfWrappers


Sounds great. Now show the code and show how it kicks P/R's ***. I
finished my example with runnable source code (R. Martin's payroll).
Your turn. Verbal claims don't cut it here.

OK, but I don't really have anywhere to post it unless I simply post
the source here.

It's fairly easy to have your own web-log these days (if you don't
mind annoying ads).


Jordan

-T-

.