On 9/6/05, James Britt <james_b at neurogami.com> wrote:
> <quote>
>> I'll explain the whys and wherefors in a moment, but here are some rules
> of thumb that you can apply to see if you're really looking at an
> object-oriented system:
>> 1. All data is private. Period. (This rule applies to all
> implementation details, not just the data.)
> 2. get and set functions are evil. (They're just elaborate ways to
> make the data public.)
> 3. Never ask an object for the information you need to do something;
> rather, ask the object that has the information to do the work for you.
> 4. It must be possible to make any change to the way an object is
> implemented, no matter how significant that change may be, by modifying
> the single class that defines that object.
> 5. All objects must provide their own UI.
>> If the system doesn't follow these rules, it isn't object-oriented. It's
> that simple. That's not to say non-object-oriented systems are bad;
> there are many perfectly good procedural systems in the world.
> Nonetheless, not exposing data is a fundamental principle of
> object-oriented systems. If you violate your principles, you're nothing,
> and the same goes for object-oriented systems. If a system violates
> object-oriented principles, it isn't object-oriented; it's some sort of
> weird hybrid that you may or may not ever get to work right.
>> </quote>
Crap. Don't listen to that drival. While the idea has merit up to a
limited scale it quickly turns into hell fire. And poos on SOC. Are
you really going to teach each object how to display itself in PDF,
XML, RDF, ASCII-Art, as infinitum. I don't think so. Your going to
convert it to ONE common format, say some nice YAML, and then write
Renders for that --is dumping YAML considered accessing public data?
Now for a _main_ intereface, say a GUI, sure that's reasonable, but if
you really want to get high class you'd use AOP to "weave" the
Rendering into the object, thus maintining SOC at the same time.
As usual balance is key. I'd be wary of anyone who makes ultimatiums
like: "If the system doesn't follow these rules, it isn't
object-oriented. It's that simple."
> So, does this suggest that if I want to render, say, an Account object
> in a Web page, I should do something like this:
>> <%= account.render( xhtml_form_builder ) %>
>> where xhtml_form_builder is some object that an Account instance knows
> how to manipulate without needing to know the specifics of the rendering
> environment?
Feasible. Is it really much different then an elaborate:
out = my_form_str % account.data_for_my_form_str
Granted template systems these day have embedded procedures to deal
with, but you get the idea.
T.