Re: OO is the new Go-To (was: Biz Tree Challenge)


Robert Martin wrote:
On 2007-01-26 17:50:54 -0600, "topmind" <topmind@xxxxxxxxxxxxxxxx> said:


Robert Martin wrote:
On 2007-01-26 11:35:26 -0600, "topmind" <topmind@xxxxxxxxxxxxxxxx> said:

It is OO
evangalists like Robert Martin and Fowler and Meyer that owe us better
evidence.

And we have presented it. We have written articles, blogs, net
postings, books, etc. We have given seminars, tutorials, user-group
talks, etc.

No, you have not.

Yes we have.

Your comparative evidence is weak.

No it's not. (I can keep this up as long as you can.)

Good comparative evidence would (at least) use numeric metrics. For
example, "solution A required changing 40% more lines of code and 32%
more tokens (as defined in attachment Foo) than solution B for change
scenario X.".


Typical problems
include:

1. Vague metrics

You mean like the value of CNF6?

Most only go to normal form 3. Normal forms are simply *tips* for
removing duplication. Only 1 thru 3 directly remove duplication IIRC.
Those higher than 3 are not really about duplication.

It is easier to spot duplication in schemas than in class designs,
partly because the rules and conventions for "linking" entities is
more consistent.


2. Elevating the importance/frequency of OO-favoring change scenarios
without justification or ignoring counter change scenarios.

OO facilitates certain kinds of changes. Procedural programming
facilitates other kinds of changes. Specifically OO makes it easy to
add new data structures to existing functions without changing the
functions whereas procedural makes it easy to add new functions to
existing data structures without changing the data structures.

I tend to use tables as my "data structures". Show me how OO
facilitates "adding" this for apps. And, please, not another wrapping/
device-driver fight. I reject that because changing the implementation
of the "data structure" is not that common in practice. OO is obsessed
with such swapping; probably because it is the only thing it can do
well. It is like W bragging about the economy because it is the only
thing he has not entirely driven into the ground (yet).

The two
forms of change are complementary. Good designers will choose the kind
of change they want to facillitate and use the appropriate paradigm for
that kind of change. This kind of decision happens over and over again
in many different small parts of a system. So a system will have some
OO parts and some procedural parts.

So, no. We don't elevate the importance of OO-favoring change
scenarios. We present tools for dealing with ALL change scenarios.

I can find a fair amount that have a greater impact on your code than
mine. Your sales/salary dichotomy, for one.


3. Not providing p/r code for comparison

That's been done lots of times.

Only shape, animal, and device drivers. Or case statements that should
be tablized instead.


4. Using lame p/r or limited languages to paint all of p/r

Ah, so now we have p/r and "lame" p/r. Can you exlain the difference?

Some that come to mind:

* Lack of native string handling
* Lack of maps (associative arrays)
* Lack of named parameters
* Lack of nested functions (or dynamic scope)
* The archaic C-style "break" statement in Switch.
* Lack of dynamic typing


--
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx

-T-

.

Relevant Pages

  • Re: OO is the new Go-To (was: Biz Tree Challenge)
    ... evangalists like Robert Martin and Fowler and Meyer that owe us better ... Procedural programming facilitates other kinds of changes. ... Specifically OO makes it easy to add new data structures to existing functions without changing the functions whereas procedural makes it easy to add new functions to existing data structures without changing the data structures. ... We don't elevate the importance of OO-favoring change scenarios. ...
    (comp.object)
  • Re: OO is the new Go-To (was: Biz Tree Challenge)
    ... evangalists like Robert Martin and Fowler and Meyer that owe us better ... Your comparative evidence is weak. ... Elevating the importance/frequency of OO-favoring change scenarios ... Using lame p/r or limited languages to paint all of p/r ...
    (comp.object)
  • Re: Boochs book feels too philosophical rather than practical?
    ... Robert Martin wrote: ... shapes and lists of operations on those shapes. ... duplication of one list you introduce duplication of another. ... There are indeed two lists. ...
    (comp.object)
  • Re: Boochs book feels too philosophical rather than practical?
    ... Robert Martin wrote: ... OO allows you to add new data structures ... I challenge you to produce a half-dozen biz taxonomies where ME or ... OO has *no* real normalization rules so far. ...
    (comp.object)
  • Re: How to motivate use of OO?
    ... Robert Martin wrote: ... not yet another case/switch statement battle. ... procedural code that OO is better at removing duplication from; ... fair using code that OO is good at removing duplication from. ...
    (comp.object)