Prev: Practices for avoiding tight coupling?
Next: Funny Videos
From: adaworks on 2 Mar 2007 12:41

"topmind" <topmind(a)technologist.com> wrote in message
news:1169676210.817815.272770(a)s48g2000cws.googlegroups.com...
>
>
> Is your position:
>
> 1. Most taxonomies are best represented as trees (or mutually-exclusive
> list items).
> 2. Most taxonomies are best represented as sets.
> 3. Most taxonomies are best represented as graphs/networks.
> 4. Something else?
>
1) Set notation can be used to represent trees along with a lot of
other structures

2) An undirected graph is the parent of directed graphs, or which trees
are a subset. A network is a special kind of graph.

3) Taxonomy is another word for classification. In OOP, the
word class is short for classification set/classification hierarchy,
where a class is a special kind of Abstract Data Type, which,
when placed in a hierarchy with other members of that class,
can be organized into a hierarchy.

4) All of the above named structures are fundamentally containers.
Whether one likes OOP or not, it is useful, from a formal methods
perspective, to reason about the members of the set/hierarchy we
call a container class; it provides a good model for making decisions
in the development of complex software solutions.

5) Software development is rarely about either/or, black/white,
up/down decisions. It is, like most engineering processes, an
on-going evaluation of trade-offs and risk assessment. At some
point, after having made decisions relative to those trade-offs, we
decide on a development strategy, what tools to use, and what
validation and verification techniques will best ensure success.
Often, the choice is OOP. On other occasions, I might choose
a database generation tool. On still other projects, I might decide
to use a functional language such as OCAML or Haskell.

Software development varies according to a wide range of criteria.
There is no "one-size fits all" approach. Those who seek such an
approach are on a "fools errand." The arguments, "My dog is
better than your dog," are equally foolish. So are the arguments
that your dog is no good at all, and my dog is. What kind of dog
you like is your choice, and we would hope a choice that does not
result in your being mauled, being sued for someone else being
mauled, and can can satisfy whatever dog-need you might have.

Frederick Brooks admonition about the "silver bullet" still has
currency in software engineering.

Richard Riehle

"I invented the term object-oriented programming, and
I can tell you I did not have C++ in mind." Alan Kay


From: topmind on 2 Mar 2007 14:30

adaworks(a)sbcglobal.net wrote:
> "topmind" <topmind(a)technologist.com> wrote in message
> news:1169676210.817815.272770(a)s48g2000cws.googlegroups.com...
> >
> >
> > Is your position:
> >
> > 1. Most taxonomies are best represented as trees (or mutually-exclusive
> > list items).
> > 2. Most taxonomies are best represented as sets.
> > 3. Most taxonomies are best represented as graphs/networks.
> > 4. Something else?
> >
> 1) Set notation can be used to represent trees along with a lot of
> other structures

Yes, that is why they are flexible.

>
> 2) An undirected graph is the parent of directed graphs, or which trees
> are a subset. A network is a special kind of graph.
>
> 3) Taxonomy is another word for classification. In OOP, the
> word class is short for classification set/classification hierarchy,
> where a class is a special kind of Abstract Data Type, which,
> when placed in a hierarchy with other members of that class,
> can be organized into a hierarchy.

A hierarchy (tree) is not as flexible as sets in my opinion. I
already gave a link with examples IIRC.

>
> 4) All of the above named structures are fundamentally containers.
> Whether one likes OOP or not, it is useful, from a formal methods
> perspective, to reason about the members of the set/hierarchy we
> call a container class; it provides a good model for making decisions
> in the development of complex software solutions.

Saying something "is-a" container is kind of loaded. "Can be
represented as" I will agree with. However, "Is-a" is too strong a
statement. There are a lot of ways to represent or implement a given
concept. One can liken it to Turing Equivalency.

>
> 5) Software development is rarely about either/or, black/white,
> up/down decisions. It is, like most engineering processes, an
> on-going evaluation of trade-offs and risk assessment. At some
> point, after having made decisions relative to those trade-offs, we
> decide on a development strategy, what tools to use, and what
> validation and verification techniques will best ensure success.
> Often, the choice is OOP. On other occasions, I might choose
> a database generation tool. On still other projects, I might decide
> to use a functional language such as OCAML or Haskell.

For business domain entity/object classifications, using tree-based or
"is-a" classifciation is almost always problematic, or at least scale-
limiting. Product classifications and "feature lists" are best
represented up front as sets in my experience because in the longer
run that is where changes will lead you. And, the best set-engines
currently on the market are RDBMS.

If your organize the DB right, then most set selections come from
predicate algebra within the query such that one less likely has to
deal with such issues in the app code itself. OO tends to make the
code "shaped liked domain taxonomies". Using the RDBMS allows us to
DECOUPLE domain taxonomies/classification from the "shape" of the app
code. This is usually a good thing IMO. It simplifies the code and
allows a conceptual division of concepts.

One of the things that makes OOP software a mess is that it mixes
domain "structures" and code management issues together such that it
is hard to know where one starts and one ends. OOP software tends to
be like a person with a multiple personality disability. You cannot
tell what the division criteria (if there is one) is without reading
just about every last class.

>
> Software development varies according to a wide range of criteria.
> There is no "one-size fits all" approach. Those who seek such an
> approach are on a "fools errand." The arguments, "My dog is
> better than your dog," are equally foolish. So are the arguments
> that your dog is no good at all, and my dog is. What kind of dog
> you like is your choice, and we would hope a choice that does not
> result in your being mauled, being sued for someone else being
> mauled, and can can satisfy whatever dog-need you might have.

If you cannot predict the future well, then sets are a "safe bet". I
am not saying "one size fits all", but rather one size is the safest
gamble over the longer run for domain product/feature classification.

>
> Frederick Brooks admonition about the "silver bullet" still has
> currency in software engineering.
>
> Richard Riehle
>
> "I invented the term object-oriented programming, and
> I can tell you I did not have C++ in mind." Alan Kay

-T-

From: adaworks on 4 Mar 2007 13:41

"topmind" <topmind(a)technologist.com> wrote in message
news:1172863835.650730.44040(a)n33g2000cwc.googlegroups.com...
>
> adaworks(a)sbcglobal.net wrote:
>> "topmind" <topmind(a)technologist.com> wrote in message
>> news:1169676210.817815.272770(a)s48g2000cws.googlegroups.com...
>> >
>> >
>> > Is your position:
>> >
>> > 1. Most taxonomies are best represented as trees (or mutually-exclusive
>> > list items).
>> > 2. Most taxonomies are best represented as sets.
>> > 3. Most taxonomies are best represented as graphs/networks.
>> > 4. Something else?
>> >
>> 1) Set notation can be used to represent trees along with a lot of
>> other structures
>
> Yes, that is why they are flexible.
>
But difficult to represent graphically. Venn diagrams have their
uses, but also their limits. Trees often provide just the right view
of a set of relationships -- but I agree, not always.
>
> A hierarchy (tree) is not as flexible as sets in my opinion. I
> already gave a link with examples IIRC.
>
Flexibility does not always equate to clarity. More than one view
is necessary, in most cases.
>>
>> 4) All of the above named structures are fundamentally containers.
>> Whether one likes OOP or not, it is useful, from a formal methods
>> perspective, to reason about the members of the set/hierarchy we
>> call a container class; it provides a good model for making decisions
>> in the development of complex software solutions.
>
> Saying something "is-a" container is kind of loaded. "Can be
> represented as" I will agree with. However, "Is-a" is too strong a
> statement. There are a lot of ways to represent or implement a given
> concept. One can liken it to Turing Equivalency.
>
That is why many OOP developers now use the phrase, is_a_kind_of.
The issue is one of extensibility: being able to extend an existing class
(or, if you prefer, type) as a derived type.

A class is nothing more than a_kind_of abstract_data_type, which is nothing
more than a_kind_of_type. Well-formed classes simply extend the type
system. OOP allows for further extension of the classes.

Perhaps it is worthwhile to revisit this idea from the perspective of types.
A type,

1) has a name
2) a set of legal states
3) a set of defined behaviors
4) a set of rules vis a vis instances of other types

An abstract data type (ADT) is_a_kind_of type. It is usually
not predefined by the language. It has all the properties of a
type, but those properties are defined as extensions to the
language, usually built on top of predefined types.

A class is simply an ADT that has additional properties:

1) extensibility through inheritance
2) polymorphism
3) dynamic binding

The morphology of class instances may vary a bit. Sometimes
it involves dinstinguished receiver notation, but not always. Also,
interaction between class instances is more of a message-passing
mechanism, implied or explicit.

Sometimes a class/ADT can be parameterized. This is the template
or generic approach.

The class can be used as a building-block. It is not incompatible
with table methods, set-based methods, database methods, or
any other of the commonly used methods. Internally, a class can
benefit from old-fashioned structured methods.

This is so simple that I fail to understand how anyone can find
fault with the underlying model.

However, as noted earlier, even simple models can become complex
when misunderstood by those who use them. I cannot be responsible
for someone who fails to realize the need for a toque-wrench when
tightening the bolt on their oil pan. Good tools, even the best of
tools, are only as good as those who understand how to best use
them. This includes tables, flowcharts, types, ADT's, classes,
while loops, recursion, and simple assignment. It is easy to pick a
fight over any of those topics. But is serves little to advance the
progress of the discourse. Objects are a useful intellectual and
design tool. They are not the only tool, and need to used carefully
and by knowledgeable craftspersons. But this can be said, equally,
of any other software tool, software method, software practice.

Richard Riehle


From: topmind on 4 Mar 2007 15:19

adaworks(a)sbcglobal.net wrote:
> "topmind" <topmind(a)technologist.com> wrote in message
> news:1172863835.650730.44040(a)n33g2000cwc.googlegroups.com...
> >
> > adaworks(a)sbcglobal.net wrote:
> >> "topmind" <topmind(a)technologist.com> wrote in message
> >> news:1169676210.817815.272770(a)s48g2000cws.googlegroups.com...
> >> >
> >> >
> >> > Is your position:
> >> >
> >> > 1. Most taxonomies are best represented as trees (or mutually-exclusive
> >> > list items).
> >> > 2. Most taxonomies are best represented as sets.
> >> > 3. Most taxonomies are best represented as graphs/networks.
> >> > 4. Something else?
> >> >
> >> 1) Set notation can be used to represent trees along with a lot of
> >> other structures
> >
> > Yes, that is why they are flexible.
> >
> But difficult to represent graphically. Venn diagrams have their
> uses, but also their limits. Trees often provide just the right view
> of a set of relationships -- but I agree, not always.

To some extent I agree that sets can be difficult to conceptualize/
visualize. Trees and to a lessor extent DAG's are much more graphical
than sets. However, simplicity and power are somewhat at odds here.
Sets are flexible, but cost some congnative familiarity. But that is
why we have query languages and interactive tools to explore sets.
You get used to them after a while. They grow on you. OOP brags about
scalability, but trees/DAGs are crappy scalers such that you have a
BIGGER mess trying to bend trees to fit complexity than if you
embraced sets up front.

> >
> > A hierarchy (tree) is not as flexible as sets in my opinion. I
> > already gave a link with examples IIRC.
> >
> Flexibility does not always equate to clarity. More than one view
> is necessary, in most cases.
> >>
> >> 4) All of the above named structures are fundamentally containers.
> >> Whether one likes OOP or not, it is useful, from a formal methods
> >> perspective, to reason about the members of the set/hierarchy we
> >> call a container class; it provides a good model for making decisions
> >> in the development of complex software solutions.
> >
> > Saying something "is-a" container is kind of loaded. "Can be
> > represented as" I will agree with. However, "Is-a" is too strong a
> > statement. There are a lot of ways to represent or implement a given
> > concept. One can liken it to Turing Equivalency.
> >
> That is why many OOP developers now use the phrase, is_a_kind_of.
> The issue is one of extensibility: being able to extend an existing class
> (or, if you prefer, type) as a derived type.
>
> A class is nothing more than a_kind_of abstract_data_type, which is nothing
> more than a_kind_of_type. Well-formed classes simply extend the type
> system. OOP allows for further extension of the classes.
>
> Perhaps it is worthwhile to revisit this idea from the perspective of types.
> A type,
>
> 1) has a name
> 2) a set of legal states
> 3) a set of defined behaviors
> 4) a set of rules vis a vis instances of other types
>
> An abstract data type (ADT) is_a_kind_of type. It is usually
> not predefined by the language. It has all the properties of a
> type, but those properties are defined as extensions to the
> language, usually built on top of predefined types.
>
> A class is simply an ADT that has additional properties:
>
> 1) extensibility through inheritance
> 2) polymorphism
> 3) dynamic binding
>
> The morphology of class instances may vary a bit. Sometimes
> it involves dinstinguished receiver notation, but not always. Also,
> interaction between class instances is more of a message-passing
> mechanism, implied or explicit.
>
> Sometimes a class/ADT can be parameterized. This is the template
> or generic approach.
>
> The class can be used as a building-block. It is not incompatible
> with table methods, set-based methods, database methods, or
> any other of the commonly used methods. Internally, a class can
> benefit from old-fashioned structured methods.
>
> This is so simple that I fail to understand how anyone can find
> fault with the underlying model.

I agree it is simple, but just like trees and DAG's (above), they are
not as flexible.

>
> However, as noted earlier, even simple models can become complex
> when misunderstood by those who use them.

That is not why they are limited. Sets can represent more than trees
and DAGs can *without* duplication and refactoring. Sets better model
the real world because the real world has cycles and other things that
DAG's and trees can't do without duplication or refactoring. "Types"
are a rather artificial human construct. If you want to truly scale,
you have to resist the human instinct to go with the comfy. I've tried
to model biz things with trees and types. They simply do not bend as
well as sets. Sets are more forgiving to change: they don't favor
early levels over later levels and let something belong to zero or
many sets without complaint or rework. I think if you look at them,
you will see that sets are a superior choice once you get past their
difficult or learning curve to conceptualize. Trees/types are catchy,
but sets scale better.

> I cannot be responsible
> for someone who fails to realize the need for a toque-wrench when
> tightening the bolt on their oil pan. Good tools, even the best of
> tools, are only as good as those who understand how to best use
> them. This includes tables, flowcharts, types, ADT's, classes,
> while loops, recursion, and simple assignment. It is easy to pick a
> fight over any of those topics. But is serves little to advance the
> progress of the discourse. Objects are a useful intellectual and
> design tool. They are not the only tool, and need to used carefully
> and by knowledgeable craftspersons. But this can be said, equally,
> of any other software tool, software method, software practice.
>
> Richard Riehle

-T-

 | 
Pages: 1
Prev: Practices for avoiding tight coupling?
Next: Funny Videos