Re: Booch's book feels too philosophical rather than practical?


Robert Martin wrote:
On 2007-01-24 15:04:05 -0600, "topmind" <topmind@xxxxxxxxxxxxxxxx> said:


Robert Martin wrote:
On 2007-01-23 15:02:42 -0600, "topmind" <topmind@xxxxxxxxxxxxxxxx> said:

Robert Martin wrote:
Procedural programming allows you to add new functions without changing
the existing data structures. OO allows you to add new data structures
without changing the existing functions. You need both capabilities.

You mean adding functions and "subtypes" without changing existing
code?

Sometimes you have functions that can deal with many different kinds of
data structures. Often these functions will have a switch/case
statement in them for the parts of those data structures that vary.
You can add new functions any time you like, without having to make any
changes to the data structures.

"Kinds" of data structures? I use tables (given a choice). There is
only one kind for relational fans (and maybe maps for small local
things). You are trying to sell refridgerators to eskimos.

Yes, "Kinds" of data structures. You know, like: Order, Invoice,
LineItem, Customer, etc. Each of these is a different kind of data
structure. The fact that they can be represented in a table or an
object or XML, or the tiny vibrations of the eyelids of a tree toad is
irrelevant.

It is relavent. Some are more powerful than others. If you ONLY use
them as dumb storage, then they could be viewed as interchangable. A
car can store gas and a trash-can can store gas. However, that does
not mean that the *potential* utility of a garbage can and a car are
the same.


OO gives you the opposite ability. Sometimes you have functions that
deal with with a particular kind of data structure. Often these data
structures have variants. If you treat them as OO subclasses then you
can add new variant data structures any time you like without having to
make any changes to the existing functions.

There are table-driven ways to do such and even file-driven ways.

Of course. OO just hides these techniques behind a language syntax.

The difference is minor, and like I describe in a nearby message, the
OO approach locks you into mutual-exclusiveness.

And as I described in a follow up message: "No it doesn't." Any
operation can be bundled into an object and handled by a composite
object (e.g. a Set). The whole "mutual-exclusive hierarchy" argument
is a red-herring.

Yes, but you did not *start out* that way. To get the needed
flexibility, you are slowly reinventing a navigational database bit by
bit.


As I demonstrated in my response to your SavingsAccount vs
CheckingAccount example, it is trivially easy to create accounts that
have both Savings and Checking rules, and any other rules you wish,
even when you didn't know this was going to be necessary before you
started. (And, no, I'm not talking about multiple inheritance).

If I remember correctly, I debunked that already. You are NOT going
to be able to match the simplicity of the feature table without
building I messy little OO contraption.

If we take the feature table from this:

http://www.geocities.com/tablizer/bank.htm

And make code like this:

function process(accountID) {
rs=query("select * from account where accountID=" . accountID);
while(row=nextRow(rs)) {
if row.hasFeature1 {....}
if row.hasFeature2 {....}
if row.hasFeature3 {....}
if row.hasFeature4 {....}
if row.hasFeature5 {....}
if row.hasFeature6 {....}
if row.hasFeature7 {....}
if row.hasFeature8 {....}
if row.hasFeature9 {....}
if row.hasFeature10 {....}
}
...
}

It can handle any combination of those features. If you subclass to
get it, then you would have to make a combinatorial explosion of
classes to get every possible combination.


I don't find a
practical need for such very often in biz apps, though.

I have seen you make that startling statement many times. I make use
of this ability of OO all the time in business applications. Perhaps
we just have very different world views.

I guess so. OO'ers see hierarchies and M.E. lists where I see sets.

No, I wouldn't put it that way at all. OO'ers see dependency breaks,
and the need for isolated modules and information hiding. OO'ers see
the need to separate detail from policy, and make sure policy does not
depend on detail.

You are going into buzzword mode again. Without any clear definition
or ways to measure these, they are not usable, communicatable
distinctions.


I
could force domain nouns into taxonomies, but they are artificial and
have many change spike problems. Your "employee types" as described in
my review of your book is a pretty good example of this.

Actually it's not, because the book doesn't talk about types of
employees. It talks about different types of payment classifications.

Same diff in this case.

This allows an Employee object to hold a referent to a
paymentClassification object. If the employee falls into a category
that isn't mutually exclusive, he'll just hold more than one
paymentClassification.

Yes, but you didn't build that up-front. You would have to alter your
design. As a rule of thumb, I avoid hard-wiring M.E. up-front, or at
least make it easy to escape. To use your own lingo, I "decouple" my
design from dependence on M.E. existing.

And, of course, we'd use the composite pattern
to implement that so that the Employee has no idea that it has more
than one payment classification.

You didn't use composit. You had to significantly change your design
to add it.


And a real one
witnessed by me: rank and file employees got sales commissions. It is
not a change I dreamed up.

Understood, and easily handled using the above common technique.

I challenge you to produce a half-dozen biz taxonomies where ME or
trees are a safe bet. Just list the taxonomies in outline format:

It's not about taxonomies. It's about dependency inversion. But what
the heck, I'll just use one from your own example plus a few more off
the top of my head.

AccountPolicy
SavingsPolicy
CheckingPolicy

Those are features that are not necessarily mutually-exclusive as
described in the link.


StateWithholdingCalculator
IowaWithholdingCalculator
MississippiWithholdingCalculator

Possible. I would need more details to see if the differences couldn't
be partly or entirely table-driven.


BillingSchedule
WeeklyBillingSchedule
FullMoonBillingSchedule

Those are also features. If there are a lot, one should not hard-wire
them into code.


MediaReturnPolicy
BookReturnPolicy
CDReturnPolicy

Books and CD's come bundled together in many cases. Computer books do
it a lot. Besides, it may not be a good idea hard-wire media
categories into the code. They should be table-driven so that the code
does not have to know about a given "media type" and such that an
operator or administrator can add them instead of a programmer.


WebPageController
BookReturnController
CDReturnController

Huh? Please clarify.


EmployeeDatabase
OracleEmployeeDatabase
InRamEmployeeDatabase

Huh huh, these are not necessarily mutually-exclusive either. You are
stuck in M.E. thinking. Did OO do that to you, or did your ME thinking
lead you to OO?


But you forgot to mention another change pattern: loss of mutual
exclusiveness. If 2+ options change to no longer be mutually exclusive,
then procedural fairs better. It is a smaller change: just change the
CASE to IF statements. With polymorphism you have to move code to
different named modules, and I give that a much higher change cost
score.

On the contrary the the change in an OO program is remarkably simple.
One simply puts the objects that represent the non-exclusive options
into a composite.

That is not a simple change compared to p/r.

Really? I think it is. A few lines of code at the most.

And how hard it is to make the p/r change? How many case statements
have to be turned into if statements? Where are they all? Are they
all really nicely formed as case statements?

Why would multiple similar case statements be needed in that case?


Plus, in the real world
the DB already has the necessary "structures". Repeating them in the
app language is double duty.

If you mean copying the data out of the "table" format into a java data
structure, then I disagree. First, any such copying is done once in a
very low level place. Second it has to be done in any case since the
data often needs to move into convenience variables.

A java data structure is not a "convenience variable". RDB-centric
applications tend to join multiple tables in one query (a "flat"
result set) to avoid having to create one-to-many or many-to-many
structures in app code. (And if they are needed, I prefer local/temp
tables, if the lang/tool supports them.)


I find it easier to manage taxonomies in tables than in code (if they
are small and local, then it does not impact the argument either way
except that procedural is easier for local stuff IMO). It is hard to
search, sort, and sift code. Plus, normalization rules produce more
consistency rather than every OO fan invent their own.

There are rules for object construction just as there are normal forms
for relational tables. And there are people who follow those rules and
people who don't in both cases.

There are many ways to make one-to-many and many-to-many relationships
in OO. There is generally one and only one in relational.


OO has *no* real normalization rules so far.

OO is not a data storage technique. OO is a data *manipulation*
technique.

Again again again again, DB's are NOT just about "storage".

And there *are* indeed rules.

Such as?


It is shanty town
building. Relational has "building codes".

Tsk tsk. The metaphorical pejoratives are falling like rain.

Thus, relational gives me
the power of sets to manage noun "taxonomies", and the consistency of
normalization, and the built-in collection handling abilities. OO
lacks.

OO gives you the dependency management, isolation, and encapsulation
tecniques that relational lacks.

Buzzwords with no real metric.


I think you believe that programming paradigms are a mutually exclusive
taxonomy. They aren't. You can use OO and Relational together quite
nicely; and it makes for better systems.

Prove it with code and change scenarios, not buzzwords.

(I thot I replied to this message already, but don't see it.)



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

-T-

.

Relevant Pages

  • Re: Boochs book feels too philosophical rather than practical?
    ... OO allows you to add new data structures ... It talks about different types of payment classifications. ... This allows an Employee object to hold a referent to a paymentClassification object. ... Just list the taxonomies in outline format: ...
    (comp.object)
  • Re: Critique of Robert C. Martins "Agile Principles, Patterns, and Practices"
    ... every different way you might need to fetch employee data? ... Your solution would cause extra roundtrips to the database for fetching ... implementaiton of the SQL statement without affecting the functions ... There is no need for passing data structures around the application. ...
    (comp.object)
  • Side by Side Worksheet Functions
    ... you may post some example data (if both data structures ... >I have 2 long user info extracts which I need to compare ... an HR database. ... or registered (new employee not ...
    (microsoft.public.excel.worksheet.functions)
  • 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: OO Concepts and C# Properties
    ... >have been advocating data structures as a bad smell. ... // class Location, struct Address ... //class Point, struct XYPoint ... Employee e = new Employee; ...
    (comp.object)