Re: OO Design induces an existential crisis



Nick Malik [Microsoft] wrote:
> > Even if they are really the same, they don't show WHY they are better
> > than p/r versions outside of systems software and device drivers. You
> > keep dancing around this gap instead of facing it.
>
> I did no such thing. You introduced this notion in the earlier part of the
> discussion, after bashing OO on the basis that there is no consistent way to
> write OO code. I am sticking to the point. This notion can be dealt with
> in a different response.

You are right, I lost sight of the sub-topic there: consistency. Well,
I don't see how those principles guarentee consistency. Some of them
may actually conflict in less trivial examples. I don't currently have
any examples of them conflicting, I have to admit, but you have not
shown conflicts in my list either.

And, some of the are vague, such as Open-Closed Principle. The example
shown is typical case-statement bashing. One can show that case
statements like that can make it easier to add new behavior/operations
without having to change existing modules (or at least less modules
than poly). And like I always fuss about, "sub-types" are a fragile
modeling technique in my domain. Sub-type based examples need even more
overhauling if sub-types "degenerate".

OC could possibly "fix" some of them by simply extending and extending
via sub-classing. However, sub-classing may not lead to proper
factoring. If you cannot "open" other classes, you cannot share the
code because one may have to move the method higher up the tree, or
move it to a different node on the tree and reshuffle the hierarchy.

Here is an example class hierarchy where the indentation level
indicates tree level:

A
--A1
----A11 needs method B
--A2 has method B

Later into the project it turns out that class A11 needs method B, but
still uses other methods found only in A1. Thus, we cannot put A11
under A2 but have to refactor the tree. You either have to duplicate B,
change the interface to A and it's children's interface (which requires
"opening"), move ("open") the other methods in A11 to B, and/or change
("open") A2.

Thus, OC can objectively conflict with duplication factoring for
certain sets of changes. Or is factoring out duplication NOT one of
your principles? You can avoid a lot of "problems" if you simply allow
duplication, but few want to endorse duplication you will find out.

>
> >> One more chance.
> >>
> >> Provide a link to a single site that describes a fairly complete set of
> >> guiding principles for procedural software development.
> >
> > Again, here are the basic principles:
> >
> > 1. Use the RDB for noun modeling, apply the usual normalization rules
> > to factor out duplication.
> > 2. Divide software into relatively independent tasks that communicate
> > mostly through the database.
> > 3. Factor[1] intra-task commonalities into intra-task subroutines.
> > 4. Factor[1] inter-task commonalities into inter-task shared libraries.
> > 5. Use top-down "controllers" for batch jobs and event-driven
> > controllers/frameworks for interactive apps.
> > 6. Consider factoring repeating case statement lists or IF conditions
> > into tables if they are likely to stay similar over the long run. (The
> > long-run estimation is a judgement-call based on experience.)
> >
> > [1] A variation can be found in the Factoring Threashold: the number of
> > times something repeats before being factored. Some companies like high
> > numbers, others like low numbers.
> >
> > If you can show me a flaw in these principles, please do.
>
>
> I would, if these were principles. They are not.
>
> The American Heritage dictionary defines principle as "1. A basic truth,
> law, or assumption 2. (a) a rule or standard, especially of good behavior,
> (b) the collectivity of moral or ethical standards or judgements 3. a fixed
> or predetermined policy or mode of action 4. A basic or essential quality or
> element determining intrinsic nature or characteristic behavior"
>
> Look to definition #4. A basic or essential quality [] determining
> intrinsic nature or characteristic behavior
>
> Your list is a set of practices to apply to a problem. You have outlined
> them in a prior message on this thread. However, you do not point to a set
> of principles that leads to these practices. In other words, you have told
> me "what" to do, but not "why" to do it, or "how" to judge that what I've
> done is correct.

Neither have you. IIRC, Open-Closed is in part based on Meyer's "single
choice principle", which is used against case statement lists, but
fails to use it against duplicate "lists" of methods in a class even
though it requires multiple visits to add new methods, the stated
reason for avoiding "duplicate lists". If one type of duplication is
bad but another is good, he failed to clarify *why*.

As far as why those p/r principles work, I don't fully know nor claim
to fully know. They just do. Part if the benefit is from a general
principle called "divide and conquer". The RDB and/or table engines
focus on and standardize collection-oriented issues allowing the coding
part to focus mostly on one task at a time without worries about
taxonomies etc in code. OO tends to reinvent collection-orientation
from scratch for each and every class, creating duplicate interface
patterns because otherwise encapsulation is violated. Encapsulation
actually CAUSES interface duplication. Thus, you get things like getX,
findX, deleteX, listX, getY, findY, deleteY, listY, getZ......over and
over and over again.

>
> You seem to be having a hard time understanding the question.
>
> I would expect you to respond with a site, where a thoughtful person (other
> than yourself) describes the individual qualities that a well developed
> procedural application would exhibit. RM describes the principles of
> "Single Responsibility," "Open Closed", "Substitution", "Dependency
> Inversion", etc. He made a very good case, in another thread, that the
> quality of an OO application can be judged on the basis of how well an app
> follows each principle, independently of the others.

I have shown how Open Closed is flawed (as stated), and have addressed
the others in the past. They are flawed, or at least rely on dogmatic,
unproven, or change-pattern-biased givens.

>
> Just as I can judge a particular type of apple on its color, its size, its
> sugar content, and its lack of pests (each independently of the others), I
> can also judge an OO application on the basis of how well it presents the
> quality of dependency inversion and single responsibility, seperately from
> the others.
>
> If you still do not understand the question, please say so.
>
> Otherwise, please respond with a link to a description of the consistent
> principles that a procedural application will follow. The page or set of
> pages will contain a coherent description of a finite set of principles.
> Each principle will have a name. Each will be described in a way that it
> can be understood and evaluated to exist (in the code) independently of the
> others.

Let me give it a start:

1. Avoid hard-wiring taxonomies/classification-systems in code because
it makes the code harder to manage and change. The only consistent
exception is a small hierarhcial task-break-down in old-fashioned
top-down style per each event or task.

2. Use a "collection oriented engine/interface" to deal with most
collection-oriented issues rather than roll-your-own. Otherwise, you
will keep reinventing the wheel.

>
> I did a little digging and didn't find one. However, this is not my point
> to prove. I've done my part. I'm waiting for you to do yours.
>
> If you cannot show principles of procedural development, then I would say
> that you have proven that your charge ("OO cannot be consistently applied")
> is completely baseless and I would expect you to retract that statement,
> both here and from your web site.

In summary, even the authors of those principles don't apply them
consistently, as sub-type-meltdowns and adding new operations show.
And, as a group they may conflict, as OC can with duplication
factoring.

Here is another principle that appears to be a truism so far:

OO defenenders cannot excape dealing with change probabilities no
matter how hard they try.

>
> The undeniable fact that OO has often been practiced by poorly trained
> individuals does not mean that it cannot be consistently applied.
>
> --
> --- Nick Malik [Microsoft]

-T-
Happily busting OOP lies for the good of humanity and oppressed IT
workers.

.

Relevant Pages

  • Re: Simples Rules make creating Big Balls of Mud impossible.
    ... would be lack of duplication at every level. ... This was one of Kent Beck's ideas back in 1998. ... I don't think there are any Kantian a priori principles. ... Different developers have different specialties ...
    (comp.object)
  • Re: OO Design induces an existential crisis
    ... > You are one of the few OO defenders who claim OO is consistent across ... p/r is not objectively worse for custom business ... >> and rational use of OO principles will create well-formed OO applications ... Two talented designers, having not ...
    (comp.object)
  • Re: Torkel Franzen on truth
    ... etc. Deriving what follows from those principles. ... Humans believe that PA is consistent. ... rely on mathematical principles that go beyond PA. ... "Human abilities surpass those of any machine" ...
    (sci.logic)
  • Re: OO Design induces an existential crisis
    ... > I asked for a single statement of principles for procedural development ... Two talented designers, having not ... That is as consistent as you can get in software. ... change-friendly than a p/r version. ...
    (comp.object)
  • Re: How about some principles people?
    ... >> If you care about truth, be principled and consistent. ... >> you are nothing but a partisan shrill and hack that aren't worth the ... > If you want principles, consistency and truth, you came to the wrong ...
    (alt.politics.bush)