Re: OO Design induces an existential crisis



>
> > The "Just list candidate classes" line reminds me of Nijinksy's "I
> > just leap and stop in midair". Figuring out the candidate classes
> > is hell for me.
>
> Analysis paralysis? I suffered from this terribly for a while. OO gives
> you many choices and you freeze up trying to figure out which is best.
>
> A: The best choice is to figure out how your clients will use the object
> and go from there. Don't worry about being right/best. Worry about
> working, worry about writing tests that prove its working, then worry
> about improving. Its a bit like my father always says: "Look after today
> and tomorrow looks after itself :-".
>
> > Or I should put it differently: when I look at
> > the "candidate classes" that OO experts come up with I am utterly
> > mystified, like someone who just saw an elephant being pulled out
> > of a hat.
>
> OO experts aren't always right. Or at least they're solving something
> slightly different than what you need, which can make a big difference.
> Sure there is creativity there, and you don't see how they made that
> leap, but they got that creativity by trial and error and practice, just
> as you will.

Inconsistency is one of the biggest problems with OO today. There are
no guiding design principles that anybody agrees on. Different
"experts" just keeping creating and tinkering with classes until the
damned thing runs. If the original author leaves, the newcomers are
stuck with a big soup of tangled classes that don't necessarily fit
their own OO techniques.

Procedural with a RDBMS has proven relatively simple, easy to learn,
easy to relate to, easy to navigate, relatively consistent, and is not
objectively worse than OO. It basically follows these principles:

1. The "noun model" goes in the RDBMS, not in code.
2. Group code by tasks
3. Factor commonalities into libraries
4. Use mostly the DB or tables to communicate between tasks
5. Let a menu-framework or event-driven GUI framework tie the
events/tasks together (if app has a UI).

(I don't claim it works for all domains.)

>
> Might read up on patterns. Patterns are shorthand for prior creative
> ideas. Know your patterns and most things things are just one-offs or
> combinations of them. If you can "see" patterns in the problem, you'll be
> creative.

Nobody can agree on when and what patterns to use. All paradigms have
patterns. Patterns are not unique to OO. OO just spends more time
trying to document them because nobody has any better ideas for
cleaning up sea-of-classes messes.

>
> > My first recollection of this is when I learned about the general
> > MVC idea for the first time. I understood the scheme right away,
> > but I was (and remain) puzzled/amazed that anyone could have come
> > up with that particular way to break up the problem. But that's
> > not the worst of it, since, who knows, maybe after thinking about
> > the problem for some time I could have come up with something
> > remotely resembling the MVC classes. But I am *certain* that not
> > in a MILLION YEARS would I have been able to come up with the
> > particular set of "responsibilities" for these classes that
> > characterizes the MVC scheme. (I'm using the term "responsibilities"
> > losely to refer to both "who does what", and "who *knows* what".)

Event-driven GUI engines are superior to MVC in my opinion. (Then
again, what is a "controller" is so vague that MVC can perhaps be seen
as an approach to impliment event-driven frameworks.)

This is why Visual-Basic, despite many flaws, kicked SmallTalk's MVC
*** in the marketplace. SmallTalk had all the GUI wind and hype behind
it, but was flattened by a better, simpler idea. (SmallTalker's claim
it was because ST's price tag was too high, but there was enough GUI
enthusiasm that this alone would not stop big companies from paying.
People paid double for MACs compared to PC's because of the GUI back
then, I would note.)

-T-

.