Re: Using STATIC

[Hans Boldt <boldt@xxxxxxxxxx>]

Joe Pluta wrote:
> Adding public methods to an interface means that your interface is not
> complete, and that you then cannot code to the interface.  Coding to the
> interface is the most basic benefit of OO programming, and anything that
> breaks that paradigm reduces the benefit.

What interface ever is "complete"?  Another advantage of OO is the
ability to make changes without touching existing class definitions.
  Indeed, you may not even be allowed to touch existing class
definitions!

Taking an existing class definition and changing the interface is a
fairly common pattern in OO design.  For example, you may have
objects belonging to several different classes (say coming from
several different 3rd party products).  By encapsulating these
objects into "adapter" classes, you make them appear to have the
same interface to your application.

> Mix-in classes scare me, personally, because I'd be tempted to use them to
> cover up my hierarchy mistakes <grin>.  But we could go 'round and 'round
> about those topics - pick the language that best suits your programming
> style and use it.  Java happens to fit mine quite nicely (if only subclasses
> inherited their own copy of static variables instead of sharing them with
> the superclass).

OK, you're used to Java programming.  Think of a mix-in as an
interface, but having concrete implementations of at least some of
its methods.

Sure, on the one hand, you may want to revisit the design of your
object hierarchy.  (A particular design decision is really only a
"mistake" in retrospect!)

But on the other hand, (as mentioned earlier), you might not have
control over that hierarchy, and the best you can do is implement an
"adapter" pattern.  Or, you just might not have the time to
re-engineer the existing class hierarchy.  Another advantage of OO
is often a gain in productivity.

> Unfortunately, mapping objects to rows is only a relatively small part of
> business applications.  Business applications are about performing actions
> based on the contents of that data, and often very different actions based
> on the content of a single field (or even a combination of fields in
> different files).  Trying to map these complex conditional actions to a
> fixed class hierarchy is quite difficult.

So what you're saying is that business applications tend to be too
complex for OO techniques?  I thought the whole idea of OO was that
procedural programming was not powerful enough for complex applications!

> Now, the concept of mix-in classes would actually make this easier.  Even a
> syntax like JavaScript, where you can add methods to an object dynamically,
> might be better for business programming.

I must admit, I've just never bothered learning JavaScript.  I just
haven't found a compelling use for it.  ;-)

Adding methods and attributes to objects dynamically is a handy
technique in the interpreted OO languages Python and Perl.  I'm not
sure if that would necessarily be better for business programming.
For effective business programming using OO, I think you'd be better
off just applying the OO "design patterns".

Cheers!  Hans