Dan Doel
9/3/2003 9:51:00 PM
Scott Thompson wrote:
> I read his articles after you posted your note. His ideas are
> certainly extreme and show a marked misunderstanding of the proper way
> to implement the MVC paradigm. For some reason he does a reasonable
> job of explaining that objects are bundles of capabilities (or
> responsibilities) then completely ignores that fact in presuming that
> a Model object in an MVC world is simply a bundle of data with a bunch
> of getter's and setter's.
>
> Sure... if you design your model objects to violate encapsulation then
> your system is not very Object Oriented (presuming, of course, that
> you accept encapsulation as a tenet defining Object Oriented-ness).
> But if your model, view, and controller objects are designed as
> objects, following the proper definition of object, how could you
> reasonably make the claim that the system is other than Object Oriented?
>
> There are some valuable ideas in those articles... but some very poor
> ones as well.
I haven't finished reading all the articles yet (I'm on the second).
However, I get the impression that he
doesn't expect the ideas he presents to be used in all general
contexts. For example, if you're designing
the standard library for some language, the String class needs to be
used in many different ways. However,
the only way to have the string able to visually display itself is to
couple String with a complete GUI
library. Each GUI library would have to have its own implementation of
String which displayed itself
in accord with the components of that library, and Strings from
different libraries wouldn't be interchangable.
That's not to mention that you might want to either display a string, or
display something that allows a
string to be inputted (is that a word?). Thus, giving String visual
display capabilities isn't really the domain
his advice concerns itself with.
Rather, he's talking about the design of object oriented programs that
do something. If you're designing
a chess game, and have a Knight class, there's no reason to make that
class interchangable with a
Knight class from a fantasy role-playing game. Thus, you know how the
Knight class will represent
itself in that context, and can make it specific to its intened context.
As another example, suppose you're desgning a text editor. You could
have a text area that the
user enters stuff into, and then the program queries the text editor for
the underlying String and does
things with it. However, this isn't very object oriented (he'd argue).
You're using objects, but it's
not much different from
str = gets
result = process(str)
puts result
Which isn't really object oriented at all. What you really want is a
Text class that knows not only
how to display itself as a text area and accept user input, but knows
how to do everything that
your specific program might want to do with text. It's the difference
between:
str = text_area.underlying_string
str.gsub(/blah/, "")
text_area.underlying_string = str
and:
text_area.delete_word "blah"
Since you're writing the class for text_area, you know you'll need it.
As a nice summary, I'd say he's talking more about implementing object
oriented applications, and
less about writing frameworks with which object oriented applications
will be built, if that makes any
sense.
I could be totally off, I suppose, as I'm sure Holub is much more
experienced than I am. However,
I can't agree with many of his assertions unless I take them in the
light I discussed above. His
ideas don't make sense in many cases if you're trying to write general,
reusable, interchangable
libraries.
Somebody shoot me down if I'm wrong.
- Dan