Re: Variations and Reuse

topmind a écrit :
Nick Malik [Microsoft] wrote:

"topmind" <topmind@xxxxxxxxxxxxxxxx> wrote in message
news:1152341729.589349.186060@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


(snip)

It ain't pretty, but I have not found something better.

20 years since the publishing of the Design patterns book and hundreds of
books and courses and practical descriptions that have followed. If you
have not found, you have not looked.


With enough layers and combinations of design patterns I am sure it is
possible. However, I am skeptical it would be an obvious improvement.

according on which metrics ?

Replacing mess A with mess B is not a "solution".

Why should A or B be a "mess" ?

Anyway, if "mess B" is such that it allows to modify most parts of the "mess" (preferably the one that are the most susceptible to change) indendently while "mess A" fails to do so, then "mess B" would IMHO qualify as an improvement upon ""mess A". IOW, it's not about totally eliminating complexity (which seems a bit utopic), but about managing it. And managing complexity can sometimes add complexity.

Another solution somebody once offered looked kind of like a "rules
database",

Hard to tell without a better description or definition, but it seems that if rules are somewhat ad-hoc and tends to change frequently (which is the common case for business apps), then "kind of like a rules database" could looks like a sensible solution - and probably an "obvious improvement" upon hard-coded rules...

but it was really just more or less an implementation of
80's style Expert Systems. The GOF solutions thus appear to either
reinvent a database or an Expert System.

Care to explain yourself ? With actual references to similarities/parallels between (named) GOF pattern(s) and (named) databases or "expert" systems ?

One might as well skip the OO
middle-man and use an ES and/or a database with scripts. But even those
are not significantly better than a bunch of IF statements.

according to which metrics ?

When most of the regularity is factored to functions the database (such
as attribute/feature assignments), the IRRegularity is left over. It is
like mining for anti-gold: you process the soil and the soil goes down
the pipes, leaving the anti-gold behind in the pan. That is what the IF
statements are. You can only pump so much regularity out of irregular
domain rules.

Of course - what led you to believe in a total eradication of explicit branching ? The goal is to remove as much explicit branching as possible from parts that are the most subjects to frequent (and somewhat arbitrary) changes. And there are of course very few one-size-fits-all solutions to the problem...

An Expert System is just IF statements stored in a
database. I don't reallly have a problem with that, but it does not
really change the nature of the beast.

A branch is a branch is a branch, eh ?

A graph is a graph, and graphs are inharently messy. GOF is not going
to magically make them "clean". We can use many-to-many tables to
meta-tize such graphs in order to study and sift them better, but again
this is just a relational form of 80's technology Expert Systems.

To summarize, since any form of polymorphism or rule system is really just branching somehow, you propose to stick with hard-coding huge, deeply nested if/cases statements ?

.

Relevant Pages