Re: OO Design induces an existential crisis

In <fnbpc194knu1gih31ho79695k0q9ttk89v@xxxxxxx> Rick Elbers <rick.elbers@xxxxxxxxx> writes:

>Basics of OO design is that its all about semantics...

>Just list candidate classes from the domain you are working in for a
>project...

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. 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.

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".)

I can think of three possible explanations for this, in increasing
order of desirability:

1. The MVC scheme was just a stroke of genius (end of story, time
to find a new job).

2. The MVC scheme was the outcome of much blind trial and error;
after umpteen failed alternatives, *uncannily*, MVC proved to
be the best ("just trust us: it works; we are not sure exactly
why, but it works").

3. The MVC scheme is the logical consequence of a series of design
*principles* that, it just so happens, I don't yet know.

Of course, I hope the answer is 3, but after years of searching
(and reading more descriptions of MVC than one can shake a stick
at) I have yet to find what these principles are. And no, I'm not
referring to the boilerplate OO principles of abstraction,
encapsulation, inheritance, blah, blah, blah. One can follow
*these* principles religiously and *never* even *suspect* the
classes let alone the assignment of responsibilities that characterizes
MVC.

Here's one more, more mundane, example, which is occupying me at
the moment. I decided, by way of exercise, to design a collection
of classes to represent and manipulate graphs (as in vertices and
edges). Of the "candidate classes" I initially thought of, the
main ones were Vertex and Edge. These seemed like a no-brainer.
After all, mathematicians defined a graph as a set of vertices and
a set of edges between these vertices.

I wrote the tests, implemented the classes and wrote a few programs
with them, and they seem fine. But then I looked at a few standard
implementations of graph classes and was surprised to see that,
although *all* of them included an Edge class, not a single one of
them had a Vertex class! Moreover, all of them include a Graph
class, which I did not include because my Vertex class encapsulates
all the information (i.e. the vertex' neighbors) necessary to fully
describe the graph.

I can come up with possible explanations for why all these
implementations avoided using a Vertex class, but they are just
guesses. In reality, I have no clue.

As you can see, listing the candidate classes, and their
responsibilities, is, as far as I can tell, black magic.

>Don't go into details considering frameworks you
>use, just mention the classes/ responsibilities to be used with the
>responsibilities of your domain classes. Don't even try to mention
>methods of the framework classes.

It's interesting to read this, because even though lately I've made
a conscious effort, during the design stage, to stay as far away
as possible from specific implementation details, I still devote
much thought to the methods each class will support. The reasoning
goes like this: "it's taking me aeons to design these classes, so
at least let's design some halfway decent APIs *now*, and ***hope***
that, with enough *refactoring* I will (asymptotically) arrive at
adequate implementations for them." Of course, when I say I think
about these methods what I mean is that I think about their names
and their signatures, and how they complement each other, not about
their guts.

kj

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
.

Relevant Pages

  • Re: OO Design induces an existential crisis
    ... Figuring out the candidate classes ... I think you're trying to design like a seasoned veteran right from the ... Most people struggle severely with MVC. ... which I did not include because my Vertex class encapsulates ...
    (comp.object)
  • Re: OO Design induces an existential crisis
    ... Figuring out the candidate classes ... responsibilities... ... >remotely resembling the MVC classes. ... The MVC scheme is the logical consequence of a series of design ...
    (comp.object)
  • Re: OO Design induces an existential crisis
    ... Figuring out the candidate classes ... > remotely resembling the MVC classes. ... The MVC scheme is the logical consequence of a series of design ... > implementations of graph classes and was surprised to see that, ...
    (comp.object)
  • Re: OO Design induces an existential crisis
    ... I decided, by way of exercise, to design a collection ... Of the "candidate classes" I initially thought of, ... > implementations of graph classes and was surprised to see that, ... which I did not include because my Vertex class encapsulates ...
    (comp.object)
  • Re: ttk::checkbutton - I think, its a bug
    ... knowledge about MVC and similar designs, but it's clear too that you ... suggesting using <Destroy> for releasing the data associated with the ... binding on the widget (in order to destroy the data. ... On a MVC design, there are mechanisms for transfering the data from the ...
    (comp.lang.tcl)