Re: OOP/OOD Philosophy

Michael Feathers wrote:
> krasicki wrote:
>
> > Not all Computer Scientists are successful with design objects. To be
> > successful, the individual using them must be able to think in very
> > abstract ways. Not everyone can and even when they can, corporate
> > policy and practice often make the effort impossible.
>
> I agree that it takes work, but I don't think that deep abstraction is
> involved.

I don't think deep abstraction is necessary either but the ability to
juggle, weigh, and formalize multiple, sometimes conflicting complex
ideas is. That's not something everyone can do and, quite frankly,
it's obvious.

> To me, object design is more like concretization. The steps
> are: 1)think of thing that can solve a problem for you, 2) think of a
> way to ask it to solve the problem 3) go inside the thing and solve
> the problem.

That's certainly one way to look at it but in the world of commercial
development it is closer to:

The company has bought a product or is orthodox about a methodology, or
is managed by raving idiots who have very short tempers and zero
patience. If you need the money you play the game.

The game is to design something that is reasonably functional under the
circumstances knowing full well that you stand a snowball's chance in
hell of running the gauntlet.

Design amounts to ensuring that the thing accurately processes the data
the client is responsible for. This is the minimum design criteria any
software engineer needs to accomplish.

The *problem* then becomes trying to jump through the hoops that are
usually political and sometimes insurmountable. Here, no design
methodology or tool exists - except maybe dance lessons.

I must add that on rare occasions you have the opportunity to start and
proceed with a blank slate but it is rare indeed.

> It's just a little different from the procedural mindset
> which is: 1) think of a way to solve the problem 3) solve the problem.

Well, the difference is really the difference in asking the easiest way
to get from here to there vs. asking how best to create discrete and
logically cohesive application framework components. And in the case
of the latter there is no one set *right* answer. Two children's
graphic applications may function identically yet be designed wholly
differently. This is not always obvious to the novice or even the
initiated.

And.

In some shops you aren't allowed to even think that there is another
way.

> The abstraction in OO is really all about thinking about a way to ask
> for a solution rather than leaping into a solution.

Sorry. That does not ring true.

>
> > This frustrating truth is largely responsible for the Extreme
> > *whathaveyou-usually-Programming* phenomenons. With a straight face,
> > these proponents assert that if design is not egalitarian and if
> > companies don't respect it then -snip, snip- out with it except for
> > perfunctory lip-service.
>
> How many XP teams have you worked with?

Why do you ask? The methodology is well-documented. It is considered
a lightweight methodology is it not. It cannot be lightweight unless
it is lighter somewhere. What is lighter? The sum programming is the
same, correct?

>
> > One cannot glibly 'think' in OOD, there isn't any such thing. OOD is
> > very hard work, time-consuming, expensive and easy to derail (just have
> > bottom-up activity happening in the background that pre-empts the
> > designers).
>
> It is like anything else. Hard when you start, but easier when you
> acclimate to it.

No. It is not a way of thinking because when you think about it it
makes no sense. A virtual rock in cyberspace can have methods attached
to it. A real-life rock can't and doesn't. In cyberspace there is
only the formal, there is no imagination that can override the
programmatic reality whimsically.

> I "think in OO" but I've been doing it for a long time.

Let's say you think you think in OO. When you're working software you
formalize your ideas to OO patterns.

cheers.

.

Relevant Pages

  • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
    ... The point is that different design methodologies can produce very ... What the methodology brings to the table is a synergy that allows ... so militantly and in so many ways as the OO paradigm. ... concerns in collaboration for Who, ...
    (comp.object)
  • Re: SETI Scientists Arent Searching for ET?
    ... SETI scientists hypothesize. ... "By "intelligent design" I mean to imply design beyond the laws of ... Creation, Evolution, & Modern Science, 2000 ... argues that scientific methodology unfairly restricts causal ...
    (talk.origins)
  • Re: Comparison and criteria of design quality
    ... > that problem by making it less of a value judgment. ... today one is dependent on applying the methodology de jour correctly. ... than it is to evaluate whether a particular design is good. ... >> superior to the author's satisfaction. ...
    (comp.object)
  • Re: Mapping (CoBOL) Methodologies to Problem Domains
    ... which the design is based and which provides the rationale for everything ... begrudge them their success, to the extent that they are successful. ... *Journeymen*, who do not deign to call ourselves Methodology Masters, ... The evolution of methodologies is the confluence of two sets of cycles. ...
    (comp.lang.cobol)
  • Re: Mapping (CoBOL) Methodologies to Problem Domains
    ... are not _these_ the Agile Iterations? ... which the design is based and which provides the rationale for everything are violated. ... begrudge them their success, to the extent that they are successful. ... *Journeymen*, who do not deign to call ourselves Methodology Masters, ...
    (comp.lang.cobol)