How to motivate use of OO?
nass...@gmail.com
Yesterday I found myself in a peculiar situation. One of my friends
runs an Internet site with education-related information. The site is
written in ASP (VBScript), but now he has to rewrite the code in C#
because the web hosting company he uses are dropping ASP support.... So
this guy invited me over to explain OO to him - I've been working as
systems developer and architect for a while now...
So I explained the basics of OO to him, encapsulation, inheritance,
that kind of basic concepts.... Then after a while he said that he has
a nice structure in his old ASP code, so he thought the best way would
be to just convert the old function libraries (files) to classes with
static methods. Naturally I was horrified and told him he really
shouldn't do it, but instead build an object model and redesign the
solution. And then he asked me: WHY? It works great as it is, wouldn't
a new design just make things worse? And I really had NO answer to that
why...
So now I'm asking you people, what should I tell him? Why should he use
objects instead of plain functions? Please give me some good arguments
to use!!!
Ed Kirwan
> Hello all!
>
>
> So now I'm asking you people, what should I tell him? Why should he use
> objects instead of plain functions? Please give me some good arguments
> to use!!!
>
OO is good at managing change: changing requirements, changing products,
changing frameworks, changing configurations, even changing code for
bug-fixes.
OO is not a silver bullet; it is not true that, "Doing it in OO will
automatically make it better."
Your friend is in an enviable position: he has a full product developed
(his Internet site), has (I presume) a full history of its bug-fixes and
upgrades, and has a rough idea of a product road-map: what new features
he'd like to introduce in future.
Let's take two slight exaggerations to make the point:
Case A: The site is extremely stable, there have been no major bug-fixes
or new features introduced in recent years; the site just works; and
there are no major new features envisioned for the coming years. This
being the case, and presuming that the re-write in C# is
straight-forward [*], OO will have little to offer, and his functional
approach is better.
Case B: The site is not stable, there are new features added regularly
and plenty more to come. OO is a good choice.
[*] Re-writing any code in a manner which is at odds with intentions of
the language itself can be tricky, or at least verbose. C# is intended
for OO solutions, which means that it has some useful tools for handling
OO solutions; it can be used for non-OO solutions, but usually non-OO
languages will be better. So it's by no means certain that re-writing
the code using his existing structure will be significantly cheaper than
re-writing with OO in mind.
--
www.EdmundKirwan.com - Home of The Fractal Class Composition.
Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html
fre...@gmail.com
> objects instead of plain functions? Please give me some good arguments
> to use!!!
There is nothing wrong with using functions, but in some cases
classes/objects has some benefits.
If you are creating custom datatypes, like social-security number, it
might be good idea to hide the fact that the number is stored as a
string or integer (encapsulation). The user of the datatype onlys need
to know that he is using a social-security number. By making the
internal data private, you can force the user (programmer) to only
access the number by the methods you define. Using this you can be sure
that no illegal state transitions are made.
There are a number of other areas there encapsulation might be a good
idea like generic collection classes, GUI classes, device drivers.
But you also need to remember that there are other areas there
encapsulation does not have any benefits. For example, making a
customer class would probably have more disadvantages than benefits. In
this example, you would be forced to create a lot of getters/setters to
allow the users of the customer objects to manipulate the objects
states. You will probably end up with a classical data structure.
My experience is that for an average enterprise application, you will
probably use a lot of classes/objects from pre-built packages, but the
number of classes you define by yourself will probably be rather low.
Fredrik Bertilsson
http://frebe.php0h.com
fre...@gmail.com
> changing frameworks, changing configurations, even changing code for
> bug-fixes.
I think his friend need some better motivations for these claims. After
all, they are rather bold.
Fredrik Bertilsson
http://frebe.php0h.com
Ed Kirwan
I completely agree, Fredrik, and if his friend is willing to go into
some details of what he wants his software to do, I'd be happy to
provide a rough outline of a change-friendly solution, and give reasoned
argument for all decisions; then his friend is perfectly welcome to say,
"My site isn't going to change that much, so no thanks."
(I'm presuming his friend's site isn't 100,000 lines of code and
growing, of course; that would consume more time than I have available
between Open University on BBC Prime and, "American Choppers.")
Also, as a final note, OO isn't all-or-nothing; there's a grey-scale
between a fully functional program and an OO program. Take MVC: you
could write a largely functional Model, View, and Controller; but have
them each encapsulated behind Model, View, and Controller interfaces. A
gargantuan grain of encapsulation, admittedly, but it is possible. (This
is running with the idea that OO is flexibility through
variance-encapsulation.)
Frans Bouma
> Hello all!
>
> Yesterday I found myself in a peculiar situation. One of my friends
> runs an Internet site with education-related information. The site is
> written in ASP (VBScript), but now he has to rewrite the code in C#
> because the web hosting company he uses are dropping ASP support....
> So this guy invited me over to explain OO to him - I've been working
> as systems developer and architect for a while now...
>
> So I explained the basics of OO to him, encapsulation, inheritance,
> that kind of basic concepts.... Then after a while he said that he has
> a nice structure in his old ASP code, so he thought the best way would
> be to just convert the old function libraries (files) to classes with
> static methods. Naturally I was horrified and told him he really
> shouldn't do it, but instead build an object model and redesign the
> solution. And then he asked me: WHY? It works great as it is, wouldn't
> a new design just make things worse? And I really had NO answer to
> that why...
OOAD isn't a silver bullet which will make your program suddenly work
without bugs. It's just a tool which gives you some advantages over
other tools however has also disadvantages over other tools, it just
depends if your particular case/context benefits more from the
advantages of OOAD than the benefits of other techniques.
Against what some think/believe, it's not true that OOAD will be the
only way to create workable software. Similar to that others think that
OOAD is the root of all evil.
What ASP made so horrible is the runtime-checking of the code: it
would take a lot of time and testing to see that a page is correct.
However, if you reach the point where you can say: "no more syntax
mistakes at least", it is a proper technique to get a website up and
running and if the guy/girl who writes the code is very familiar with
ASP, why switch to something which will give the same net result: a
working website?
> So now I'm asking you people, what should I tell him? Why should he
> use objects instead of plain functions? Please give me some good
> arguments to use!!!
If a true craftsman can create exactly what you want with tool T, you
shouldn't recommend that craftsman to use tool U, just because YOU like
U more than T. After all, the craftsman is able to use T to produce
what you want.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Bruno Desthuilliers
(snip)
>, OO will have little to offer, and his functional
> approach is better.
s/functional/procedural/
(snip)
> Case B: The site is not stable, there are new features added regularly
> and plenty more to come. OO is a good choice.
s/is a good choice/can be a good choice/
(snip the rest - mostly agree)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'on...@xiludom.gro'.split('@')])"
fre...@gmail.com
> >> changing frameworks, changing configurations, even changing code for
> >> bug-fixes.
> >
> > I think his friend need some better motivations for these claims. After
> > all, they are rather bold.
>
> some details of what he wants his software to do, I'd be happy to
> provide a rough outline of a change-friendly solution, and give reasoned
> argument for all decisions;
If your claims are true, there must be many showcases availible on the
web, wouldn't it? Why don't you just post the pointers to some
resources showing that OO is good at managing changes, so we can share
them all together?
Fredrik Bertilsson
http://frebe.php0h.com
Daniel T.
nass...@gmail.com wrote:
Tell him he is right. OO is for managing complexity, if the complexity
isn't there, there is no need for OO:
Here's a paraphrase for you...
One of my friends has a program that he wrote using assembly language,
he's been asked by his boss to translate it into C, so I explained how
to write functions and how the operators work. He thought the best way
would be to simply write an asm{ } block in main and I was horrified and
told him he really shouldn't do it. Of course he asked, "why?" His
assembly code worked fine after all.
Ed Kirwan
Sure, but what do you mean by, "Showcases?" Do you mean
state-of-the-art theory or real-world source code?
I don't mean to be glib, but the best theory I've seen is the, "Design
patterns," book, which really defines how object-orientation's
flexibility is used to manage change, indeed that, "Flexibility
through variance encapsulation," is the prime concern of object
orientation.
And although that's not on the web, googling for, "Object-orientation
design pattern," will throw up loads of alternatives.
A second good source is a series of papers by Robert Martin outlining
what he considers to be core ideas in object-orientation; all of these
serve to enhance the flexibility of object-oriented solutions; summary
here:
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF
But you've been on this list for a while, so I presume you know all
about those; so I presume this is not the answer you were looking for.
So do you want me to point out source code (not snippets, but full
applications) and how it uses object-orientation to manage change? I
can't publish the code I work with professionally, but I'll gladly
publish an application I wrote and point out the salient parts, if you
like. Alternatively, I could go to sourceforge and look for some good
code.
Daniel T.
r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> "Daniel T." <dani...@earthlink.net> writes:
> >write an asm{ } block in main and I was horrified and told him
> >he really shouldn't do it. Of course he asked, "why?"
>
> »asm« is not a part of the language C (ISO/IEC 9899:1999 (E)).
The point still remains.
Davor
and OO...
http://api.drupal.org/api/HEAD/file/developer/topics/oop.html
Davor
H. S. Lahman
> So I explained the basics of OO to him, encapsulation, inheritance,
> that kind of basic concepts.... Then after a while he said that he has
> a nice structure in his old ASP code, so he thought the best way would
> be to just convert the old function libraries (files) to classes with
> static methods. Naturally I was horrified and told him he really
> shouldn't do it, but instead build an object model and redesign the
> solution. And then he asked me: WHY? It works great as it is, wouldn't
> a new design just make things worse? And I really had NO answer to that
> why...
Basically I agree with Kirwan and others. If it ain't broke, don't fix
it -- unless you have a reason to do so.
Ask him how often he had to do maintenance on it and, if so, how often
he sees that happening in the future. If maintenance is an issue, then
the rewrite is an ideal time to address that. If it isn't and the site
Just Works, then he can save himself a lot of design effort. (But he
should understand that trade-off.)
An interesting question: why is he using C#? One reason might simply be
that it is has easy access to .NET facilities that will save a lot of
grunt work. If the site is stable and that is the only reason he is
using C#, then he might as well be doing it in C anyway. IOW, he is not
using C# to solve a problem with OO; he is using it as a tool to get at
infrastructure.
OTOH, it might be a good opportunity to learn OO techniques. B-)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
Valmont
<nass...@gmail.com> schreef in bericht
news:1151999442.6...@75g2000cwc.googlegroups.com...
I came here two years ago asking for lessons on OOD because I noticed that there
was a pattern in my design problems. The reason I had design problems is because
I like to think in terms of (reusable) objects. So a "problempattern" was
acknowledged, and thus people here tought me the basics of design patterns. So
it was me who made the first step: I needed something, then I received a
solution which was inherent to my problem.
That's the way to go I think.
However, your friend didn't complain about design. He mentioned there was a lot
of re-coding to do. That's a different problem - not related to Object
Orientation. So why give him a solution related to design while he never
addressed design issues? Only because you love it? If you would like to be
helpfull to your friend you should realize that is not about you, but about
assisting your friend in his needs.
That's how I think. Absolutely not critisizing you: you only try to help, I
know.
~Val
Laurent Bossavit
> objects instead of plain functions?
Does the existing source have a lot of duplicated code, i.e. anything
that looks like the result of copy-paste programming ?
If yes, some understanding of OO principles can help with that, together
with an understanding of the specific facilities provided in C# for that
purpose.
Laurent
Robert Martin
> Hello all!
> [...snip...]
> So now I'm asking you people, what should I tell him? Why should he use
> objects instead of plain functions? Please give me some good arguments
> to use!!!
I presume, since it's just your friend writing it, that the site is
relatively small as sites go. Since he doesn't seem to be particularly
knowledgeable in the craft of software, and since he has a structure
that he already understands, I suggest that creating an object model is
not the right solution for him.
The motivation to use OO is to decrease coupling between modules, and
manage the interdependencies of the source code. This becomes more and
more important as the size of a project grows. You know you need OO
when a small change to the requirements causes you to change many
different modules, or when one small change in one part of the program
causes other unrelated parts to break. These are symptoms of unmanaged
dependencies.
Typically these symptoms (called rigidity and fragility) become
geometrically worse the larger the system becomes. Dependencies grow
with the square of the number of modules. So if your friend plans to
grow the system beyond it's current limits, then ask him to watch for
the symptoms described above. If the system starts to become rigid
(too many modules need changing for simple requirements changes), or
fragile (other unrelated modules break when any particular module is
changed), then he should consider a redesign using some OO techniques.
Take care not to foist the whole OO religion upon him. It's not likely
that he will need a whole object model, or dabatase insulation, or
tools like hibernate or EJB. As his system grows what he'll need are
the simple tools of OO. A little bit of polymorhism here and there can
keep the depencencies in check, and stave off the symptoms of rigidity
and fragility.
One other tool your friend will need is tests. Tests will allow him to
make changes to the system, and eventually to add OO structures to his
system, without breaking anything.
Advise your friend to read "Test Driven Development in C#" by Jim
Newkirk. Encourage him to use the technique as he rewrites his system
in C#. Advise him that as his system grows, those tests will enable
him to make changes with much less risk than he's previously
experienced.
And, just between you and me, writing tests is a very good way to force
someone to start using OO techniques. Since the tests need to access
independent modules, the use of interfaces and polymorphism to isolate
modules from each other becomes obviously necessary.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716 |
Robert Martin
> If your claims are true, there must be many showcases availible on the
> web, wouldn't it? Why don't you just post the pointers to some
> resources showing that OO is good at managing changes, so we can share
> them all together?
Take a look at FitNesse. www.fitnesse.org.
Robert Martin
Portability? His boss may be concerned that they will lose an
important asset if they change platforms.
Daniel T.
Robert Martin <uncl...@objectmentor.com> wrote:
> On 2006-07-04 12:24:40 -0500, "Daniel T." <dani...@earthlink.net> said:
>
> > In article <asm-20060...@ram.dialup.fu-berlin.de>,
> > r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> >
> >> "Daniel T." <dani...@earthlink.net> writes:
> >>> write an asm{ } block in main and I was horrified and told him
> >>> he really shouldn't do it. Of course he asked, "why?"
> >>
> >> »asm« is not a part of the language C (ISO/IEC 9899:1999 (E)).
> >
> > The point still remains.
>
> Portability? His boss may be concerned that they will lose an
> important asset if they change platforms.
No complexity. If I'm having no trouble understanding and maintaining a
program that was written using structural techniques, I don't need OO.
Like you, I don't think that OO is the right solution. His motivation
for using an OO language was not one of complexity management, but
rather he was forced to because of old product phase-out. That isn't a
reason to change paradigms.
Phlip
> Like you, I don't think that OO is the right solution. His motivation
> for using an OO language was not one of complexity management, but
> rather he was forced to because of old product phase-out. That isn't a
> reason to change paradigms.
If the conversion was from ASP Classic to C#, the OP's friend might be
_forced_ to use "objects".
Total agreement with Uncle Bob about making only one kind of conversion at a
time. If it's possible. And use Watir for the tests.
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Frans Bouma
> On 2006-07-04 12:24:40 -0500, "Daniel T." <dani...@earthlink.net>
> said:
>
> > In article <asm-20060...@ram.dialup.fu-berlin.de>,
> > r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> >
> >> "Daniel T." <dani...@earthlink.net> writes:
> >>> write an asm{ } block in main and I was horrified and told him
> >>> he really shouldn't do it. Of course he asked, "why?"
> >>
> >> »asm« is not a part of the language C (ISO/IEC 9899:1999 (E)).
> >
> > The point still remains.
>
> Portability? His boss may be concerned that they will lose an
> important asset if they change platforms.
that's a red herring. Porting C full of structs from big-endian to
little endian and from for example vc to gcc will give you a lot of
headaches. If you want portable C code, you've to write C that's
portable. It's not portable by definition.
Alvin Ryder
Hi,
My friend recently learn't ASP.NET v2, it was a 3 to 6 month learning
curve. Not so much about OOP or C# but the .NET framework itself, it is
not tiny.
Ok it happens to use OOP but I'd keep the OO side secondary, this will
spare the neurons for .net.
I agree OOP and C# need to be used properly but learning all that and
.net at the same time is just too much for one chunk, IMHO.
I've also encountered several people who already know OOP and C#, they
are merely migrating from .net version 1.1 to version 2.0 and they are
finding it no joy ride either.
HTH,
Cheers.
Nick Malik [Microsoft]
> One of my friends
> runs an Internet site with education-related information. The site is
> written in ASP (VBScript), but now he has to rewrite the code in C#
> because the web hosting company he uses are dropping ASP support....
No he doesn't. Just change web hosting companies. ASP support is still in
the Windows Server products. There is nothing wrong with ASP. If it works
for your friend, and he doesn't want to add a lot of features, he should
leave the code alone. It is far easier to move the domain name from one web
host to another than it is to rewrite his code.
> So I explained the basics of OO to him, encapsulation, inheritance,
> that kind of basic concepts.... Then after a while he said that he has
> a nice structure in his old ASP code, so he thought the best way would
> be to just convert the old function libraries (files) to classes with
> static methods. Naturally I was horrified and told him he really
> shouldn't do it, but instead build an object model and redesign the
> solution. And then he asked me: WHY? It works great as it is, wouldn't
> a new design just make things worse? And I really had NO answer to that
> why...
Sounds like your friend is not a professional programmer. We (as
programmers and architects) cope with change all the time. We have learned
to use tools to deal with that. Your friend does not cope with change all
the time, and only when it is of his own making. He may not need the same
tools.
> So now I'm asking you people, what should I tell him?
Tell him that you were wrong.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
topmind
fre...@gmail.com wrote:
> > OO is good at managing change: changing requirements, changing products,
> > changing frameworks, changing configurations, even changing code for
> > bug-fixes.
>
> I think his friend need some better motivations for these claims. After
> all, they are rather bold.
And UNproven. I've been asking for code samples to back such claims for
the biz domain for almost a decade now, and nobody can point to
something they are confident to show. The few times they have, their
assumptions about change patterns and frequencies seemed unrealistic to
me, as if they were accepting OO change doctrine right out of pro-OO
books uncritically.
If you want to motivate him/her to use OOP, then say that OOP is used
in practice and if you don't know it you won't be able to read other's
code. This is the "QWERTY" argument, named after the keyboard letters;
sometimes also known as the "when in Rome" argument.
The social or familiarity argument is far easier to back and justify
than claims of objective paradign greatness.
>
> Fredrik Bertilsson
> http://frebe.php0h.com
topmind
Object mentor tends to focus on systems software, which may not be
applicable to custom business software. For one, the interfaces seem to
change slower in systems software. The same applies for Design Patterns
for the most part. Many people looking for OO advice do not write word
processors or modem drivers for a living. OOP examples seem to have a
love affair with systems software, but good biz examples are sorely
lacking. Coincidence?
I have yet to encounter an OO author that seems to have a good feel for
the biz domain. Shapes, animals, and device drivers can only take you
so far.
>
> But you've been on this list for a while, so I presume you know all
> about those; so I presume this is not the answer you were looking for.
>
> So do you want me to point out source code (not snippets, but full
> applications) and how it uses object-orientation to manage change? I
> can't publish the code I work with professionally, but I'll gladly
> publish an application I wrote and point out the salient parts, if you
> like. Alternatively, I could go to sourceforge and look for some good
> code.
>
> --
> www.EdmundKirwan.com - Home of The Fractal Class Composition.
-T-
Robert Martin
> I've been asking for code samples to back such claims for
> the biz domain for almost a decade now, and nobody can point to
> something they are confident to show.
Take a look at FitNesse. www.fitnesse.org
--
Robert Martin
<perseus.usenet.NOSPAM.@xs4all.nl> said:
> that's a red herring. Porting C full of structs from big-endian to
> little endian and from for example vc to gcc will give you a lot of
> headaches. If you want portable C code, you've to write C that's
> portable. It's not portable by definition.
True enough. On the other hand it's not possible to write portable
assembly language (unless you simulate the machine).
topmind
> On 2006-07-05 11:00:02 -0500, "topmind" <top...@technologist.com> said:
>
> > I've been asking for code samples to back such claims for
> > the biz domain for almost a decade now, and nobody can point to
> > something they are confident to show.
>
> Take a look at FitNesse. www.fitnesse.org
A couple of issues with this:
1. It targets C and Java. I would like to see a version for a
dynamicly-typed language(s) also. Static languages don't get along with
databases very well IMO, and I almost always use a database.
2. This is generally "systems software", I've asked for a custom biz
example, please note.
3. I couldn't find any actual source code. (It may be there in the
haystack, but it is not labelled clearly.) Nobody disputes that OOP
runs. So does assembler, but I wouldn't want to program in it.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
> (...) is the heart of why ObjectOrientedProgramming is
> better.
>
> http://c2.com/cgi/wiki?ReplaceConditionalWithPolymorphism
>
> I assume your friend is using Microsoft® Windows, where files
> are represented by areas within the Microsoft® Windows
> Explorer. To print a PDF-File, he chooses the message »print«
> from the context menu of the file area. To print a bitmap-File,
> he chooses the message »print« from the context menu of the
> bitmap-file.
>
> He does not have to find out which program (method) is needed
> to print a PDF-file or a bitmap file, respectively. He just
> sends the same message »print« to any printable file object,
> regardless of its type. A conditional was replaced with
> polymorphism. I assume, he prefers it this way. Then, he knows
> why it is better.
Fine. Oop is great for device drivers (like print drivers above),
animals, and shapes. But can we pleaaaaaase get something that reflects
what real people see in the real workplace? The vast majority of
software I write does not fit a device driver pattern. For example,
some use "employee types" with polymorphic methods for each sub-type as
a polymorphic biz example. In reality, you cannot divide employees into
a *clean* hierarchical taxonomy. And even if you did, new legal changes
could render the hierarchy useless, splitting existing categories, etc.
Lawmakers do not respect tree-ness. They don't care if new legislation
busts your nice little tree.
Thus, I've found it best to use a database to describe employees using
various attributes and flags. The code then processes these attributes
and flags without worrying too much about which taxonomy they are
attached to. The code is NOT shaped like a noun taxonomy. This is key
to FLEXIBILITY.
This way if the classification system for employees changes, as long as
the flags or attribs are the same, the code still carries out the
instruction. If the "noun" that triggers a given condition moves, such
as being tied to the department that you work in instead of an
individual person, then you only have to change the IF statement
expression a bit. Polymorphism would require *moving* the code because
the "responsibility" changes. Moving is a bigger change than altering
in-place. (Sure, you could get a fancy dancy OOP code processor to do
it for you, but one could make a CASE/IF statement processor also. I
too can build crutches.)
And the granularity of poly is often not fine enough. How do you
override HALF of a method? (without duplicating some behavior). IF
statements are simply more bendable and flexible to handle real-world
changes. You can refine them without moving lots of code around.
Polymorphism artificially couples your code to specific nouns and
specific noun taxonomies. If one is going to hammer on "coupling", then
you cannot pick and choose which coupling you keap and which you reject
without justification. If *all* coupling is bad, then poly is coupling
to nouns and noun taxonomies and is therefore bad.
-T-
topmind
Procedural/relational is *just* as factorable with regard to
duplication as OOP. If you disagree, then produce code that proves it.
And please, not yet another case/switch statement battle. The topic is
beat to death here:
http://c2.com/cgi/wiki?SwitchStatementsSmell
-T-
Bruno Desthuilliers
(snip)
> Fine. Oop is great for device drivers (like print drivers above),
> animals, and shapes. But can we pleaaaaaase get something that reflects
> what real people see in the real workplace? The vast majority of
> software I write does not fit a device driver pattern. For example,
> some use "employee types" with polymorphic methods for each sub-type as
> a polymorphic biz example.
"some" also store serialized multivalued attributes in RDBMS fields,
have table schema with numbered repeated attributes (like 'value1',
'value2', 'value3'), or any other obvious ineptia. "some" also set
indices on lowly-discriminating attribs, hoping for performance boost. I
could write many pages on the stupidities I've seen in DB schemas. Does
it imply that RM doesn't work ? Of course not.
> In reality, you cannot divide employees into
> a *clean* hierarchical taxonomy.
And why should you ?
> And even if you did, new legal changes
> could render the hierarchy useless, splitting existing categories, etc.
Of course. That's why it would probably be a bad idea to model employees
as a type hierarchy.
> Lawmakers do not respect tree-ness. They don't care if new legislation
> busts your nice little tree.
*your* "nice little tree".
I don't have this kind of problems. But that's probably because I'm not
totally OOD-impaired. I avoid sub-typing as much as possible, and I
encapsulate what's the most subject to arbitrary changes.
> Thus, I've found it best to use a database to describe employees using
> various attributes and flags. The code then processes these attributes
> and flags without worrying too much about which taxonomy they are
> attached to. The code is NOT shaped like a noun taxonomy. This is key
> to FLEXIBILITY.
And I can do exactly the same thing with OO.
(snip)
> Polymorphism would require *moving* the code because
> the "responsibility" changes.
Pardon ?
>
> And the granularity of poly is often not fine enough. How do you
> override HALF of a method? (without duplicating some behavior).
Refactor into distinct methods and only override the one that needs to be.
> IF
> statements are simply more bendable and flexible to handle real-world
> changes.
Keep on believing it. That's your problem.
> You can refine them without moving lots of code around.
> Polymorphism artificially couples your code to specific nouns and
> specific noun taxonomies.
Please learn what polymorphism mean in CS. It's by no way OO specific,
and even in OO it doesn't have to be tied to class hierarchies.
> If one is going to hammer on "coupling", then
> you cannot pick and choose which coupling you keap and which you reject
> without justification. If *all* coupling is bad, then poly is coupling
> to nouns and noun taxonomies and is therefore bad.
Really ?
class Something:
def doThis(self):
print "in Something.doThis"
class Another:
def doThis(self):
print "in Another.doThis"
class Different:
def __init__(self, thing):
self.thing = thing
def __getattr__(self, name):
return getattr(self.thing, name)
def doThat(obj):
print "in doThat for %s" % obj.__class__.__name__
def doWhat(obj):
print "in doWhat for %s" % obj.__class__.__name__
class Nothing:
pass
def getNothing(doFhisFunc):
from types import MethodType
n = Nothing()
n.doThis = MethodType(doThisFunc, n, Nothing)
return n
things = [Something(),
Another(),
Different(Something),
getNothing(doThat),
getNothing(doWhat),
]
for t in things:
t.doThis()
No subclassing here, loose and even looser coupling, and yet
polymorphism at work.
OO is certainly not a silver bullet - nor are RDBMS. Both are useful
tools when you know how to use them. Both are useless when you don't
know how to use them. IOW, stop talking about what you just don't
understand.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'on...@xiludom.gro'.split('@')])"
Robert Martin
> Robert Martin wrote:
>> On 2006-07-05 11:00:02 -0500, "topmind" <top...@technologist.com> said:
>>
>>> I've been asking for code samples to back such claims for
>>> the biz domain for almost a decade now, and nobody can point to
>>> something they are confident to show.
>>
>> Take a look at FitNesse. www.fitnesse.org
>
> A couple of issues with this:
>
> 1. It targets C and Java. I would like to see a version for a
> dynamicly-typed language(s) also. Static languages don't get along with
> databases very well IMO, and I almost always use a database.
There are ports for ruby, and python.
However, your claim was not about how well OO plays with databases, it
was that OO does not manage change well. Fitnesse, as an OO system,
manages change quite nicely, including changes of database. There have
been a large number of changes that have been made to the requirements
of fitnesse. None of those changes has caused the structure of the
system to unravel. Indeed, one of our users removed the back end
persistence mechanism based on flat files, and inserted an RDB back
end. This took him a day, and we now offer it as a plug in (which
barely anyone uses).
> 2. This is generally "systems software", I've asked for a custom biz
> example, please note.
FitNesse is a wiki. A wiki is a management information system. It is
a collaboratively editable website.
FitNesse is also an acceptance testing tool build for the purpose of
helping business analysts and QA people test custom business software.
FitNesse was written for businesses.
Bryce, you keep widening the bucket of things for which OO works well
for. First it was drivers. Now it's system software. I think what
you really mean, Bryce, is that you don't care whether OO works so long
as you can continue to claim that it doesn't work for the stuff that
you do on a regular basis.
> 3. I couldn't find any actual source code. (It may be there in the
> haystack, but it is not labelled clearly.) Nobody disputes that OOP
> runs. So does assembler, but I wouldn't want to program in it.
Go to www.fitnesse.org, click on the 'download' link, click on the
fitnesse_src20050731.zip link.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Robert Martin
> Procedural/relational is *just* as factorable with regard to
> duplication as OOP. If you disagree, then produce code that proves it.
>
>
> And please, not yet another case/switch statement battle. The topic is
> beat to death here:
> http://c2.com/cgi/wiki?SwitchStatementsSmell
Translation:
OK all you know-it-all OO evangelists, just shown me one instance of
procedural code that OO is better at removing duplication from; but no
fair using code that OO is good at removing duplication from.
End translation.
Robert Martin
> But can we pleaaaaaase get something that reflects
> what real people see in the real workplace?
Take a look at www.fitnesse.org. It is a java program. Written using
OO principles. It is a web delivered system using a back-end database
and is used by businesses to help them create knowledge-bases, and to
capture requirements and tests for custom business applications.
topmind
> On 2006-07-05 22:21:13 -0500, "topmind" <top...@technologist.com> said:
>
> > Robert Martin wrote:
> >> On 2006-07-05 11:00:02 -0500, "topmind" <top...@technologist.com> said:
> >>
> >>> I've been asking for code samples to back such claims for
> >>> the biz domain for almost a decade now, and nobody can point to
> >>> something they are confident to show.
> >>
> >> Take a look at FitNesse. www.fitnesse.org
> >
> > A couple of issues with this:
> >
> > 1. It targets C and Java. I would like to see a version for a
> > dynamicly-typed language(s) also. Static languages don't get along with
> > databases very well IMO, and I almost always use a database.
>
> There are ports for ruby, and python.
>
> However, your claim was not about how well OO plays with databases, it
> was that OO does not manage change well. Fitnesse, as an OO system,
> manages change quite nicely, including changes of database. There have
> been a large number of changes that have been made to the requirements
> of fitnesse. None of those changes has caused the structure of the
> system to unravel. Indeed, one of our users removed the back end
> persistence mechanism based on flat files, and inserted an RDB back
> end. This took him a day, and we now offer it as a plug in (which
> barely anyone uses).
I think we've debated swapping wiki "storage mechanisms" before. I'm
tired of hearing about swapping implementation. It is not something
that happens often in *custom* biz software because bosses are cheap
and don't want to pay somebody to write the same process twice.
Plus, one can do it with functions also. I actually wrote a wiki in PHP
once, and thought about making the "storage mechanism" swappble, but
realized that flat files are so crappy at joins and concurrency
management that a generic interface that handled joins and concurrency
would just add too much bloat. I would rather have to modify a few
simple case statements than an ocean full of classes. OOP is a
bureaucrats dream. It is a firewall between you and productivity.
I will tentatively agree that *if* I was paid to build a "generic" wiki
engine that could use tables or flat files or FTP, etc., that OOP may
indeed help there. Okay?
However, mass swappability is *not* the goal of a custom software
builders. Only once out of 100+ times in custom software have I ever
had to yank out the DB and replace it with flat files. The wrappers are
a 30% up-front code tax. Unless there is about a 30% chance of
switching to flat files, it is not economically logical.
You not only spend code on the wrappers, but have to stick with a
lowest-common-denominator, sacrificing the power of some relational
tools. It is a lot easier to go from flat files to DB's than the other
way around because DB's generally are a super-set of flat files.
Your writing is obsessed with this swapping stuff. You need to get more
tricks for your ponies.
> FitNesse is also an acceptance testing tool build for the purpose of
> helping business analysts and QA people test custom business software.
> FitNesse was written for businesses.
So were spreadsheets, but most don't write them from scratch.
>
> you keep widening the bucket of things for which OO works well
> for. First it was drivers. Now it's system software.
No, I have been complaining about systems software-centric examples for
years. Thus, your assertion that I am moving the goalposts is not true
because they have been there for years. (Device drivers essentially are
systems software.)
Thus, your allegations that I am trying to manipulate the scene are not
true.
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
Stefan Ram wrote:
> "topmind" <top...@technologist.com> writes:
> >Thus, I've found it best to use a database to describe employees using
>
> polymorphism: The same operation »SELECT« is supported by an
> object, independent of whether it is a base table or a
> »virtual« table (a »view«), independent of whether this is a
> result of a join operation or of a union operation, while the
> /implementation/ of »SELECT« might differ for base tables and
> different types of views.
> ...Different SQL database programs also are an example for
> useful polymorphism: They all understand the same language,
> but might have different implementations internally.
> Their client does not have to be aware of the implementation
> details.
You are using a rather wide definition of "polymorphism" that seems to
encompass all indirection. Anyhow, without getting bogged down in a
definition battle, maybe OOP is good for *making* RDBMS (systems
software). I won't challenge that. I am just saying that OOP has been
oversold for *my* niche, custom business software, and it is a big
niche.
Systems software is about making generic low-level or support tools.
Doing such may indeed require mass swapping of implementation behind
interfaces. However, that huge need does not necessarily extrapolate to
other domains. OO demonstrations often lean toward systems-software or
systems-software-like examples. I don't think that is a coincidence.
> These are /your/ trees. (However, the use of these personal
> pronouns and attributions distracts from the topic.)
>
> Polymorphism does not necessarily have to appear in a
> hierarchy, it does not have to appear together with
> inheritance. Just look at COM objects: They might
> - polymorphically - implement all kinds of interfaces, but are
> not (necessarily) part of a hierarchy.
They are *indirectly* a hierachy: a bunch of subtypes off of a master
"template" interface, which is the "parent".
This kind of thinking leads OO authors to create examples such as
"employee types", where employees can be nicely classified into
mutually-exclusive groups (sub-types) where each independent group
implements its own "payMe", "taxMe", "fireMe", etc. method.
In reality, set-based classification techniques are superior these, and
relational better fits that design. Sets allow better management of
overlapping attributes. Sets are a better HAS-A tool for a HAS-A world.
OO is good for IS-A, but the world I see is not an IS-A world. Yes, OOP
can *do* HAS-A, but is crappy at it, creating a navigational pointer
mess, similar to the kind that Dr. Codd set out to remedy 40 years ago.
-T-
Davor
> software). I won't challenge that. I am just saying that OOP has been
> oversold for *my* niche, custom business software, and it is a big
> niche.
What is "custom business software"?
In fact, what is "business software"?
And, is "custom business software" a subclass of "business software"?
Davor
topmind
Well, I couldn't give an exact boundary anymore than one can give an
exact boundary for "country music". However, it tends to do with
billing, inventory, reports (formal and ad-hoc), tracking, commisions,
marketing, etc.
A student and grade tracking system would make a reasonable (but not
perfect) coded example because it needs typical CRUD (edit screens &
reports) of biz apps, and everybody who has gone to college is familiar
with the concepts. Thus, there is little need to explain the domain.
http://c2.com/cgi/wiki?CampusExample
-T-
Davor
> Davor wrote:
> > topmind wrote:
> > > software). I won't challenge that. I am just saying that OOP has been
> > > oversold for *my* niche, custom business software, and it is a big
> > > niche.
> >
> > What is "custom business software"?
> >
> > In fact, what is "business software"?
> >
> > And, is "custom business software" a subclass of "business software"?
> >
> > Davor
>
>
> Well, I couldn't give an exact boundary anymore than one can give an
> exact boundary for "country music". However, it tends to do with
> billing, inventory, reports (formal and ad-hoc), tracking, commisions,
> marketing, etc.
OK, so what they typically call business/enterprise software... Good.
> perfect) coded example because it needs typical CRUD (edit screens &
> reports) of biz apps, and everybody who has gone to college is familiar
> with the concepts. Thus, there is little need to explain the domain.
OK, but this is not really "business software"... This is a general
description of a system consisting of
UI
data storage
operations to create, read, update, and destroy data
Even my basic text editor is such a system, but is not considered
"business software". Or, maybe my basic text editor is indeed a
"business software". Text editors are used in many businesses. A lot of
secretaries, developers, managers, CEOs, plumbers, etc. are using text
editors...
So, are you saying that OOP is not good for building basic text
editors, or for example, for building
world-wide-enterprise-housewife-business-intelligence-integration, that
fits better in what you described above as typical "business software",
(and this is real software that we were all financing in last several
years for FBI - http://www.spectrum.ieee.org/print/1455)??
My impression is that your claim that OOP is not good for "business
software" is as strong as typical OOP zealot's claim that OOP is good
for "business software".
Davor
topmind
This is why I use the term "custom business software". They don't come
in a box.
Spreadsheets and word processors are not really *just* for business
anyhow. Scientists can use them also. They are general work tools,
*not* specific to inventory tracking, sales reports, billing, etc. SAP,
for example, is "business software", but not "custom business
software".
> Or, maybe my basic text editor is indeed a
> "business software". Text editors are used in many businesses. A lot of
> secretaries, developers, managers, CEOs, plumbers, etc. are using text
> editors...
Exactly.
>
> So, are you saying that OOP is not good for building basic text
> editors, or for example, for building
> world-wide-enterprise-housewife-business-intelligence-integration, that
> fits better in what you described above as typical "business software",
> (and this is real software that we were all financing in last several
> years for FBI - http://www.spectrum.ieee.org/print/1455)??
>
> My impression is that your claim that OOP is not good for "business
> software" is as strong as typical OOP zealot's claim that OOP is good
> for "business software".
I am just saying that there is a void of OO examples for custom
business software. The examples one finds in the OO training material
do not reflect the custom biz apps that I deal with. They are obsessed
with device-drivers and swappability, something I don't see a big need
for.
For example, OO'ers keep harping on, "what if you want to replace your
database with flat files or a different RDBMS vendor?" That is not a
common need. I am not going to waste code on trying to make generic
wrappers (if even possible) unless there is an up-front known need for
such. Future discounting (similar to ROI curves) finance concepts are
also against it.
>
> Davor
-T-
topmind
> On 2006-07-05 23:02:34 -0500, "topmind" <top...@technologist.com> said:
>
> > Procedural/relational is *just* as factorable with regard to
> > duplication as OOP. If you disagree, then produce code that proves it.
> >
> >
> > And please, not yet another case/switch statement battle. The topic is
> > beat to death here:
> > http://c2.com/cgi/wiki?SwitchStatementsSmell
>
> Translation:
>
> OK all you know-it-all OO evangelists, just shown me one instance of
> procedural code that OO is better at removing duplication from; but no
> fair using code that OO is good at removing duplication from.
>
> End translation.
I am not sure what you are refering to. Lack of custom business
examples? Why does that make me bad?
Polymorphism being good in domain X does not automatically mean it is
good in domain Y.
Do you agree with that or not?
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
> topmind wrote:
> (snip)
> > Fine. Oop is great for device drivers (like print drivers above),
> > animals, and shapes. But can we pleaaaaaase get something that reflects
> > what real people see in the real workplace? The vast majority of
> > software I write does not fit a device driver pattern. For example,
> > some use "employee types" with polymorphic methods for each sub-type as
> > a polymorphic biz example.
>
> "some" also store serialized multivalued attributes in RDBMS fields,
> have table schema with numbered repeated attributes (like 'value1',
> 'value2', 'value3'), or any other obvious ineptia. "some" also set
> indices on lowly-discriminating attribs, hoping for performance boost. I
> could write many pages on the stupidities I've seen in DB schemas. Does
> it imply that RM doesn't work ? Of course not.
That is why I want to see an example of allegedly "good" OOP kicking
other paradigm's butt in my domain.
>
> > In reality, you cannot divide employees into
> > a *clean* hierarchical taxonomy.
>
> And why should you ?
It is a fairly common OOP training example.
>
> > And even if you did, new legal changes
> > could render the hierarchy useless, splitting existing categories, etc.
>
> Of course. That's why it would probably be a bad idea to model employees
> as a type hierarchy.
>
> > Lawmakers do not respect tree-ness. They don't care if new legislation
> > busts your nice little tree.
>
> *your* "nice little tree".
>
> I don't have this kind of problems. But that's probably because I'm not
> totally OOD-impaired. I avoid sub-typing as much as possible, and I
> encapsulate what's the most subject to arbitrary changes.
>
> > Thus, I've found it best to use a database to describe employees using
> > various attributes and flags. The code then processes these attributes
> > and flags without worrying too much about which taxonomy they are
> > attached to. The code is NOT shaped like a noun taxonomy. This is key
> > to FLEXIBILITY.
>
> And I can do exactly the same thing with OO.
It would probably tend to not be OO then. It might be functions in OO
clothing.
>
> (snip)
>
> > Polymorphism would require *moving* the code because
> > the "responsibility" changes.
>
> Pardon ?
This is related to "responsibility-driven design". Perhaps you don't
use that OO technique.
>
> >
> > And the granularity of poly is often not fine enough. How do you
> > override HALF of a method? (without duplicating some behavior).
>
> Refactor into distinct methods and only override the one that needs to be.
That is not making code change-friendly, that is giving in to the
Change Gods. Such refactoring will involve a fair amount of code
moving.
>
> > IF
> > statements are simply more bendable and flexible to handle real-world
> > changes.
>
> Keep on believing it. That's your problem.
Show me otherwise. If there is regularity, factor it to the database,
and use IF statements to deal with the nitty gritty exceptions.
>
> > You can refine them without moving lots of code around.
> > Polymorphism artificially couples your code to specific nouns and
> > specific noun taxonomies.
>
> Please learn what polymorphism mean in CS.
Nobody really agrees, I have found out.
> It's by no way OO specific,
> and even in OO it doesn't have to be tied to class hierarchies.
The topic is about polymorphism.
IN PRACTICE, most polymorphism involve an explicit or implicit
hierarchy or "list" of mutually-exclusive "kinds" of things. About 90%
of all the poly I see does. This is probably why you had to use a
foobar example instead of something like employees or bonds, etc.
>
> OO is certainly not a silver bullet - nor are RDBMS. Both are useful
> tools when you know how to use them. Both are useless when you don't
> know how to use them. IOW, stop talking about what you just don't
> understand.
Paternalistic insults? I understand it perfectly fine. I just have not
seen EVIDENCE of it being better. I have not even seen a custom biz
examples that fellow OOP fans agree is a good example. You haven't even
pleased your own kind, so stop trying to dump the biz gap in MY lap.
Not having found something that passes even your peers and me being
allegedly dumb are not related. Bad debaters often call the other
person dumb when cornered. Smart debaters don't have to because they
can SHOW. Good debaters kill with examples and code and scenarios, not
with names. Names are for amatures.
>
> --
> bruno desthuilliers
-T-
Frans Bouma
> Robert Martin wrote:
> > On 2006-07-05 23:02:34 -0500, "topmind" <top...@technologist.com>
> > said:
> >
> > > Procedural/relational is just as factorable with regard to
> > > duplication as OOP. If you disagree, then produce code that
> > > proves it.
> > >
> > >
> > > And please, not yet another case/switch statement battle. The
> > > topic is beat to death here:
> > > http://c2.com/cgi/wiki?SwitchStatementsSmell
> >
> > Translation:
> >
> > OK all you know-it-all OO evangelists, just shown me one instance of
> > procedural code that OO is better at removing duplication from; but
> > no fair using code that OO is good at removing duplication from.
> >
> > End translation.
>
> I am not sure what you are refering to. Lack of custom business
> examples? Why does that make me bad?
>
> Polymorphism being good in domain X does not automatically mean it is
> good in domain Y.
>
> Do you agree with that or not?
that's the same as:
$TECHNIQUE being good in domain $DOMAIN_X doesn't automatically mean
it's good in $DOMAIN_Y
Alvin Ryder
> Stefan Ram wrote:
> > nass...@gmail.com writes:
> > >So now I'm asking you people, what should I tell him?
> >
> > the Refactor "Replace Conditional with Polymorphism".
> > (...) is the heart of why ObjectOrientedProgramming is
> > better.
> >
> > http://c2.com/cgi/wiki?ReplaceConditionalWithPolymorphism
> >
> > I assume your friend is using Microsoft® Windows, where files
> > are represented by areas within the Microsoft® Windows
> > Explorer. To print a PDF-File, he chooses the message »print«
> > from the context menu of the file area. To print a bitmap-File,
> > he chooses the message »print« from the context menu of the
> > bitmap-file.
> >
> > He does not have to find out which program (method) is needed
> > to print a PDF-file or a bitmap file, respectively. He just
> > sends the same message »print« to any printable file object,
> > regardless of its type. A conditional was replaced with
> > polymorphism. I assume, he prefers it this way. Then, he knows
> > why it is better.
>
> Fine. Oop is great for device drivers (like print drivers above),
> animals, and shapes. But can we pleaaaaaase get something that reflects
> what real people see in the real workplace?
I don't think OOP is good for every type of application, in particular
Web and CRUD heavy business apps aren't the best showcase for it but
rich GUI apps are.
And curiously "shapes" represent far more applications than people
realise. Think of all those editors like "Paint", PaintShop, Visio, 3D
Studio Max, MAYA ... Ok you may not have written any of these but
millions of people use them daily and there are thousands of programs
in this "shapes" or graphical editor category.
Then there's the usual GUI apps like the "office" products, browsers,
and all those IDE's like Visual Studio, Eclipse, Netbeans, ... Then
there's games, game engines, simulations, scientific modelling ... all
these can benefit from OOP.
I'm not saying OOP cures cancer but it does provide a couple of extra
options, as do templates. In the right hands these extra options can be
put to good use but in the wrong hands they just provide more rope to
be hung with.
I work with games and game engines (and still some java/j2ee stuff),
some engines are written in C, like QUAKE3 and others in C++ with OOP
like DOOM3 and HALF-LIFE. Frankly I really like the C Quake stuff, it
has a certain mojo and speedy attitude that I love. But the C++ engines
are also excellent and they make very good use of OOP.
My conclusion is a good programmer will do a good job even if all they
have is assembler but with the extra options OO provides they can do
even better. OTOH bad programmers will not become a good programmers
just because they dabble in OOP and learn some buzz. So is OOP
worthless, not at all, it depends on how it's used, who uses it and
what type of application it's being used for.
Some people do better with languages like SQL, VB, HTML and even Perl,
there is less to think about, less to go wrong and less free rope but
none of this nullifies OOP's worth.
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>
>>topmind wrote:
>>(snip)
>>
>>>Fine. Oop is great for device drivers (like print drivers above),
>>>animals, and shapes. But can we pleaaaaaase get something that reflects
>>>what real people see in the real workplace? The vast majority of
>>>software I write does not fit a device driver pattern. For example,
>>>some use "employee types" with polymorphic methods for each sub-type as
>>>a polymorphic biz example.
>>
>>"some" also store serialized multivalued attributes in RDBMS fields,
>>have table schema with numbered repeated attributes (like 'value1',
>>'value2', 'value3'), or any other obvious ineptia. "some" also set
>>indices on lowly-discriminating attribs, hoping for performance boost. I
>>could write many pages on the stupidities I've seen in DB schemas. Does
>>it imply that RM doesn't work ? Of course not.
>
>
> That is why I want to see an example of allegedly "good" OOP kicking
> other paradigm's butt in my domain.
>
>
>>>In reality, you cannot divide employees into
>>>a *clean* hierarchical taxonomy.
>>
>>And why should you ?
>
>
> It is a fairly common OOP training example.
And a fairly bad one in this case. Hierarchical taxonomies may be good
for invariant parts that also happens to be hierarchical. Using them for
highly variant, non hierarchical parts is just plain and obvious
stupidity. This doesn't say much on OO - mostly on the average level of
people trying to teach OO when they're not even able to use their brain.
>
>>>And even if you did, new legal changes
>>>could render the hierarchy useless, splitting existing categories, etc.
>>
>>Of course. That's why it would probably be a bad idea to model employees
>>as a type hierarchy.
>>
>>
>>>Lawmakers do not respect tree-ness. They don't care if new legislation
>>>busts your nice little tree.
>>
>>*your* "nice little tree".
>>
>>I don't have this kind of problems. But that's probably because I'm not
>>totally OOD-impaired. I avoid sub-typing as much as possible, and I
>>encapsulate what's the most subject to arbitrary changes.
>>
>>
>>>Thus, I've found it best to use a database to describe employees using
>>>various attributes and flags. The code then processes these attributes
>>>and flags without worrying too much about which taxonomy they are
>>>attached to. The code is NOT shaped like a noun taxonomy. This is key
>>>to FLEXIBILITY.
>>
>>And I can do exactly the same thing with OO.
>
> It would probably tend to not be OO then.
OO is about organizing a program in terms of objects communicating by
messages, 'object' being defined as 'id + state + behaviour +
interface'. Nothing in this definition imply rigid hierarchical taxonomy
AFAICT.
> It might be functions in OO
> clothing.
Think of functions as objects.
>>(snip)
>>
>>
>>>Polymorphism would require *moving* the code because
>>>the "responsibility" changes.
>>
>>Pardon ?
>
> This is related to "responsibility-driven design". Perhaps you don't
> use that OO technique.
>
That's not the point. I'd like you to give further explanations on your
previous statement.
>>>And the granularity of poly is often not fine enough. How do you
>>>override HALF of a method? (without duplicating some behavior).
>>
>>Refactor into distinct methods and only override the one that needs to be.
>
>
> That is not making code change-friendly,
Yes it is. OO design (and FWIW, it's not restricted to OO, you'll find
the same thing in FP and even in plain procedural) is about decoupling
variance from invariant. The standard C sort() function does this. It
decouple the invariant part (the sort algorithm) from the variant part
(the actual type of objects being sorted and the comparison function
that defines sort order). It's CS 101.
> that is giving in to the
> Change Gods. Such refactoring will involve a fair amount of code
> moving.
blah blah.
>
>>>You can refine them without moving lots of code around.
>>>Polymorphism artificially couples your code to specific nouns and
>>>specific noun taxonomies.
>>
>>Please learn what polymorphism mean in CS.
>
>
> Nobody really agrees, I have found out.
http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
>
>>It's by no way OO specific,
>>and even in OO it doesn't have to be tied to class hierarchies.
>
> The topic is about polymorphism.
>
The topic is about your lack of understanding of what polymorphism is.
You can copy/paste the above snippet and try it in a Python interpreter.
I think this is enough to qualify as "practice".
> most polymorphism involve an explicit or implicit
> hierarchy or "list" of mutually-exclusive "kinds" of things.
polymorphism *by definition* (look for an etymology of the word) involve
many (implied 'different') "kinds" of "things". It's even the whole
point of polymorphism in CS : uniform handling of heterogenous types.
> About 90%
> of all the poly I see does. This is probably why you had to use a
> foobar example instead of something like employees or bonds, etc.
Please demonstrate why the above could not be applied to any domain.
>
>>OO is certainly not a silver bullet - nor are RDBMS. Both are useful
>>tools when you know how to use them. Both are useless when you don't
>>know how to use them. IOW, stop talking about what you just don't
>>understand.
>
>
> Paternalistic insults?
Nope, simple constatation and friendly advice. Your arguments fail to
demonstrate that OO is not suited for business app (which doesn't imply
it is), but clearly demonstrate your lack of understanding of OO (which
doesn't imply that most people writing 'OOP training example' have a
better understanding).
> I understand it perfectly fine. I just have not
> seen EVIDENCE of it being better.
"better" than what, and according to which metric ?
OO can help managing some kind of complexity, and can add some other
kind of complexity too. No sliver bullet as usual.
My point is definitively not to demonstrate that 'OO is better', just to
make clear that your arguments againts OO only demonstrate your lack of
understanding of OO. If you intend to demonstrate the superiority of
approach A over approach B for domain C, you need to master approach A,
approach B and domain C. This is not the case. Period.
> I have not even seen a custom biz
> examples that fellow OOP fans agree is a good example.
Not being a 'fan' of anything, I'm not concerned with this.
> You haven't even
> pleased your own kind,
Care to explain what you mean here ?
> so stop trying to dump the biz gap in MY lap.
> Not having found something that passes even your peers and me being
> allegedly dumb are not related.
Effectively. FWIW, the "decoupling variance from invariant" part is
certainly something anyone here would agree upon, but here I'm only
concerned with your assertions about OO. Also please note that I never
stated that *you* were dumb. Just that your arguments against OO are
wrong. If you choose to identify yourself to your anti-OO crusade, then
it's none of my responsability.
> Bad debaters often call the other
> person dumb when cornered. Smart debaters don't have to because they
> can SHOW. Good debaters kill with examples and code and scenarios, not
> with names. Names are for amatures.
What's funny with this is that :
1/ I didn't called you names
2/ I gave a working example that counters your arguments
3/ As a result, *you* make it a personal affair.
Please take your own medicine.
topmind
Some people feel that the world changes in a hierarchical way. I've
encountered some. Without showing them actual film of changes over
decades, there is probably no way to convince them. If they see
tree-oriented changes, they see tree-oriented changes.
> >>>Thus, I've found it best to use a database to describe employees using
> >>>various attributes and flags. The code then processes these attributes
> >>>and flags without worrying too much about which taxonomy they are
> >>>attached to. The code is NOT shaped like a noun taxonomy. This is key
> >>>to FLEXIBILITY.
> >>
> >>And I can do exactly the same thing with OO.
> >
> > It would probably tend to not be OO then.
>
> OO is about organizing a program in terms of objects communicating by
> messages, 'object' being defined as 'id + state + behaviour +
> interface'. Nothing in this definition imply rigid hierarchical taxonomy
> AFAICT.
I've seen about 7 or so primary definitions of OOP. I've chucked them
all and now use my own working definition instead (which does not
differ much from Robert Martin's, actually). There is no consistent
consensus definition of OOP out there. It makes it hard to pin down
what is OO and what isn't.
By the way, you used "object" to define "object", more or less. Thus,
you have a recursive definition.
>
> > It might be functions in OO
> > clothing.
>
> Think of functions as objects.
I suppose one could. But that does not necessarily mean that one
should. C2.com lists about 20 "everything is an X" mental models that
one could take. Lisp fans see everything as a regular expression, for
example. Indeed everything could be modelled that way. Whether it
*should* is another story.
> >>>And the granularity of poly is often not fine enough. How do you
> >>>override HALF of a method? (without duplicating some behavior).
> >>
> >>Refactor into distinct methods and only override the one that needs to be.
> >
> >
> > That is not making code change-friendly,
>
> Yes it is. OO design (and FWIW, it's not restricted to OO, you'll find
> the same thing in FP and even in plain procedural) is about decoupling
> variance from invariant. The standard C sort() function does this. It
> decouple the invariant part (the sort algorithm) from the variant part
> (the actual type of objects being sorted and the comparison function
> that defines sort order). It's CS 101.
I am judging the total change effort and not giving much of a
"discount" just because it may be the implementation that has to be
changed instead of the interface. Change work is change work. A bad
implementation change will bust the system as much as a bad interface
change.
>
> > that is giving in to the
> > Change Gods. Such refactoring will involve a fair amount of code
> > moving.
>
> blah blah.
Hand-wave if you want. Change work is change work.
>
>
> >
> >>>You can refine them without moving lots of code around.
> >>>Polymorphism artificially couples your code to specific nouns and
> >>>specific noun taxonomies.
> >>
> >>Please learn what polymorphism mean in CS.
> >
> >
> > Nobody really agrees, I have found out.
>
> http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
That redirects me to "type polymorphism". Type polymorphism is just one
kind of polymorphism.
>
> >
> >>It's by no way OO specific,
> >>and even in OO it doesn't have to be tied to class hierarchies.
> >
> > The topic is about polymorphism.
> >
>
> The topic is about your lack of understanding of what polymorphism is.
You appear to be the one ignorant of all the potential definitions and
viewpoints of poly are. There is no consensus definition. An informed
person who has been around the block knows this.
I mean a real case of polymorphism that one encounters in the *field*.
Of course a "lab example" can be made non-hierarchical. I don't dispute
that.
>
> > most polymorphism involve an explicit or implicit
> > hierarchy or "list" of mutually-exclusive "kinds" of things.
>
> polymorphism *by definition* (look for an etymology of the word) involve
> many (implied 'different') "kinds" of "things". It's even the whole
> point of polymorphism in CS : uniform handling of heterogenous types.
Not every OO proponent agrees that poly is about "types". This also
gets into the messy issue of what a "type" is.
>
> > About 90%
> > of all the poly I see does. This is probably why you had to use a
> > foobar example instead of something like employees or bonds, etc.
>
> Please demonstrate why the above could not be applied to any domain.
First of, "can" and "should" are two different things. If I see a fair
amount of decent examples for my domain, I may change my stance. Until
them, I am skeptical of OOP working for my domain. If you write device
drivers and word processors for a living, poly may be great there. I
won't challenge that domain.
>
> >
> >>OO is certainly not a silver bullet - nor are RDBMS. Both are useful
> >>tools when you know how to use them. Both are useless when you don't
> >>know how to use them. IOW, stop talking about what you just don't
> >>understand.
> >
> >
> > Paternalistic insults?
>
> Nope, simple constatation and friendly advice. Your arguments fail to
> demonstrate that OO is not suited for business app (which doesn't imply
> it is),
I didn't take it as friendly. If you want to "educate" an allegedly
ignorant person such as me, then show me examples from my domain of
poly objectively improving code. I am not taking your word for it
because everybody on the web thinks they are smarter than everybody
else. I cannot distinquish you from all the pretenders.
> but clearly demonstrate your lack of understanding of OO (which
> doesn't imply that most people writing 'OOP training example' have a
> better understanding).
I understand the mechanics and written philosophy of OO. What I don't
understand is why it is allegedly better for building custom biz apps.
I want to see concrete examples. I am tired of brochure-talk and shape,
animal, and device-driver examples.
>
> > I understand it perfectly fine. I just have not
> > seen EVIDENCE of it being better.
>
> "better" than what, and according to which metric ?
I don't know. I didn't claim it better so I don't know how to show it
better. I can't get specifics. If nobody can articulate exactly why it
is better with change scenarios etc, then perhaps it is indeed all
subjective. My stance is that paradigms are a probably subjective
preference and that there is no demonstrable-objective silver bullet,
or even a brass bullet.
Here are some suggested metrics for code change volume:
http://www.geocities.com/tablizer/goals.htm#base
>
> OO can help managing some kind of complexity, and can add some other
> kind of complexity too. No sliver bullet as usual.
Yes, but can you show it being at least a brass bullet?
>
> My point is definitively not to demonstrate that 'OO is better', just to
> make clear that your arguments againts OO only demonstrate your lack of
> understanding of OO. If you intend to demonstrate the superiority of
> approach A over approach B for domain C, you need to master approach A,
> approach B and domain C. This is not the case. Period.
"Master" tends to mean "do and think my way" in web discussions. That
is not dissectable and analyzable, at least not in the western
reductionalist stanpoint.
>
>
> > I have not even seen a custom biz
> > examples that fellow OOP fans agree is a good example.
>
> Not being a 'fan' of anything, I'm not concerned with this.
>
> > You haven't even
> > pleased your own kind,
>
> Care to explain what you mean here ?
Nobody has presented an example code of a custom biz app that even OOP
proponents agree is an example of good OOP code. Somebody once proposed
the Java "pet store" example, but many OO proponents have dissagreed.
There is nothing to compare and analyze and scrutinize. It is all
anecdotal evidence. Should I accept anecdotal evidence?
>
> > so stop trying to dump the biz gap in MY lap.
> > Not having found something that passes even your peers and me being
> > allegedly dumb are not related.
>
> Effectively. FWIW, the "decoupling variance from invariant" part is
> certainly something anyone here would agree upon,
I've found that not everybody even agrees on what is invariant. As
mentioned above, people perceive change differently such that they code
for different change probability profiles.
> > Bad debaters often call the other
> > person dumb when cornered. Smart debaters don't have to because they
> > can SHOW. Good debaters kill with examples and code and scenarios, not
> > with names. Names are for amatures.
>
> What's funny with this is that :
> 1/ I didn't called you names
You accused me of being ignorant about OO.
> 2/ I gave a working example that counters your arguments
Being right in theory is not the same as being right in practice. If
99% of actual production code makes subtypes in order to use poly, then
the fact that poly does not technically need subtypes may not mean much
as far as utility.
> 3/ As a result, *you* make it a personal affair.
>
> Please take your own medicine.
I'll spank myself on the weekend.
>
> --
> bruno desthuilliers
-T-
nass...@gmail.com
> You may not like my reply very much...
>
> > One of my friends
> > runs an Internet site with education-related information. The site is
> > written in ASP (VBScript), but now he has to rewrite the code in C#
> > because the web hosting company he uses are dropping ASP support....
>
> No he doesn't. Just change web hosting companies. ASP support is still in
> the Windows Server products. There is nothing wrong with ASP. If it works
> for your friend, and he doesn't want to add a lot of features, he should
> leave the code alone. It is far easier to move the domain name from one web
> host to another than it is to rewrite his code.
> programmers and architects) cope with change all the time. We have learned
> to use tools to deal with that. Your friend does not cope with change all
> the time, and only when it is of his own making. He may not need the same
> tools.
>
>
company and HAS to port his old ASP VBScript code to C#. So instead of
just rewriting it in another language I suggested using OOP. The reason
is that the site is quite large, well-used and new functionality is
added regularily... But of course I shouldn't push OO as a religion....
Patrick May
> Lisp fans see everything as a regular expression, for example.
Is this a typo? Common Lisp doesn't even include a regular
expression package in the standard. (I use CL-PPCRE, but there are
other options available.)
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>
>>topmind wrote:
>>
>>>Bruno Desthuilliers wrote:
>>>
>>>
>>>>topmind wrote:
>>>>(snip)
>>>>
>>>>
>>>>>Thus, I've found it best to use a database to describe employees using
>>>>>various attributes and flags. The code then processes these attributes
>>>>>and flags without worrying too much about which taxonomy they are
>>>>>attached to. The code is NOT shaped like a noun taxonomy. This is key
>>>>>to FLEXIBILITY.
>>>>
>>>>And I can do exactly the same thing with OO.
>>>
>>>It would probably tend to not be OO then.
>>
>>OO is about organizing a program in terms of objects communicating by
>>messages, 'object' being defined as 'id + state + behaviour +
>>interface'. Nothing in this definition imply rigid hierarchical taxonomy
>>AFAICT.
>
>
> I've seen about 7 or so primary definitions of OOP. I've chucked them
> all and now use my own working definition instead (which does not
> differ much from Robert Martin's, actually). There is no consistent
> consensus definition of OOP out there. It makes it hard to pin down
> what is OO and what isn't.
Indeed. But AFAICT, the definition I used should be agreed upon by
almost anyone here, should not contradict most usual definitions, and
should be appliable to most OOPLs and/or systems claiming to be OO. If
you can prove me wrong, please do.
> By the way, you used "object" to define "object", more or less.
> Thus,
> you have a recursive definition.
>
Let's check:
- definition of "object oriented":
"""
OO is about organizing a program in terms of objects communicating by
messages
"""
No recursive definition here.
- definition of "object":
"""
'object' being defined as 'id + state + behaviour +
interface'
"""
Still no recursion here.
I could of course add definitions for messages, id, state, behaviour and
interface.
>>>It might be functions in OO
>>>clothing.
>>
>>Think of functions as objects.
>
>
> I suppose one could. But that does not necessarily mean that one
> should. C2.com lists about 20 "everything is an X" mental models that
> one could take. Lisp fans see everything as a regular expression, for
> example.
LOL ! Worth an entry in fortune.
> Indeed everything could be modelled that way. Whether it
> *should* is another story.
Lispers see everything as lists (not regex), because lists are the
central data structures in Lisp (FWIW, Lisp stands for List Processing),
and are what allow to have a uniform representation of both code and
data. FWIW, functional programming sees everything as functions, because
it allows a uniform model too. And OO sees everything as objects for the
very same reason.
>
>>>>>And the granularity of poly is often not fine enough. How do you
>>>>>override HALF of a method? (without duplicating some behavior).
>>>>
>>>>Refactor into distinct methods and only override the one that needs to be.
>>>
>>>
>>>That is not making code change-friendly,
>>
>>Yes it is. OO design (and FWIW, it's not restricted to OO, you'll find
>>the same thing in FP and even in plain procedural) is about decoupling
>>variance from invariant. The standard C sort() function does this. It
>>decouple the invariant part (the sort algorithm) from the variant part
>>(the actual type of objects being sorted and the comparison function
>>that defines sort order). It's CS 101.
>
> I am judging the total change effort and not giving much of a
> "discount" just because it may be the implementation that has to be
> changed instead of the interface. Change work is change work. A bad
> implementation change will bust the system as much as a bad interface
> change.
Do you have any change to make to the standard C sort function to use it
for any type and any ordering function ?
>>>that is giving in to the
>>>Change Gods. Such refactoring will involve a fair amount of code
>>>moving.
>>
>>blah blah.
>
>
> Hand-wave if you want. Change work is change work.
*which* 'change work' ? Hint: answer the previous question first...
>
>>
>>>>>You can refine them without moving lots of code around.
>>>>>Polymorphism artificially couples your code to specific nouns and
>>>>>specific noun taxonomies.
>>>>
>>>>Please learn what polymorphism mean in CS.
>>>
>>>
>>>Nobody really agrees, I have found out.
>>
>>http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
>
>
> That redirects me to "type polymorphism". Type polymorphism is just one
> kind of polymorphism.
Have you read the whole paper ?
>
>>>>It's by no way OO specific,
>>>>and even in OO it doesn't have to be tied to class hierarchies.
>>>
>>>The topic is about polymorphism.
>>>
>>The topic is about your lack of understanding of what polymorphism is.
>
> You appear to be the one ignorant of all the potential definitions and
> viewpoints of poly are. There is no consensus definition. An informed
> person who has been around the block knows this.
Your original argument is that polymorphism couples to tightly because
it requires a rigid hierarchical taxonomy. I give you examples of
polymorphism that don't require this (and FWIW pointers to examples of
polymorphism not implying OO at all. So your argument doesn't stand.
I do use the features described above on a daily basis. My job is to
write web applications, which includes business apps. This is not "lab
example".
>
>>>most polymorphism involve an explicit or implicit
>>>hierarchy or "list" of mutually-exclusive "kinds" of things.
>>
>>polymorphism *by definition* (look for an etymology of the word) involve
>>many (implied 'different') "kinds" of "things". It's even the whole
>>point of polymorphism in CS : uniform handling of heterogenous types.
>
>
> Not every OO proponent agrees that poly is about "types". This also
> gets into the messy issue of what a "type" is.
indeed.
>
>>> About 90%
>>>of all the poly I see does. This is probably why you had to use a
>>>foobar example instead of something like employees or bonds, etc.
>>
>>Please demonstrate why the above could not be applied to any domain.
>
> First of, "can" and "should" are two different things.
What you wrote about "foobar example" (and now with "lab example") imply
that the features I showed can not be used in real life. So I challenge
you to back your claim. Please, no diversion.
> If I see a fair
> amount of decent examples for my domain, I may change my stance. Until
> them, I am skeptical of OOP working for my domain.
Did I make any claim about OO being appropriate (or not) for business apps ?
> If you write device
> drivers and word processors for a living, poly may be great there. I
> won't challenge that domain.
And ? Please focus on your argument about the reasons why polymorphism
is not usable in business apps.
>
>>>>OO is certainly not a silver bullet - nor are RDBMS. Both are useful
>>>>tools when you know how to use them. Both are useless when you don't
>>>>know how to use them. IOW, stop talking about what you just don't
>>>>understand.
>>>
>>>
>>>Paternalistic insults?
>>
>>Nope, simple constatation and friendly advice. Your arguments fail to
>>demonstrate that OO is not suited for business app (which doesn't imply
>>it is),
>
>
> I didn't take it as friendly.
Sorry.
> If you want to "educate" an allegedly
> ignorant person such as me, then show me examples from my domain of
> poly objectively improving code.
Did I make any claim about polymorphism improving code ?
> I am not taking your word for it
Which words ? Please quote...
> because everybody on the web thinks they are smarter than everybody
> else. I cannot distinquish you from all the pretenders.
I'm certainly not pretending being smarter than anyone. And I honnestly
admit having proven my own stupidity or ignorance on many occasions.
>
>>but clearly demonstrate your lack of understanding of OO (which
>>doesn't imply that most people writing 'OOP training example' have a
>>better understanding).
>
>
> I understand the mechanics and written philosophy of OO. What I don't
> understand is why it is allegedly better for building custom biz apps.
Did I make such a claim ?
> I want to see concrete examples. I am tired of brochure-talk and shape,
> animal, and device-driver examples.
And you're totally right on this point. FWIW, I wholefully share your
annoyment with all the dumbiest canonical examples and PHB-directed
marketing crap.
>
>>>I understand it perfectly fine. I just have not
>>>seen EVIDENCE of it being better.
>>
>>"better" than what, and according to which metric ?
>
>
> I don't know.
Well... You don't see "EVIDENCE of (OO) being better" than you don't
know what according to you don't know which metrics ?
What can I add ?
> I didn't claim it better so I don't know how to show it
> better.
Common understanding of of value judgements is that A is either worse
than, as good as or better than B (or not comparable to...) according to
a given metric. Note that this requires an alternative and a metric...
Until you provide both, "better" (or "worse" etc) has no meaning.
> I can't get specifics.
Yes, I think we've all noticed this already.
> If nobody can articulate exactly why it
> is better
Still no meaning.
> with change scenarios etc, then perhaps it is indeed all
> subjective.
Or (non-exclusive) perhaps does it depends on the kind of changes. But
still we don't know what we are comparing to, so it's all meaningless.
> My stance is that paradigms are a probably subjective
> preference
Then why do you spend so much time on this newsgroup (and on c2) trying
to demonstrate that OO is ill-suited for business apps ?
> and that there is no demonstrable-objective silver bullet,
> or even a brass bullet.
I'd say that the particularity of silver-bullets is to be the mythical
solution to a mythical problem. If you agree on this definition, there
is *of course* no "demonstrable-objective" silver bullet !-)
>
>>OO can help managing some kind of complexity, and can add some other
>>kind of complexity too. No sliver bullet as usual.
(ot: s/sliver/silver/)
>
> Yes, but can you show it being at least a brass bullet?
I wouldn't even try.
>
>>My point is definitively not to demonstrate that 'OO is better', just to
>>make clear that your arguments againts OO only demonstrate your lack of
>>understanding of OO. If you intend to demonstrate the superiority of
>>approach A over approach B for domain C, you need to master approach A,
>>approach B and domain C. This is not the case. Period.
>
>
> "Master" tends to mean "do and think my way" in web discussions.
Strange enough, I tend to consider as "masters" peoples that not
necessarily "do and think my way", but are mostly able to improve the
way I do and think. This usually imply them having a pretty good working
knowledge on the topic.
> That
> is not dissectable and analyzable, at least not in the western
> reductionalist stanpoint.
Not doing philosophy, thanks.
>
>>
>>>I have not even seen a custom biz
>>>examples that fellow OOP fans agree is a good example.
>>
>>Not being a 'fan' of anything, I'm not concerned with this.
>>
>>
>>>You haven't even
>>>pleased your own kind,
>>
>>Care to explain what you mean here ?
>
>
> Nobody has presented an example code of a custom biz app that even OOP
> proponents agree is an example of good OOP code. Somebody once proposed
> the Java "pet store" example, but many OO proponents have dissagreed.
Did I present any example of code of a business app ? Not AFAIK.
> There is nothing to compare and analyze and scrutinize. It is all
> anecdotal evidence. Should I accept anecdotal evidence?
This is another question, and I don't have any answer on it. But I still
fail to understand the meaning of the sentence "You haven't even
pleased your own kind,", and it's relevance here.
>>>so stop trying to dump the biz gap in MY lap.
>>>Not having found something that passes even your peers and me being
>>>allegedly dumb are not related.
>>
>>Effectively. FWIW, the "decoupling variance from invariant" part is
>>certainly something anyone here would agree upon,
>
>
> I've found that not everybody even agrees on what is invariant.
In the standard C sort() function, the invariant (wrt/ the function
interface) is the sort algorithm. It should be obvious that what is
invariant and what is not greatly depends on the specific problem and
context (and that for some domains and/or contexts, it may not be easy
to know for sure the kind and probability of change for anything).
> As
> mentioned above, people perceive change differently such that they code
> for different change probability profiles.
>
>
>>> Bad debaters often call the other
>>>person dumb when cornered. Smart debaters don't have to because they
>>>can SHOW. Good debaters kill with examples and code and scenarios, not
>>>with names. Names are for amatures.
>>
>>What's funny with this is that :
>>1/ I didn't called you names
>
>
> You accused me of being ignorant about OO.
I assert that you don't understand OO and hence don't know how to use it.
Is that an "accusation" ? It's not a tribunal here AFAIK, and not
understanding OO is not criminal nor even delictuous.
Is that an insult ? Well, the last time I told my wife she didn't
understood OO, she didn't seem to think it was an insult. In fact, she
laughed and confirmed. And as far as I'm concerned, the last times I've
been proven wrong or ignorant on some topics, I gracefully (well... more
or less gracefully) admitted the point.
So, I'm sorry for you if you want to take my above assertion as an
insult, but then I also refuse to be held responsible for your emotive
over-reaction.
>>2/ I gave a working example that counters your arguments
>
> Being right in theory is not the same as being right in practice.
If I'm right in theory, then the practice is wrong.
> If
> 99% of actual production code makes subtypes in order to use poly,
I think it's actually less, but that's another point. Now please note
that "makes subtypes" greatly depends on the definition of "subtyping".
According to Liskov, if in program P you can substitute object B to
object A without breaking P (read : P doesn't crash and continue to
produce correct outputs), than the type of B is a subtype of the type of
A. This implies that subtypes are in fact *determined* by polymorphism -
and in know way requires a rigid hierarchical type taxonomy.
The fact that the most mainstream (read : overselled to PHB with
silver-bullet like marketing arguments) "OO" languages requires rigid
types taxonomy for polymorphic dispatch to work is mostly irrelevant. It
only proves that
1/ with enough money to back your marketing plan, you can sell anything
to PHBs - which is alas nothing new.,
2/ being "mainstream" (read: buzzword-compliant) doesn't imply being
right - and this not new neither.
> then
> the fact that poly does not technically need subtypes
cf above about the relation between polymorphism and subtyping.
> may not mean much
> as far as utility.
FWIW, the fact that SQL DBMS fails to implement the relational model
doesn't say much about the utility of both the relational model and SQL
DBMS.
>
>>3/ As a result, *you* make it a personal affair.
>>
>>Please take your own medicine.
>
>
> I'll spank myself on the weekend.
Good boy !-)
topmind
Patrick May wrote:
> "topmind" <top...@technologist.com> writes:
> > Lisp fans see everything as a regular expression, for example.
>
> Is this a typo? Common Lisp doesn't even include a regular
> expression package in the standard. (I use CL-PPCRE, but there are
> other options available.)
Sorry, I meant S-expressions (or "ess-expressions"). Thanks for
pointing that out.
Bruno Desthuilliers
> topmind wrote:
>
(snip)
>
>>If
>>99% of actual production code makes subtypes in order to use poly,
>
>
> I think it's actually less, but that's another point. Now please note
> that "makes subtypes" greatly depends on the definition of "subtyping".
> According to Liskov, if in program P you can substitute object B to
> object A without breaking P (read : P doesn't crash and continue to
> produce correct outputs), than the type of B is a subtype of the type of
> A. This implies that subtypes are in fact *determined* by polymorphism -
> and in know way requires a rigid hierarchical type taxonomy.
>
>
>>then
>>the fact that poly does not technically need subtypes
>
>
> cf above about the relation between polymorphism and subtyping.
>
I actually meant "a possible relation", not "the". There's of course
much more to typing and polymorphism than LSP.
topmind
I cannot speak for OO affectionado's, but I doubt you would find
agreement. In fact, I would bet money on it if this was in the Vegas
books.
>
> > By the way, you used "object" to define "object", more or less.
> > Thus,
> > you have a recursive definition.
> >
>
> Let's check:
> - definition of "object oriented":
> """
> OO is about organizing a program in terms of objects communicating by
> messages
> """
>
> No recursive definition here.
If OO = Object oriented, it is essentially recursive. Saying that "foo
oriented programming has foo's", is redundant, or at least trivial to
most. Perhaps it was meant for thoroughness, which is forgivable, but
not useful for describing it here.
>
> - definition of "object":
> """
> 'object' being defined as 'id + state + behaviour +
> interface'
> """
So do RDBMS. Does that make them OO?
>
> > Indeed everything could be modelled that way. Whether it
> > *should* is another story.
>
> Lispers see everything as lists (not regex), because lists are the
> central data structures in Lisp (FWIW, Lisp stands for List Processing),
It was a typo. It should be "ess-expression", not "regular expression".
> and are what allow to have a uniform representation of both code and
> data. FWIW, functional programming sees everything as functions, because
> it allows a uniform model too. And OO sees everything as objects for the
> very same reason.
>
> >
> >>>>>And the granularity of poly is often not fine enough. How do you
> >>>>>override HALF of a method? (without duplicating some behavior).
> >>>>
> >>>>Refactor into distinct methods and only override the one that needs to be.
> >>>
> >>>
> >>>That is not making code change-friendly,
> >>
> >>Yes it is. OO design (and FWIW, it's not restricted to OO, you'll find
> >>the same thing in FP and even in plain procedural) is about decoupling
> >>variance from invariant. The standard C sort() function does this. It
> >>decouple the invariant part (the sort algorithm) from the variant part
> >>(the actual type of objects being sorted and the comparison function
> >>that defines sort order). It's CS 101.
> >
> > I am judging the total change effort and not giving much of a
> > "discount" just because it may be the implementation that has to be
> > changed instead of the interface. Change work is change work. A bad
> > implementation change will bust the system as much as a bad interface
> > change.
>
> Do you have any change to make to the standard C sort function to use it
> for any type and any ordering function ?
I don't write sort algorithms for a living. Whether OO helps with that
I not is irrelavent to me. It is essentially another Systems Software
example. I have already "surrendured" systems software to OO years ago.
I just want something that helps *my* domain. OO'ers are
over-extrapolating.
> >>>>>You can refine them without moving lots of code around.
> >>>>>Polymorphism artificially couples your code to specific nouns and
> >>>>>specific noun taxonomies.
> >>>>
> >>>>Please learn what polymorphism mean in CS.
> >>>
> >>>
> >>>Nobody really agrees, I have found out.
> >>
> >>http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
> >
> >
> > That redirects me to "type polymorphism". Type polymorphism is just one
> > kind of polymorphism.
>
> Have you read the whole paper ?
No. Is there any spot you wish to point out?
Smalltalkers, for example, generally view polymorphism as different
objects being able to answer the same message (same named method).
Example:
A.foo(); // not smalltalk, just an example
B.foo();
Here object A and object B both answer the message "foo". There may be
no connection between A and B whatsoever. And, there is no "type
checking". It has nothing to do with "types".
>
> >
> >>>>It's by no way OO specific,
> >>>>and even in OO it doesn't have to be tied to class hierarchies.
> >>>
> >>>The topic is about polymorphism.
> >>>
> >>The topic is about your lack of understanding of what polymorphism is.
> >
> > You appear to be the one ignorant of all the potential definitions and
> > viewpoints of poly are. There is no consensus definition. An informed
> > person who has been around the block knows this.
>
> Your original argument is that polymorphism couples to tightly because
> it requires a rigid hierarchical taxonomy. I give you examples of
> polymorphism that don't require this (and FWIW pointers to examples of
> polymorphism not implying OO at all. So your argument doesn't stand.
Technically you are 100% correct. However, I wish to deal with
*practicality*. If you don't, then I guess we should part ways.
> > I mean a real case of polymorphism that one encounters in the *field*.
> > Of course a "lab example" can be made non-hierarchical. I don't dispute
> > that.
>
> I do use the features described above on a daily basis. My job is to
> write web applications, which includes business apps. This is not "lab
> example".
That's great. That means you can provide some specific actual scenarios
so that I don't have to take your word for it anymore....
And I agree there are a few places where OOP could help in my biz apps.
But it is such a small percentage that it does not make sense to mix
paradigms.
> >>> About 90%
> >>>of all the poly I see does. This is probably why you had to use a
> >>>foobar example instead of something like employees or bonds, etc.
> >>
> >>Please demonstrate why the above could not be applied to any domain.
> >
> > First of, "can" and "should" are two different things.
>
> What you wrote about "foobar example" (and now with "lab example") imply
> that the features I showed can not be used in real life. So I challenge
> you to back your claim. Please, no diversion.
I did not say that. If they *are* practical in real life, then simply
show realistic examples of it being so. I didn't claim that unicorns
didn't exist, I only claim that I've never seen any.
>
> > If I see a fair
> > amount of decent examples for my domain, I may change my stance. Until
> > them, I am skeptical of OOP working for my domain.
>
> Did I make any claim about OO being appropriate (or not) for business apps ?
You implied it. If that is not the case, then perhaps we don't have a
disagreement afterall.
>
> > If you write device
> > drivers and word processors for a living, poly may be great there. I
> > won't challenge that domain.
>
> And ? Please focus on your argument about the reasons why polymorphism
> is not usable in business apps.
I did not say it was not usable. I am only saying I have yet to see
frequent *good* uses for it. I am not saying that don't exist, I am
only saying I have not seen any and thus remain skeptical. Again, the
unicorn analogy.
> >>>I understand it perfectly fine. I just have not
> >>>seen EVIDENCE of it being better.
> >>
> >>"better" than what, and according to which metric ?
> >
> >
> > I don't know.
>
> Well... You don't see "EVIDENCE of (OO) being better" than you don't
> know what according to you don't know which metrics ?
Huh? I didn't make the claim. If you claim X is better, you are
obligated to show that X is better. You can use whatever metrics you
want (subject to scrutiny of course). You claim unicorns exist, you
show the evidence. Whether it is film, footprints, eyewitnesses, that
is up to you.
>
> What can I add ?
>
>
> > I didn't claim it better so I don't know how to show it
> > better.
>
> Common understanding of of value judgements is that A is either worse
> than, as good as or better than B (or not comparable to...) according to
> a given metric. Note that this requires an alternative and a metric...
> Until you provide both, "better" (or "worse" etc) has no meaning.
No. It could all be subjective. It could be that some like paradigm A
and some like paradigm B with there being no objectively measurable
benefits between them.
Now, please don't ask me to objectively prove that subjectivity exists
:-)
One debater did that once. I laughed all day. Something like, "If you
claim it subjective, then you are obligated to objectively prove your
case."
> > with change scenarios etc, then perhaps it is indeed all
> > subjective.
>
> Or (non-exclusive) perhaps does it depends on the kind of changes. But
> still we don't know what we are comparing to, so it's all meaningless.
That is why I wish to see realistic biz examples.
>
> > My stance is that paradigms are a probably subjective
> > preference
>
> Then why do you spend so much time on this newsgroup (and on c2) trying
> to demonstrate that OO is ill-suited for business apps ?
Somebody else suggested that OO was superior, implying all domains. I
thus put the pressure on them to demonstrate it.
> >>My point is definitively not to demonstrate that 'OO is better', just to
> >>make clear that your arguments againts OO only demonstrate your lack of
> >>understanding of OO. If you intend to demonstrate the superiority of
> >>approach A over approach B for domain C, you need to master approach A,
> >>approach B and domain C. This is not the case. Period.
> >
> >
> > "Master" tends to mean "do and think my way" in web discussions.
>
> Strange enough, I tend to consider as "masters" peoples that not
> necessarily "do and think my way", but are mostly able to improve the
> way I do and think. This usually imply them having a pretty good working
> knowledge on the topic.
IMO, the best teachers use explicit examples coupled with explanation.
English is not very useful by itself for software concepts because it
is meant for a physical world, not a virtual one.
> >>>so stop trying to dump the biz gap in MY lap.
> >>>Not having found something that passes even your peers and me being
> >>>allegedly dumb are not related.
> >>
> >>Effectively. FWIW, the "decoupling variance from invariant" part is
> >>certainly something anyone here would agree upon,
> >
> >
> > I've found that not everybody even agrees on what is invariant.
>
> In the standard C sort() function, the invariant (wrt/ the function
> interface) is the sort algorithm. It should be obvious that what is
> invariant and what is not greatly depends on the specific problem and
> context (and that for some domains and/or contexts, it may not be easy
> to know for sure the kind and probability of change for anything).
Yes yes, but not for many of the other scenarios that I've dealt with.
Sorts are easy to deal with that way, but not very representative of
real-stuff that I encounter.
Sorting has been dissected every which way til Sunday. Still, its
lessons are limited. Many things don't fit the same pattern. I wish it
did, then life would be simple.We could plug things in Lego-like
without worrying about messy little exceptions and variations.
> >
> > You accused me of being ignorant about OO.
>
> I assert that you don't understand OO and hence don't know how to use it.
Dissagreeing with your pet definitions is not the same as not
understanding.
>
> Is that an "accusation" ? It's not a tribunal here AFAIK, and not
> understanding OO is not criminal nor even delictuous.
>
> Is that an insult ? Well, the last time I told my wife she didn't
> understood OO, she didn't seem to think it was an insult. In fact, she
> laughed and confirmed. And as far as I'm concerned, the last times I've
> been proven wrong or ignorant on some topics, I gracefully (well... more
> or less gracefully) admitted the point.
>
> So, I'm sorry for you if you want to take my above assertion as an
> insult, but then I also refuse to be held responsible for your emotive
> over-reaction.
It is rude because one has no way to easily defend themself whether
wrong or correct. It is similar to, "Have you stopped beating your wife
yet?" General, open-ended accusations should be avoided if you desire
to be diplomatic (many don't).
>
> > If
> > 99% of actual production code makes subtypes in order to use poly,
(99% was meant as hypothetical. I didn't make that clear and
apologize.)
>
> I think it's actually less, but that's another point. Now please note
> that "makes subtypes" greatly depends on the definition of "subtyping".
> According to Liskov, if in program P you can substitute object B to
> object A without breaking P (read : P doesn't crash and continue to
> produce correct outputs), than the type of B is a subtype of the type of
> A. This implies that subtypes are in fact *determined* by polymorphism -
> and in know way requires a rigid hierarchical type taxonomy.
That is sustitutability of objects. If you have objects A, B and C that
all respond to the same message/method "foo", then they are essentially
*conceptually* "sub-types" from the perspective of "foo". Sub-typing
does not require an explicit hierarchy. (Although, there are probably
many variations on the term "subtype".)
> > may not mean much
> > as far as utility.
>
> FWIW, the fact that SQL DBMS fails to implement the relational model
> doesn't say much about the utility of both the relational model and SQL
> DBMS.
I meant "can do X" versus "should do X".
>
> >
> >>3/ As a result, *you* make it a personal affair.
> >>
> >>Please take your own medicine.
> >
> >
> > I'll spank myself on the weekend.
>
> Good boy !-)
Bow wow woof, scratch scratch lick.
Please take my wonderful shiney Gift of Appreciation I left on your
front lawn. Custom made just for you ;-)
>
> --
> bruno desthuilliers
-Dogmind-
Robert Martin
> Robert Martin wrote:
>> On 2006-07-05 23:02:34 -0500, "topmind" <top...@technologist.com> said:
>>
>>> Procedural/relational is *just* as factorable with regard to
>>> duplication as OOP. If you disagree, then produce code that proves it.
>>>
>>>
>>> And please, not yet another case/switch statement battle. The topic is
>>> beat to death here:
>>> http://c2.com/cgi/wiki?SwitchStatementsSmell
>>
>> Translation:
>>
>> OK all you know-it-all OO evangelists, just shown me one instance of
>> procedural code that OO is better at removing duplication from; but no
>> fair using code that OO is good at removing duplication from.
>>
>> End translation.
>
> I am not sure what you are refering to. Lack of custom business
> examples? Why does that make me bad?
Silly boy! I was referring to your exclusion of switch/case
statements. One of the advantages of OO is the ability to replace
repetative switch/cases statments with jump tables (i.e. dynamic
polymorphism).
>
> Polymorphism being good in domain X does not automatically mean it is
> good in domain Y.
It has nothing to do with domain. It has to do with managing
dependencies between modules. If I have a selector (i.e. a switch/case
statement) in a given module, and if that selector delegates to many
differen modules, then the selector module has a large fan-out. (I
call it a high efferent coupling (Ce) but nobody understands what that
means <grin>) A module with a high fan-out (a high Ce) is, of course,
coupled to many lower level modules (i.e. the modules that the selector
delegates to).
|Module|
|
+----+---+----+----+
| | | | |
V V V V V
|A| |B| |C| |D| |E|
Using OO we can change this coupling as follows
|Module|------>|Interface|
A
|
+---+---+---+---+
| | | | |
|A| |B| |C| |D| |E|
This is not always a better structure. But often it is. It breaks the
depenence of Module upon the lower level modules, and causes those
lower level modules to *DO* the depending instead of being depended
upon.
Who wouldn't want this tool in their toolbox. You don't use it for
everything of course, but it's a great way to manage dependencies.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Robert Martin
> I don't think OOP is good for every type of application, in particular
> Web and CRUD heavy business apps aren't the best showcase for it but
> rich GUI apps are.
I disagree. Web and CRUD applications can make very nice use of OO
because WEB and CRUD application have modules that depend upon each
other. Those dependencies need to be managed.
Bruno Desthuilliers
(snip)
> IF statements are simply more bendable and flexible to handle real-world
But not without modifying existing code. And in a lot of cases modifying
it in *many* places. What polymorphism brings is mainly using another
way of doing the dispatch that doesn't require explicit branching - so
it doesn't require modification of the calling code. This is of course
not enough to isolate all code of all possible change, but it's still a
pretty useful tool -- and a very often used, one way or another.
(snip - already addressed in some other post)
> If one is going to hammer on "coupling", then
> you cannot pick and choose which coupling you keap and which you reject
> without justification.
Not "without justification".
> If *all* coupling is bad,
Where did you get the baroque idea that "all" coupling would be bad ?
What we want is to avoid coupling between parts that have (or may have)
to change independantly (and I agree that deciding what should be
decoupled from what is not always easy). Now the problem addressed by
polymorphism is how to decouple usage from implementation (not to
decouple from usage from usage, which would be totally meaningless) . In
other terms, it's a matter of "what, not how" - something that DBMS try
to solve in the domain of data management BTW.
topmind
> On 2006-07-07 00:15:53 -0500, "topmind" <top...@technologist.com> said:
>
> > Robert Martin wrote:
> >> On 2006-07-05 23:02:34 -0500, "topmind" <top...@technologist.com> said:
> >>
> >>> Procedural/relational is *just* as factorable with regard to
> >>> duplication as OOP. If you disagree, then produce code that proves it.
> >>>
> >>>
> >>> And please, not yet another case/switch statement battle. The topic is
> >>> beat to death here:
> >>> http://c2.com/cgi/wiki?SwitchStatementsSmell
> >>
> >> Translation:
> >>
> >> OK all you know-it-all OO evangelists, just shown me one instance of
> >> procedural code that OO is better at removing duplication from; but no
> >> fair using code that OO is good at removing duplication from.
> >>
> >> End translation.
> >
> > I am not sure what you are refering to. Lack of custom business
> > examples? Why does that make me bad?
>
> Silly boy! I was referring to your exclusion of switch/case
> statements. One of the advantages of OO is the ability to replace
> repetative switch/cases statments with jump tables (i.e. dynamic
> polymorphism).
Replacing it with repeative OO code is simply exchanging rain for hail.
The equiv case/switch statement is *not less code*.
http://www.geocities.com/tablizer/inher.htm
I see the same amount of repetition. Further, case/switch is easier to
change into non-mutually-exclusive options. Just change the CASE blocks
into IF blocks. The equiv change in OOP would be moving code to
different classes, a costlier change.
I don't want to get into another case/switch-vs-poly holy war anyhow. I
am tired of them. See here for a typical battle:
http://c2.com/cgi/wiki?SwitchStatementsSmell
Well, it is a technique that is waaaaaaay oversold. It has duped
Dilbertian bosses the world over. And even many OO affectionado's will
admit that too many newbies abuse it and go hog-wild with class
hierarchies. Plus, if we load up our toolbox with every marginally good
idea, we would have 10 paradigms in there such that nobody can read our
code. It may be good job security for the purpretrator, but not very
economical.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
> On 2006-07-07 07:32:30 -0500, "Alvin Ryder" <alvi...@telstra.com> said:
>
> > I don't think OOP is good for every type of application, in particular
> > Web and CRUD heavy business apps aren't the best showcase for it but
> > rich GUI apps are.
>
> I disagree. Web and CRUD applications can make very nice use of OO
> because WEB and CRUD application have modules that depend upon each
> other. Those dependencies need to be managed.
I would welcome some coded examples, something like the Campus example,
that show it being better than procedural/relational, perhaps with some
realistic change scenarios, not the bogus ones the OO books like to
use. (The only real "reuse" in the OO books is cloning the stupid
change scenarios.)
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
> topmind a écrit :
> (snip)
> > IF statements are simply more bendable and flexible to handle real-world
> > changes. You can refine them without moving lots of code around.
>
> But not without modifying existing code. And in a lot of cases modifying
> it in *many* places. What polymorphism brings is mainly using another
> way of doing the dispatch that doesn't require explicit branching - so
> it doesn't require modification of the calling code. This is of course
> not enough to isolate all code of all possible change, but it's still a
> pretty useful tool -- and a very often used, one way or another.
When I see it in my domain, I will beleive you. It does not work in the
real world like it does in shape, animal, and device-driver book
examples. The real world (at least in my domain) does not change that
way. The books set up an artificial strawman, and then knock it down
with polymorphism.
>
> (snip - already addressed in some other post)
>
> > If one is going to hammer on "coupling", then
> > you cannot pick and choose which coupling you keap and which you reject
> > without justification.
>
> Not "without justification".
>
> > If *all* coupling is bad,
>
> Where did you get the baroque idea that "all" coupling would be bad ?
It is a hypothetical question testing an idea, not a claim.
> What we want is to avoid coupling between parts that have (or may have)
> to change independantly (and I agree that deciding what should be
> decoupled from what is not always easy). Now the problem addressed by
> polymorphism is how to decouple usage from implementation (not to
> decouple from usage from usage, which would be totally meaningless) . In
> other terms, it's a matter of "what, not how" - something that DBMS try
> to solve in the domain of data management BTW.
I am perfectly aware and highly conscience of change and change
patterns to code. Generally there is no free lunch, it is all a
compromise between competiting factors. But *overall* I find Sets one
of the best tools for managing changes. For one, they don't have the
mutual-exclusiveness problems that poly tends to. This is based on
*experience*. I did not walk out of school beleiving that sets were
nice. If you really care about change management, then persue Sets. I
find them far more promising than polymorphism. (RDBMS are currently
the best available Set tools.) If there is a Silver bullet, sets will
come closer than poly.
As Popeye might say, I bets on sets.
Poly can kiss my cracker.
-T-
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>
>>topmind wrote:
>>
(snip)
>
>>>>
>>>>OO is about organizing a program in terms of objects communicating by
>>>>messages, 'object' being defined as 'id + state + behaviour +
>>>>interface'. Nothing in this definition imply rigid hierarchical taxonomy
>>>>AFAICT.
>>>
>>>
>>>I've seen about 7 or so primary definitions of OOP. I've chucked them
>>>all and now use my own working definition instead (which does not
>>>differ much from Robert Martin's, actually). There is no consistent
>>>consensus definition of OOP out there. It makes it hard to pin down
>>>what is OO and what isn't.
>>
>>Indeed. But AFAICT, the definition I used should be agreed upon by
>>almost anyone here, should not contradict most usual definitions, and
>>should be appliable to most OOPLs and/or systems claiming to be OO. If
>>you can prove me wrong, please do.
>
> I cannot speak for OO affectionado's,
I think they can speak by themselves.
> but I doubt you would find
> agreement.
We'll see. You'll notice the use of the "AFAICT", which usually means
"as far as I can tell".
> In fact, I would bet money on it if this was in the Vegas
> books.
Don't understand.
>
>
>>>By the way, you used "object" to define "object", more or less.
>>>Thus,
>>>you have a recursive definition.
>>>
>>
>>Let's check:
>>- definition of "object oriented":
>>"""
>>OO is about organizing a program in terms of objects communicating by
>>messages
>>"""
>>
>>No recursive definition here.
>
>
> If OO = Object oriented, it is essentially recursive.
Oh, yes. Well, just like using "function" in a definition of "functional
programming", "procedure" in a definition of "procedural programming",
and "relation" in a definition of "relational model", that's it ?
(snip)
>>- definition of "object":
>>"""
>>'object' being defined as 'id + state + behaviour +
>>interface'
>>"""
>
>
> So do RDBMS.
If you considere constraints + triggers + stored procs as behaviour and
"select, insert, update, delete" as messages (which implies a very
uniform interface...), well, why not ? But this would probably make a
somewhat restricted object model IMHO.
(snip)
>>Lispers see everything as lists (not regex), because lists are the
>>central data structures in Lisp (FWIW, Lisp stands for List Processing),
>
> It was a typo. It should be "ess-expression", not "regular expression".
Talk about a typo !-)
(snip)
>>Do you have any change to make to the standard C sort function to use it
>>for any type and any ordering function ?
>
>
> I don't write sort algorithms for a living.
That's totally irrelevant here.
And the
> Whether OO helps with that
It's not OO, it's the standard lib. And it's about polymorphism.
> I not is irrelavent to me. It is essentially another Systems Software
> example.
Either your memory is bad or you fail to make the connection with your
initial question about "How do you override HALF of a method? (without
duplicating some behavior)". FWIW, you can s/method/function/, the
answer is obviously : "by separating the parts". In the C sort example -
like in almost every non-trivial C program, be it a business app - it's
done with void pointers and function pointers so you can parameterize
one algorithm with different types. This is also done quite a lot in
functional programming. This can be done in OO too - and is effectively,
eventually using a "function-like" object if the language doesn't
support first class functions, or code blocks like in Smalltalk. OO
brings another idiom of it's own with "template methods" - perhaps the
most known and used OO designed pattern (FWIW, I used it years before I
first heard mention of design patterns).
> I have already "surrendured" systems software to OO years ago.
Is standard C sort OO ?-)
> I just want something that helps *my* domain.
Why do you think the same technical problem would require a different
technical solution according to the domain ?
> OO'ers are
> over-extrapolating.
If by this you mean "when faced to the same known problem, try to solve
it with the same known solution", yes, possibly. But that would be a
rather strange definition.
>
>>>>>>>You can refine them without moving lots of code around.
>>>>>>>Polymorphism artificially couples your code to specific nouns and
>>>>>>>specific noun taxonomies.
>>>>>>
>>>>>>Please learn what polymorphism mean in CS.
>>>>>
>>>>>
>>>>>Nobody really agrees, I have found out.
>>>>
>>>>http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
>>>
>>>
>>>That redirects me to "type polymorphism". Type polymorphism is just one
>>>kind of polymorphism.
>>
>>Have you read the whole paper ?
>
>
> No. Is there any spot you wish to point out?
Not really, I just wondered.
> Smalltalkers, for example, generally view polymorphism as different
> objects being able to answer the same message (same named method).
> Example:
>
> A.foo(); // not smalltalk, just an example
> B.foo();
>
> Here object A and object B both answer the message "foo". There may be
> no connection between A and B whatsoever. And, there is no "type
> checking".
You can do the same in OCaml, which is a stronly, statically typed
language. And without any *declared* relationship between type A and type B.
> It has nothing to do with "types".
Depends on how you define "type".
If of course you define a type as "a label I explicitly put in front of
some definition of a set of values and a set of operations on this set
of values", no, it has nothing to do with types. But then it would prove
that you don't need rigid hierachical type taxonomy for OO polymorphic
dispatch to work.
>>>>>>It's by no way OO specific,
>>>>>>and even in OO it doesn't have to be tied to class hierarchies.
>>>>>
>>>>>The topic is about polymorphism.
>>>>>
>>>>
>>>>The topic is about your lack of understanding of what polymorphism is.
>>>
>>>You appear to be the one ignorant of all the potential definitions and
>>>viewpoints of poly are. There is no consensus definition. An informed
>>>person who has been around the block knows this.
>>
>>Your original argument is that polymorphism couples to tightly because
>>it requires a rigid hierarchical taxonomy. I give you examples of
>>polymorphism that don't require this (and FWIW pointers to examples of
>>polymorphism not implying OO at all. So your argument doesn't stand.
>
> Technically you are 100% correct. However, I wish to deal with
> *practicality*.
It's up to you. You can verify by yourself that my example works (with
provision for eventual typos), and apply the techniques in your next
program. Of course, this won't cure cancer...
> If you don't, then I guess we should part ways.
>
>>>I mean a real case of polymorphism that one encounters in the *field*.
>>>Of course a "lab example" can be made non-hierarchical. I don't dispute
>>>that.
>>
>>I do use the features described above on a daily basis. My job is to
>>write web applications, which includes business apps. This is not "lab
>>example".
>
> That's great. That means you can provide some specific actual scenarios
> so that I don't have to take your word for it anymore....
Come and work with us, you'll see by yourself. We're in France, in
Bordeaux. Want to apply for a position ?
> And I agree there are a few places where OOP could help in my biz apps.
> But it is such a small percentage that it does not make sense to mix
> paradigms.
I happily mix them all. "Use the right tool for the right job", as they
say...
>
>>>>>of all the poly I see does. This is probably why you had to use a
>>>>>foobar example instead of something like employees or bonds, etc.
>>>>
>>>>Please demonstrate why the above could not be applied to any domain.
>>>
>>>First of, "can" and "should" are two different things.
>>
>>What you wrote about "foobar example" (and now with "lab example") imply
>>that the features I showed can not be used in real life. So I challenge
>>you to back your claim. Please, no diversion.
>
> I did not say that.
Really ?
> If they *are* practical in real life, then simply
> show realistic examples of it being so.
>I didn't claim that unicorns
> didn't exist, I only claim that I've never seen any.
I don't claim that Pluton (or is that Pluto ? You know, the planet...)
doesn't exists, I only claim I've never seen it. I could of course buy a
telescope and learn about astronomy...
>
>>>If I see a fair
>>>amount of decent examples for my domain, I may change my stance. Until
>>>them, I am skeptical of OOP working for my domain.
>>
>>Did I make any claim about OO being appropriate (or not) for business apps ?
>
>
> You implied it.
Implied what ? that OO is appropriate for business apps ? Or that it is
not ? And where ?
> If that is not the case, then perhaps we don't have a
> disagreement afterall.
We have a disagreement on your assertions that polymorphism couples
and it's not practically useful in "business applications".
>
>>>If you write device
>>>drivers and word processors for a living, poly may be great there. I
>>>won't challenge that domain.
>>
>>And ? Please focus on your argument about the reasons why polymorphism
>>is not usable in business apps.
>
>
> I did not say it was not usable. I am only saying I have yet to see
> frequent *good* uses for it. I am not saying that don't exist, I am
> only saying I have not seen any and thus remain skeptical. Again, the
> unicorn analogy.
Again, the planet/telescope analogy
>
>>>>>I understand it perfectly fine. I just have not
>>>>>seen EVIDENCE of it being better.
>>>>
>>>>"better" than what, and according to which metric ?
>>>
>>>
>>>I don't know.
>>
>>Well... You don't see "EVIDENCE of (OO) being better" than you don't
>>know what according to you don't know which metrics ?
>
>
> Huh? I didn't make the claim.
I repeat. You wrote "I just have not seen EVIDENCE of it being better."
('it' refering to OO). Do you agree that you wrote that ? Yes ? So I ask
you "better" than *what* and according to *which* metric ?
> If you claim X is better,
Than what ?
> you are
> obligated to show that X is better.
Where did I make any claim about "OO being better" than I still don't
know what accordig to I still don't know which metric ?
> You can use whatever metrics you
> want (subject to scrutiny of course). You claim unicorns exist, you
> show the evidence. Whether it is film, footprints, eyewitnesses, that
> is up to you.
Why do you keep on talking about unicorns ? Where did *I* claimed
"unicorns exist" ?
>
>>What can I add ?
>>
>>
>>
>>>I didn't claim it better so I don't know how to show it
>>>better.
>>
>>Common understanding of of value judgements is that A is either worse
>>than, as good as or better than B (or not comparable to...) according to
>>a given metric. Note that this requires an alternative and a metric...
>>Until you provide both, "better" (or "worse" etc) has no meaning.
>
>
> No. It could all be subjective.
It's a metric. "procedural better fits my mental model than functional",
for example, is, as far as I'm concerned, a perfectly valid metric - at
least for someone having seriously learned and work with both
approaches. Else, "for what I have seen of it, I don't think approach
XXX will fit my way of thinking as much as approach YYY that I know
well" is still a metric - but there's some "a priori" in it.
> It could be that some like paradigm A
> and some like paradigm B with there being no objectively measurable
> benefits between them.
productivity/quality ratio (for the same person, on a similar project)
could come to mind here - but it's hard to quantify, and we seldom have
time to do so in real life. Also, if the person is already proficient
with one approach and not with the other, there's an obvious bias...
> Now, please don't ask me to objectively prove that subjectivity exists
> :-)
Too bad, that's exactly what I was about to ask ! Shall we try with
unicorns, then ?-)
> One debater did that once. I laughed all day. Something like, "If you
> claim it subjective, then you are obligated to objectively prove your
> case."
I like this one. Worth a fortune too.
(snip)
>>>My stance is that paradigms are a probably subjective
>>>preference
>>
>>Then why do you spend so much time on this newsgroup (and on c2) trying
>>to demonstrate that OO is ill-suited for business apps ?
>
>
> Somebody else suggested that OO was superior,
Too what, and according to which metric ?-)
> implying all domains. I
> thus put the pressure on them to demonstrate it.
(My, I hope it's not me when I was younger - would be very embarassing...)
>
>
>>>>My point is definitively not to demonstrate that 'OO is better', just to
>>>>make clear that your arguments againts OO only demonstrate your lack of
>>>>understanding of OO. If you intend to demonstrate the superiority of
>>>>approach A over approach B for domain C, you need to master approach A,
>>>>approach B and domain C. This is not the case. Period.
>>>
>>>
>>>"Master" tends to mean "do and think my way" in web discussions.
>>
>>Strange enough, I tend to consider as "masters" peoples that not
>>necessarily "do and think my way", but are mostly able to improve the
>>way I do and think. This usually imply them having a pretty good working
>>knowledge on the topic.
>
>
> IMO, the best teachers use explicit examples coupled with explanation.
Sometime, a simple - even irrelevant at first look - example is enough
to get someone to a "aha" moment.
> English is not very useful by itself for software concepts because it
> is meant for a physical world, not a virtual one.
A language is an abstact thing - "purely virtual", and appropriate for
abstract thinking IMHO. Now some languages may be better taylored for
some class of abstractions in that they allow to express these
abstractions more tersly and/or rigorously. But you have to learn them
to use them anyway.
(snip)
>>>I've found that not everybody even agrees on what is invariant.
>>
>>In the standard C sort() function, the invariant (wrt/ the function
>>interface) is the sort algorithm. It should be obvious that what is
>>invariant and what is not greatly depends on the specific problem and
>>context (and that for some domains and/or contexts, it may not be easy
>>to know for sure the kind and probability of change for anything).
>
>
> Yes yes, but not for many of the other scenarios that I've dealt with.
Sorry, parser error on this input. "yes" to what, "not" for what ?
> Sorts are easy to deal with that way, but not very representative of
> real-stuff that I encounter.
> Sorting has been dissected every which way til Sunday. Still, its
> lessons are limited.
I'm not talking about sorting, I'm talking about a possible way to
"override part of a method" (which boils down to the same thing). Can't
you abstract yourself from "sorting", and sort out what in this solution
could be applied to similar problems (specializing only parts of a
behaviour) in your own domain ?
> Many things don't fit the same pattern.
Yes. OTOH, many patterns are found in different domains.
> I wish it
> did, then life would be simple.We could plug things in Lego-like
> without worrying about messy little exceptions and variations.
This almost work at different levels. I can compile Python on a
substantial choice of platforms. I can run some Python apps on any of
these platforms. I wrote apps that can work with at least SQLite and
PostgreSQL (and probably a few other SQL DBMS, but not tested), and at
least Apache or a fastCGI compliant HTTP server or a simple
(not-to-use-in-prod) embedded HTTP server. I have used the same
librairies from different languages. I have used some functions or
objects from these libs in different applications.
>
>
>>>You accused me of being ignorant about OO.
>>
>>I assert that you don't understand OO and hence don't know how to use it.
>
> Dissagreeing with your pet definitions is not the same as not
> understanding.
Asserting that OO polymorphic dispatch forces one into rigid
hierarchical taxonomies denotes a sure lack of understanding of the
topic IMHO.
>
>>Is that an "accusation" ? It's not a tribunal here AFAIK, and not
>>understanding OO is not criminal nor even delictuous.
>>
>>Is that an insult ? Well, the last time I told my wife she didn't
>>understood OO, she didn't seem to think it was an insult. In fact, she
>>laughed and confirmed. And as far as I'm concerned, the last times I've
>>been proven wrong or ignorant on some topics, I gracefully (well... more
>>or less gracefully) admitted the point.
>>
>>So, I'm sorry for you if you want to take my above assertion as an
>>insult, but then I also refuse to be held responsible for your emotive
>>over-reaction.
>
> It is rude because one has no way to easily defend themself whether
> wrong or correct.
Defend yourself from what ? From a statement about your understanding of
a given topic ? Prove me wrong, I'll take it back. I already did so in
the past. I don't feel personaly offended when proved wrong (I don't
like it more than anyone else, but that's another point).
> It is similar to, "Have you stopped beating your wife
> yet?" General, open-ended accusations
Actually, "Have you stopped beating your wife yet?" is what palo-alto
guys (the one dealing with - sorry, don't the translation, in French we
name this "sciences humaines") called a "double bind", and it's the
exact contrary of "open-ended". And if you spot something like a
double-mind in my previous post, please let me know where (not trying to
make a point, I'm deadly serious here - I wouldn't like to use such a
dishonnest technic).
> should be avoided if you desire
> to be diplomatic (many don't).
Diplomaty has never been my strong point, but that's another question.
>
>
>>>If
>>>99% of actual production code makes subtypes in order to use poly,
>
>
> (99% was meant as hypothetical. I didn't make that clear and
> apologize.)
Ok.
>
>>I think it's actually less, but that's another point. Now please note
>>that "makes subtypes" greatly depends on the definition of "subtyping".
>>According to Liskov, if in program P you can substitute object B to
>>object A without breaking P (read : P doesn't crash and continue to
>>produce correct outputs), than the type of B is a subtype of the type of
>>A. This implies that subtypes are in fact *determined* by polymorphism -
>>and in know way requires a rigid hierarchical type taxonomy.
>
>
> That is sustitutability of objects. If you have objects A, B and C that
> all respond to the same message/method "foo", then they are essentially
> *conceptually* "sub-types" from the perspective of "foo". Sub-typing
> does not require an explicit hierarchy. (Although, there are probably
> many variations on the term "subtype".)
Indeed.
>
>>>may not mean much
>>>as far as utility.
>>
>>FWIW, the fact that SQL DBMS fails to implement the relational model
>>doesn't say much about the utility of both the relational model and SQL
>>DBMS.
>
>
> I meant "can do X" versus "should do X".
I meant "bad application of an idea doesn't make the idea bad"
Davor
topmind wrote:
> > > Well, I couldn't give an exact boundary anymore than one can give an
> > > exact boundary for "country music". However, it tends to do with
Of course you can't - I did not ask for that either - I just wanted
that you say a bit more precisely what you are referring to...
> > > billing, inventory, reports (formal and ad-hoc), tracking, commisions,
> > > marketing, etc.
> >
> > OK, so what they typically call business/enterprise software... Good.
> >
> > > perfect) coded example because it needs typical CRUD (edit screens &
> > > reports) of biz apps, and everybody who has gone to college is familiar
> > > with the concepts. Thus, there is little need to explain the domain.
> >
> > OK, but this is not really "business software"... This is a general
> > description of a system consisting of
> >
> > UI
> > data storage
> > operations to create, read, update, and destroy data
> >
> > Even my basic text editor is such a system, but is not considered
> > "business software".
>
>
> This is why I use the term "custom business software". They don't come
> in a box.
I'm sure there are off-the-shelf solutions for each of above, but it's
not a problem - I guess I can see what you mean... You are referring to
heavy data management applications - the ones typically dealt with a
database solution :-). In particular the ones where heavy relational
exploration of data is needed - the ones best suited for relational
processing.
Most of such applications are built as a combination of
*procedural and relational processing*
So, I guess you would like someone to show you if a solution with
*OO and relational processing*
is better than above?
If yes, that boils down in my mind to showing if OO is better than
procedural... Right?
Also, for any meaningful comparison we should quantify what "better"
means, in order to proceed with any meaningful comparison....
> I am just saying that there is a void of OO examples for custom
> business software. The examples one finds in the OO training material
> do not reflect the custom biz apps that I deal with. They are obsessed
> with device-drivers and swappability, something I don't see a big need
> for.
The proportion of procedural code is relatively small as compared to
relational code in the applications you are talking about. Also, the
complexity of procedural code in such applications is not high, and all
complex processing is done in some relational query language... So in
such applications I would not even bother writing OO code... If it
happened that procedural part of such application is
larger/more-repetitive/with-a-lot-of-smaller-variations-depending-on-case/etc.,
I would probably include some of the OO structuring mechanisms, used a
bit of polymorphism, and a bit of extension to make the procedural part
a bit better organized... So, I don't see a big deal with all this...
>
> For example, OO'ers keep harping on, "what if you want to replace your
> database with flat files or a different RDBMS vendor?" That is not a
that is not an OO decision - doing things like that involves a lot of
architectural decisions...
> common need. I am not going to waste code on trying to make generic
> wrappers (if even possible) unless there is an up-front known need for
> such. Future discounting (similar to ROI curves) finance concepts are
> also against it.
requirements/architecture/project management issues - not OO or
relational or structured etc. issues...
Again, I don't see what a big deal is... For applications that
requirements tell me that I'll need a significant amount of relational
processing, of course I'm gonna make an architectural decision to use
relational database (unless having requirements that constrain me from
making such a decision), and if the procedural part of such an
application is relatively simple and small (which typically is), I
couldn't care less if I do it in using structured programming or OOP
(would chose based on a number of project management issues such as
developer's familiarity, what we already have in terms of
infrastructure, etc.)
Of course, if I misunderstood, and you were discussing all this based
on the fact that someone told you that you should substitute what you
would typically handle using relational processing with typical OOP
that's completely another story... But in that case, it is still not
the issue of OOP, but rather the question of substituting relational
processing with procedural processing, since in most cases when you say
OOP, it's still procedural processing at the core with a number of
features for structuring and reusing that procedural code, but at the
bottom of the line it comes to the comparison of relational to
procedural processing for a task where relational have significant
advantages.
Davor
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>
>>topmind a écrit :
>>(snip)
>> > IF statements are simply more bendable and flexible to handle real-world
>>
>>>changes. You can refine them without moving lots of code around.
>>
>>But not without modifying existing code. And in a lot of cases modifying
>>it in *many* places. What polymorphism brings is mainly using another
>>way of doing the dispatch that doesn't require explicit branching - so
>>it doesn't require modification of the calling code. This is of course
>>not enough to isolate all code of all possible change, but it's still a
>>pretty useful tool -- and a very often used, one way or another.
>
>
> When I see it in my domain, I will beleive you.
I just don't give a damn whether you "believe" it or not. You have the
right not to believe the earth turn around the sun too.
> It does not work in the
> real world like it does in shape, animal, and device-driver book
> examples.
Which "real world" ?
> The real world (at least in my domain) does not change that
> way.
Which way ?
> The books set up an artificial strawman, and then knock it down
> with polymorphism.
wrt/ shapes, it's certainly not an "artificial strawman".
(snip)
>>>If *all* coupling is bad,
>>
>>Where did you get the baroque idea that "all" coupling would be bad ?
>
> It is a hypothetical question testing an idea, not a claim.
Ok, so to resume your point, "if all coupling is bad, then all coupling
is bad" ? You can replace "coupling" and "bad" with whatever other word,
it's just as useful.
>
>>What we want is to avoid coupling between parts that have (or may have)
>>to change independantly (and I agree that deciding what should be
>>decoupled from what is not always easy). Now the problem addressed by
>>polymorphism is how to decouple usage from implementation (not to
>>decouple from usage from usage, which would be totally meaningless) . In
>>other terms, it's a matter of "what, not how" - something that DBMS try
>>to solve in the domain of data management BTW.
>
>
> I am perfectly aware and highly conscience of change and change
> patterns to code. Generally there is no free lunch, it is all a
> compromise between competiting factors.
indeed.
> But *overall* I find Sets one
> of the best tools for managing changes.
A valid definition of a type is "a set of values + a set of operations
on these values". If so, if types are sets and sets are a good tool for
managing change, then types are a good tool for managing change.
> For one, they don't have the
> mutual-exclusiveness problems that poly tends to.
I don't see how polymorphism implies more "mutual exclusiveness" than
ifs or switches (ok, depending on which kind of polymorphism, and how it
is implemented and used).
> This is based on
> *experience*. I did not walk out of school beleiving that sets were
> nice.
Fine. And ? FWIW, I barely went to school at all. And I learned to use a
computer (let alone programming) years after having quit school.
> If you really care about change management, then persue Sets.
I don't exclude them from my toolbox.
> I
> find them far more promising than polymorphism. (RDBMS are currently
> the best available Set tools.)
It seems to be commonly agreed on cdt that SQL DBMS are not really
"relational" DBMS (in that they don't fully implement the relationel
model), and that there's in fact actually no available "RDBMS" - at most
SQL DBMS.
BTW, there's much more to the relational model than just "sets"...
> If there is a Silver bullet,
There's none.
Robert Martin
> I think we've debated swapping wiki "storage mechanisms" before. I'm
> tired of hearing about swapping implementation.
And I'm tired of hearing about how OO doesn't work for an ever
narrowing set of applications that you happen to write.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Robert Martin
> It is not something
> that happens often in *custom* biz software because bosses are cheap
> and don't want to pay somebody to write the same process twice.
Business applications change and grow like any other application. As
they do there are modules that wind up being duplicated and then
modified because new function A' is a lot like old function A except
for ... OO can really help eliminate the duplication in situations
like this.
Alvin Ryder
> I disagree.
Fair enough, actually I can well agree with you.
But it's ironic that you raise this point with me because it was one of
your books that helped return me to simplicity and sanity ;-) "XP in
Practice" by Newkirk/Martin is a great little (orange) book, one of my
favorites. For readers unaware of it, it teaches XP by walking through
a practical example in a refreshingly honest and day to day way. It
also provides a J2EE web case study using Sun's Model 2 architecture.
This example doesn't use a lot of heavy duty "OOP", striving for "the
simplest possible thing that works", it ends up with very "object
based" (classes without inheritence) versus object oriented
(inheritence/poly) code.
Web applications can be broken down into smaller pieces "a page or so",
each of these contains:-
Presentation) HTML, JSP, JSTL.
No OOP *at the app dev level* - (internally yes).
Controller) Can just be simple Servlets!
People get carried away here with all sorts of OOP frameworks, command
patterns and way too many other things. After about 40 web apps I was
one of those swept away in such folly but thanks to your book and a few
others I saw the power of simplicity.
That's why I was motivated to say "web apps aren't a good example of
OOP", I should have said "fat frameworks for controllers on the
application side aren't required, they aren't the simplest possible
thing that works and /they/ are not a good example of OOP".
But yes, strictly speaking Servlets themselves are a great example of
OOP in action!
Server vendors provide a truck load of functionality and program to
interfaces, app developers provide concrete instances and polymophism
is used to connect the two parties. Developers are shielded from
internal server knowledge yet gain its power which is just one method
call away!
Model) Often use databases.
Again JDBC is a great example of OOP. We program to just *one*
interface and it drives hundreds of different types of databases.
People say, "when will one brand of db be changed for a flat file",
well maybe not for a flat file but very often we must program in db
vendor neutral ways. A shrink wrapped app may work with Oracle at one
site and SQL Server at another. And there are JDBC drivers that drive
text files as well!
Furthermore flat files are often swaped for LDAP or XML, FTP delivery
might be swapped for MQ, screen scrapers might be swapped for EJBs - so
this notion of decoupling is not without merit! But I digress.
Back to the topic, again at the app level, we can keep our CRUD code
very flat, the example in the "XP in Practice" book uses static methods
(hence not-OOP) to sit between the app and JDBC code.
This, BTW, is why I said CRUD heavy apps don't need "OOP", they can get
away with a very "object based" (classes without poly) or a "static
method" (glorified global function) approach.
In PERL we just had CGI.pm, you could use it in a very non-OO way. Just
a simple controller, that read user input, touched the model and
resulted in a page of some sort. No or very little OOP at all.
I must also say Sun have ended up with an extremely heavy OOP approach
with their J2EE and web solutions, I can imagine far lighter and easier
ways. This also motivated my comment, I should've said "Sun's web
approach isn't the best showcase for OOP".
So I can quite happily retract or rewrite my statement but hopefully
I've made my rather complex point?
Cheers
PS. Thanks for the great little book ;-)
Alvin Ryder
We sell shrink wrapped packages that might use Oracle at one site, SQL
Server at another and Hypersonic (essentially entire db in one ascii
file) at another site. Sorry I cannot give you the code.
With JDBC you program to *one* interface yet drive potentially hundreds
of different types of databases. This is a great example of OOP.
I acknowledge, at any given site they might not change db vendors on a
regular basis (well never;-) but can you see the value in my example?
How would you achieve such vendor neutrality without OOP?
Web Servers)
Java based web servers connect to application code via interfaces and
polymorphism. Again you can have different vendors with different
features and prices. You may not swap vendors at a given site but
across sites you might have:- Weblogic, Websphere, Tomcat, ...
Again this is a good example of OOP. But nevermind vendor swapping, for
me *the best part is I don't need to know the inner workings of any web
server*.
All I have to do is learn *one* interface and just the tip of the
iceberg! I do not have to know all the inner workings of all the
different web server vendors!
In the old C days you just had to pretty much know everything about
everything! Yes C code *could* have been well encapsulated and
sometimes it was but usually you had to know a lot more than desired.
This is no small point.
Can you see how interfaces shield you from such extraneous knowledge?
And how they are the tip of the iceberg?
When you learn to drive a car, you learn one interface, steering wheel,
brakes, etc then you can drive any vendor's car and you never need to
know the inner engine workings. Am I getting through?
Furthermore to gain all this power you just have to call a method!
There are other ways to achieve swapability but it involves swapping
libraries/drivers, this can get very ugly. You know "Insert CD" but
oops I don't have it. OOP provides decoupling but it isn't too far
away, the code will be there, it's at the optimal distance.
Editors)
In my previous post I talked about "shape" oriented editors like
"Paint", "Visio", "3D Studio Max", etc etc Are you familiar with how
these work?
You appear to understand the value of "driver" and "shape" examples but
can you see how far reaching they are? ;-) There are literally
thousands of GUI apps in this category!
GUI apps)
In general rich GUI's are composed of increasingly complex components,
inheritence is very useful here.
Again how many GUI apps are there on your PC? Ever tried to implement a
rich UI without OOP?
Conclusion)
Ok, let's ask how would the above power and flexibility be achieved
without OOP? You'd have to carry around the type information and
constantly react to each type. IOW do your own polymorphism. Possible
but ugly.
Vendor neutrality? I think you'd need a miracle or interfaces which
enforce the standard in code!
I acknowledge site bound applications don't care for vendor neutrality
but plenty of other apps do.
I also like package/class mechanisms as a way to bundle my code, a neat
place to put things.
Better still you can intermix parties and decouple them! Don't
undervalue this point (as RCM reminds us ;-)
One party can go their hardest and program to interfaces and
independantly on the other side of the fence another party could go
their hardest and program to the same interface but this time they
provide the other side of the equation (a pathetic description I know)
but do you see what I mean? The parties could be vendor/customer,
different people on a team or within the same business but in different
locations.
Person A does the outer part, person B the inner part. Party A does the
producer part, B is the consumer, there are examples without number. I
won't elaborate further but the db and web server's are examples of
parties across business lines.
Without OOP - how would you provide narrow interfaces to other
developers - thus less for them to learn and less opportunity to break
your code!
Yes you can do all of the above without OOP and I've seen well written
systems in C, for example UNIX and the QUAKE3 game engine but in the
hands of a good programmer OOP provides some nifty options.
Topmind I agree all that glitters is not gold, all the hype in OOP does
not equal a silver bullet and all $nake oil doesn't help me do my job
better but can you see any value in what I've said? OOP *can* be very
useful to *some* people.
HTH,
Cheers.
topmind
> On 2006-07-06 11:39:35 -0500, "topmind" <top...@technologist.com> said:
>
> > It is not something
> > that happens often in *custom* biz software because bosses are cheap
> > and don't want to pay somebody to write the same process twice.
>
> Business applications change and grow like any other application. As
> they do there are modules that wind up being duplicated and then
> modified because new function A' is a lot like old function A except
> for ... OO can really help eliminate the duplication in situations
> like this.
I've studied the patterns of changes and variation re-occurance that I
see over the years. I have concluded that the generation/creation
patterns of variations tend to be a *Cartesian Join* of all possible
features. There may be *some* rough treeness, but not enough to rely on
in the longer run.
Thus, say there are 26 total features, and we label them from A to Z.
The variations would then tend to be random subsets of the features:
instance 1: A,C,R,Q,V,Y
instance 2: D,J,L
instance 3: C,G,R,T,V,Z
instance 4: E,F,K,L,M,P,R
etc.....
So, please tell me how OO deals with such.
The procedural/relational approach is generally to put the feature
lists in tables, and then a task will tend to look something like:
Task Foo(...) {
if A {....}
if B {
if K {...
} else {
...
}
}
...
if Y {....}
if Z and not M {....}
}
It ain't pretty, but I have not found something better. Further, the IF
structure tends not to be the same from task to task. Polymorphic
solutions tend to assume the same IF "framework" for each different
task, which is the incorrect assumption most of the time.
>
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
> On 2006-07-06 11:39:35 -0500, "topmind" <top...@technologist.com> said:
>
> > I think we've debated swapping wiki "storage mechanisms" before. I'm
> > tired of hearing about swapping implementation.
>
> And I'm tired of hearing about how OO doesn't work for an ever
> narrowing set of applications that you happen to write.
Again, I deny any significant change of my "no biz" complaint over the
past few years.
As far as swapping flat files implementatioin to DB implementation, I
usually start out with a DB, and only had to swap down to flat files
*once* in my entire career (that I remember). If you do it the other
way: flat files first, then you are more likely to have to overhaul the
implementation of "persistence" (I hate that word because DBs are far
more than just that). Where do you disagree with this observation? I
am not seeing what is upsetting you. If I worded it rough, I apologize.
But this is an honest observation about change frequency.
I don't have to overhaul implimentation that often. And if I see a need
for it, I use more functions so that I can replace the function
content, yet the function calls are the same.
I focus on solving problems that I see, and swapping implementation is
not a common one for custom biz apps; and if it was, I can wrap with
functions. Poly only makes a diff over function wrappers when there are
multiple simultanious instances using the different implementations (of
the same interface), which is even rarer[1]. I *can* see a need for
such simultaniousness in say operating systems, but not for my niche.
I call them as I see them. Honest.
[1] There are ways to do it with functions also. But that is another
holy war for another day.
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
topmind
Not necessarily. It depends on the coder. SQL is often not as
expressive as I would like, so I shift that to procedural for some
parts. (SQL's faults are generally language-specific, not the fault of
relational in general. SQL is kind of long in the tooth.)
> Also, the
> complexity of procedural code in such applications is not high, and all
> complex processing is done in some relational query language...
I don't think I would agree with that. If it wasn't complex, there
would be very little code (if factored properly). The complexity is
often implementing seemingly arbitrary business rules created by
marketers, managers, and law makers. One has to translate goofy
requests into code.
> So in
> such applications I would not even bother writing OO code... If it
> happened that procedural part of such application is
> larger/more-repetitive/with-a-lot-of-smaller-variations-depending-on-case/etc.,
> I would probably include some of the OO structuring mechanisms, used a
> bit of polymorphism, and a bit of extension to make the procedural part
> a bit better organized... So, I don't see a big deal with all this...
Lots of repeating case statements is generally a sign that a new table
is required.
> >
> > For example, OO'ers keep harping on, "what if you want to replace your
> > database with flat files or a different RDBMS vendor?" That is not a
>
> that is not an OO decision - doing things like that involves a lot of
> architectural decisions...
>
> > common need. I am not going to waste code on trying to make generic
> > wrappers (if even possible) unless there is an up-front known need for
> > such. Future discounting (similar to ROI curves) finance concepts are
> > also against it.
>
> requirements/architecture/project management issues - not OO or
> relational or structured etc. issues...
>
> Again, I don't see what a big deal is... For applications that
> requirements tell me that I'll need a significant amount of relational
> processing, of course I'm gonna make an architectural decision to use
> relational database (unless having requirements that constrain me from
> making such a decision), and if the procedural part of such an
> application is relatively simple and small (which typically is), I
> couldn't care less if I do it in using structured programming or OOP
> (would chose based on a number of project management issues such as
> developer's familiarity, what we already have in terms of
> infrastructure, etc.)
Again, I would not necessarily characterize the procedural part as
"small". However, you are correct in a way because the database is (or
should be) the key. The database is like The Nile and the procedural
code is like villages along the shore.
>
> Of course, if I misunderstood, and you were discussing all this based
> on the fact that someone told you that you should substitute what you
> would typically handle using relational processing with typical OOP
> that's completely another story... But in that case, it is still not
> the issue of OOP, but rather the question of substituting relational
> processing with procedural processing, since in most cases when you say
> OOP, it's still procedural processing at the core with a number of
> features for structuring and reusing that procedural code, but at the
> bottom of the line it comes to the comparison of relational to
> procedural processing for a task where relational have significant
> advantages.
A given set of OOP code would generally produce some relational code
and some procedural code if de-OO'ed. The biggest difference is that
anything resembling a noun taxonomy or noun classification system is
usually moved to the database and what is left to procedural is
behavioral decomposition. OOP tends to mix noun classification and
behavioral issues together in the same code, often artificially forcing
the marriage IMO.
>
> Davor
-T-
fre...@gmail.com
> they do there are modules that wind up being duplicated and then
> modified because new function A' is a lot like old function A except
> for ... OO can really help eliminate the duplication in situations
> like this.
This kind of statements are very common, but very rarely motivated.
Every motivation on claims that OO should help eliminate duplication
seem to rely on inheritence. Creating hierachial taxonomies is a good
choice in some situations but a very bad choice in other situations.
For a more detailed discussion, see
http://c2.com/cgi/wiki?EmployeeTypes. OO is only good at eliminate
duplication in situations there hierachial taxonomies can be used.
Also in situations there hierachial taxonomies can be used, OO
languages is not significat better than other languages that support
polymorphism. The key feature is polymorphism, not OO.
Fredrik Bertilsson
http://frebe.php0h.com
topmind
Bruno Desthuilliers wrote:
> topmind a écrit :
> > Bruno Desthuilliers wrote:
> >
> >>topmind wrote:
> >>
> (snip)
> >>- definition of "object":
> >>"""
> >>'object' being defined as 'id + state + behaviour +
> >>interface'
> >>"""
> >
> >
> > So do RDBMS.
>
> If you considere constraints + triggers + stored procs as behaviour and
> "select, insert, update, delete" as messages (which implies a very
> uniform interface...), well, why not ? But this would probably make a
> somewhat restricted object model IMHO.
It is "restrictive" because when using a database you tend to divide
stuff up into what the DB does best and what applications do best. One
could do entire apps on the DB, but that is not the goal. It is
dividing up the workload to specialists in each area.
> (snip)
> >>Do you have any change to make to the standard C sort function to use it
> >>for any type and any ordering function ?
> >
> >
> > I don't write sort algorithms for a living.
>
> That's totally irrelevant here.
>
> And the
>
> > Whether OO helps with that
>
> It's not OO, it's the standard lib. And it's about polymorphism.
But OO being good at making flexible sorts does not necessarily
extrapolate it to making good payroll systems. (I usually let the DB do
the sorting, by the way.)
>
> > I not is irrelavent to me. It is essentially another Systems Software
> > example.
>
> Either your memory is bad or you fail to make the connection with your
> initial question about "How do you override HALF of a method? (without
> duplicating some behavior)". FWIW, you can s/method/function/, the
> answer is obviously : "by separating the parts". In the C sort example -
> like in almost every non-trivial C program, be it a business app - it's
> done with void pointers and function pointers so you can parameterize
> one algorithm with different types. This is also done quite a lot in
> functional programming. This can be done in OO too - and is effectively,
> eventually using a "function-like" object if the language doesn't
> support first class functions, or code blocks like in Smalltalk. OO
> brings another idiom of it's own with "template methods" - perhaps the
> most known and used OO designed pattern (FWIW, I used it years before I
> first heard mention of design patterns).
I don't see how this answers the "half" issue. I'll see if I can
formulate an example of halfing.
>
> > I have already "surrendured" systems software to OO years ago.
>
> Is standard C sort OO ?-)
>
> > I just want something that helps *my* domain.
>
> Why do you think the same technical problem would require a different
> technical solution according to the domain ?
Are you asking why OO techniques that apply for one domain don't apply
for another? That is a very good question. I don't know why, it just
does. The patterns of changes in systems software (at least in the
examples) is just plain different. I've been trying to figure out why,
but I cannot really state it yet.
The best I can come up with is that with systems software you are
modeling concepts created by engineers, but in biz you are modeling
concepts created by marketers, law makers, and capricious managers.
Engineers try to make things logical, but the biz crowd doesn't give a
fudge about logical. Thus, in biz one needs more flexible variation
management tools than what poly has to offer. Enter Sets.
>
> > OO'ers are
> > over-extrapolating.
>
> If by this you mean "when faced to the same known problem, try to solve
> it with the same known solution", yes, possibly. But that would be a
> rather strange definition.
Please clarify.
> > Smalltalkers, for example, generally view polymorphism as different
> > objects being able to answer the same message (same named method).
> > Example:
> >
> > A.foo(); // not smalltalk, just an example
> > B.foo();
> >
> > Here object A and object B both answer the message "foo". There may be
> > no connection between A and B whatsoever. And, there is no "type
> > checking".
>
> You can do the same in OCaml, which is a stronly, statically typed
> language. And without any *declared* relationship between type A and type B.
>
> > It has nothing to do with "types".
>
> Depends on how you define "type".
>
> If of course you define a type as "a label I explicitly put in front of
> some definition of a set of values and a set of operations on this set
> of values", no, it has nothing to do with types. But then it would prove
> that you don't need rigid hierachical type taxonomy for OO polymorphic
> dispatch to work.
Again, I did not claim that one did. I simply said that *in practice*
poly is used for sub-types that most would consider a hierarchy of
sorts, or at least "is a", some explicit some implicit.
If you have a biz example that doesn't polymorph off of anything
resembling sub-types, by all means present it.
> >>>I mean a real case of polymorphism that one encounters in the *field*.
> >>>Of course a "lab example" can be made non-hierarchical. I don't dispute
> >>>that.
> >>
> >>I do use the features described above on a daily basis. My job is to
> >>write web applications, which includes business apps. This is not "lab
> >>example".
> >
> > That's great. That means you can provide some specific actual scenarios
> > so that I don't have to take your word for it anymore....
>
> Come and work with us, you'll see by yourself. We're in France, in
> Bordeaux. Want to apply for a position ?
How about you simply describe some of your classes that you polymorph
with. Describe what the class is and give descriptions of enough
methods and/or attributes to give a feel for what it is doing.
>
> > And I agree there are a few places where OOP could help in my biz apps.
> > But it is such a small percentage that it does not make sense to mix
> > paradigms.
>
> I happily mix them all. "Use the right tool for the right job", as they
> say...
But nobody agrees on when to use what. There are no clear guidelines.
>
> >
> >>>>>of all the poly I see does. This is probably why you had to use a
> >>>>>foobar example instead of something like employees or bonds, etc.
> >>>>
> >>>>Please demonstrate why the above could not be applied to any domain.
> >>>
> >>>First of, "can" and "should" are two different things.
> >>
> >>What you wrote about "foobar example" (and now with "lab example") imply
> >>that the features I showed can not be used in real life. So I challenge
> >>you to back your claim. Please, no diversion.
> >
> > I did not say that.
>
> Really ?
>
> > If they *are* practical in real life, then simply
> > show realistic examples of it being so.
> >I didn't claim that unicorns
> > didn't exist, I only claim that I've never seen any.
>
> I don't claim that Pluton (or is that Pluto ? You know, the planet...)
> doesn't exists, I only claim I've never seen it. I could of course buy a
> telescope and learn about astronomy...
By seeing Planet "Good Code" with my own eyes thru the scope....
> > If that is not the case, then perhaps we don't have a
> > disagreement afterall.
>
> We have a disagreement on your assertions that polymorphism couples
It couples you to a mutually-exclusive assumption about the "kinds". If
there are not multiple kinds, then there is no "poly". It would be
Monomorphism. In biz apps, the variation management usually needs to be
at the instance level, not the "kind" level.
> and it's not practically useful in "business applications".
Until shown with actual code.
> >>>>>I understand it perfectly fine. I just have not
> >>>>>seen EVIDENCE of it being better.
> >>>>
> >>>>"better" than what, and according to which metric ?
> >>>
> >>>
> >>>I don't know.
> >>
> >>Well... You don't see "EVIDENCE of (OO) being better" than you don't
> >>know what according to you don't know which metrics ?
> >
> >
> > Huh? I didn't make the claim.
>
> I repeat. You wrote "I just have not seen EVIDENCE of it being better."
> ('it' refering to OO). Do you agree that you wrote that ? Yes ? So I ask
> you "better" than *what* and according to *which* metric ?
Again, it is not my job to supply evidence to the person who claims
unicorns exist. If you claim unicorns exist, the kind of evidence that
is provided is *your* obligation. I don't know *how* they are
measuring "better". They are not specific. They may say it "makes code
easier to change" sometimes, but never show the before and after code,
and expect me to take their word for it ("trust me").
> > You can use whatever metrics you
> > want (subject to scrutiny of course). You claim unicorns exist, you
> > show the evidence. Whether it is film, footprints, eyewitnesses, that
> > is up to you.
>
> Why do you keep on talking about unicorns ? Where did *I* claimed
> "unicorns exist" ?
It is an analogy. Replace "unicorns" with "OOP being better" if that
clarifies things.
>
> >
> >>What can I add ?
> >>
> >>
> >>
> >>>I didn't claim it better so I don't know how to show it
> >>>better.
> >>
> >>Common understanding of of value judgements is that A is either worse
> >>than, as good as or better than B (or not comparable to...) according to
> >>a given metric. Note that this requires an alternative and a metric...
> >>Until you provide both, "better" (or "worse" etc) has no meaning.
> >
> >
> > No. It could all be subjective.
>
> It's a metric. "procedural better fits my mental model than functional",
> for example, is, as far as I'm concerned, a perfectly valid metric - at
> least for someone having seriously learned and work with both
> approaches.
I disagree. It is not externally inspectable. Some also feel that one
should change the way they think to fit what is in style instead of the
other way around. If that is the case, then one can accuse the other of
"thinking wrong".
> Else, "for what I have seen of it, I don't think approach
> XXX will fit my way of thinking as much as approach YYY that I know
> well" is still a metric - but there's some "a priori" in it.
>
>
> > English is not very useful by itself for software concepts because it
> > is meant for a physical world, not a virtual one.
>
> A language is an abstact thing - "purely virtual", and appropriate for
> abstract thinking IMHO.
Too abstract. Stuff cannot be compared and dissected in a
semi-scientific way because it often does not have a common bind
between people. You may be interested in this:
http://www.geocities.com/tablizer/science.htm
> > Sorts are easy to deal with that way, but not very representative of
> > real-stuff that I encounter.
> > Sorting has been dissected every which way til Sunday. Still, its
> > lessons are limited.
>
> I'm not talking about sorting, I'm talking about a possible way to
> "override part of a method" (which boils down to the same thing). Can't
> you abstract yourself from "sorting", and sort out what in this solution
> could be applied to similar problems (specializing only parts of a
> behaviour) in your own domain ?
Yes, but the same change is easier as procedural.
>
> > Many things don't fit the same pattern.
>
> Yes. OTOH, many patterns are found in different domains.
>
> > I wish it
> > did, then life would be simple.We could plug things in Lego-like
> > without worrying about messy little exceptions and variations.
>
> This almost work at different levels. I can compile Python on a
> substantial choice of platforms. I can run some Python apps on any of
> these platforms. I wrote apps that can work with at least SQLite and
> PostgreSQL (and probably a few other SQL DBMS, but not tested),
Are you saying you move back and forth between RDBMS vendors for the
same application often?
> and at
> least Apache or a fastCGI compliant HTTP server or a simple
> (not-to-use-in-prod) embedded HTTP server. I have used the same
> librairies from different languages.
Please clarify.
> I have used some functions or
> objects from these libs in different applications.
>
> >
> >
> >>>You accused me of being ignorant about OO.
> >>
> >>I assert that you don't understand OO and hence don't know how to use it.
> >
> > Dissagreeing with your pet definitions is not the same as not
> > understanding.
>
> Asserting that OO polymorphic dispatch forces one into rigid
> hierarchical taxonomies denotes a sure lack of understanding of the
> topic IMHO.
"Force" is not really the correct word. But anyway, this probably won't
be settled without concrete examples.
>
> >
> >>Is that an "accusation" ? It's not a tribunal here AFAIK, and not
> >>understanding OO is not criminal nor even delictuous.
> >>
> >>Is that an insult ? Well, the last time I told my wife she didn't
> >>understood OO, she didn't seem to think it was an insult. In fact, she
> >>laughed and confirmed. And as far as I'm concerned, the last times I've
> >>been proven wrong or ignorant on some topics, I gracefully (well... more
> >>or less gracefully) admitted the point.
> >>
> >>So, I'm sorry for you if you want to take my above assertion as an
> >>insult, but then I also refuse to be held responsible for your emotive
> >>over-reaction.
> >
> > It is rude because one has no way to easily defend themself whether
> > wrong or correct.
>
> Defend yourself from what ? From a statement about your understanding of
> a given topic ? Prove me wrong, I'll take it back.
What is your OO knowledge test?
-T-
topmind
> topmind wrote:
> > Robert Martin wrote:
> > > On 2006-07-07 07:32:30 -0500, "Alvin Ryder" <alvi...@telstra.com> said:
> > >
> > > > I don't think OOP is good for every type of application, in particular
> > > > Web and CRUD heavy business apps aren't the best showcase for it but
> > > > rich GUI apps are.
> > >
> > > I disagree. Web and CRUD applications can make very nice use of OO
> > > because WEB and CRUD application have modules that depend upon each
> > > other. Those dependencies need to be managed.
> >
> > I would welcome some coded examples, something like the Campus example,
> > that show it being better than procedural/relational, perhaps with some
> > realistic change scenarios, not the bogus ones the OO books like to
> > use. (The only real "reuse" in the OO books is cloning the stupid
> > change scenarios.)
> >
> > >
> > > --
> > > Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
> >
> > -T-
>
> We sell shrink wrapped packages that might use Oracle at one site, SQL
> Server at another and Hypersonic (essentially entire db in one ascii
> file) at another site. Sorry I cannot give you the code.
>
> With JDBC you program to *one* interface yet drive potentially hundreds
> of different types of databases. This is a great example of OOP.
JDBC is based on ODBC, which is safe to classify as "systems software".
A custom applicatons developer does *not* write ODBC drivers for the
most part. The ODBC driver is simply a name passed to the query system
from the app developer's perspective. He uses it, not programs ODBC
drivers.
Not my niche, so it does not really matter. I want techniques that help
me here and now, not in my reincarnated game-maker life.
>
> You appear to understand the value of "driver" and "shape" examples but
> can you see how far reaching they are? ;-) There are literally
> thousands of GUI apps in this category!
>
>
> GUI apps)
> In general rich GUI's are composed of increasingly complex components,
> inheritence is very useful here.
I personally think that GUI's should be mostly declarative. For one,
this would allow multiple languages to use the same GUI engine rather
than write a different GUI engine for each language. Declarative,
procedural, and relational are more sharable across languages in
general. OO engines are tough to share across languages because some
langs only offer single inheritence, some have dynamic objects and
others static, etc. If you write to the lowest common denominator, you
almost have a declarative interface anyhow.
>
> Again how many GUI apps are there on your PC? Ever tried to implement a
> rich UI without OOP?
No, but that is not what I do for a living. The issue is whether OO is
good for all domains or a specific set. I won't dispute that OO may
have decent uses for some domains, just not for custom biz software.
Before somebody goes around telling everyone that OOP is a magic tool
for every piece of software, they should add the proper disclaimers
about the range of the claims.
>
> Topmind I agree all that glitters is not gold, all the hype in OOP does
> not equal a silver bullet and all $nake oil doesn't help me do my job
> better but can you see any value in what I've said? OOP *can* be very
> useful to *some* people.
Or some niches/domains.
>
> HTH,
> Cheers.
-T-
topmind
Bruno Desthuilliers wrote:
> topmind a écrit :
> > Bruno Desthuilliers wrote:
> >
> >>topmind a écrit :
> >>(snip)
> >> > IF statements are simply more bendable and flexible to handle real-world
> >>
> >>>changes. You can refine them without moving lots of code around.
> >>
> >>But not without modifying existing code. And in a lot of cases modifying
> >>it in *many* places. What polymorphism brings is mainly using another
> >>way of doing the dispatch that doesn't require explicit branching - so
> >>it doesn't require modification of the calling code. This is of course
> >>not enough to isolate all code of all possible change, but it's still a
> >>pretty useful tool -- and a very often used, one way or another.
> >
> >
> > When I see it in my domain, I will beleive you.
>
> I just don't give a damn whether you "believe" it or not. You have the
> right not to believe the earth turn around the sun too.
But code could in theory be presented that shows OOP being better for
custom biz apps if OO is better there. I just have not seen it.
>
> > It does not work in the
> > real world like it does in shape, animal, and device-driver book
> > examples.
>
> Which "real world" ?
As I observe it.
>
> > The real world (at least in my domain) does not change that
> > way.
>
> Which way ?
A way that polymorphism simplifies. For a simple example, in typical
OOP textbook shape examples, they often talk about how poly makes it
easier to add another shape. But, the case statement approach could
make it easier to add another operation to all shapes, such as
"rotate". I don't have to necessarily touch other routines, just make
a new Rotate() routine. I am not recommending it, only giving an
example of a chage that poly makes harder than case statements.
If you agree with this, then you must agree that polymorphism does not
make *all* changes easier. It comes down to probability: which changes
are more common.
>
> > The books set up an artificial strawman, and then knock it down
> > with polymorphism.
>
> wrt/ shapes, it's certainly not an "artificial strawman".
The implication is that one should sub-type *everything*. This is the
strawman.
> >>What we want is to avoid coupling between parts that have (or may have)
> >>to change independantly (and I agree that deciding what should be
> >>decoupled from what is not always easy). Now the problem addressed by
> >>polymorphism is how to decouple usage from implementation (not to
> >>decouple from usage from usage, which would be totally meaningless) . In
> >>other terms, it's a matter of "what, not how" - something that DBMS try
> >>to solve in the domain of data management BTW.
> >
> >
> > I am perfectly aware and highly conscience of change and change
> > patterns to code. Generally there is no free lunch, it is all a
> > compromise between competiting factors.
>
> indeed.
>
> > But *overall* I find Sets one
> > of the best tools for managing changes.
>
> A valid definition of a type is "a set of values + a set of operations
> on these values". If so, if types are sets and sets are a good tool for
> managing change, then types are a good tool for managing change.
Types tend to be a directed acyclic graph (did I say that right?),
while sets can represent *any* graph. Adding cycles to types is not
something people have a lot of experience with, and may be inharently
messy.
>
> > For one, they don't have the
> > mutual-exclusiveness problems that poly tends to.
>
> I don't see how polymorphism implies more "mutual exclusiveness" than
> ifs or switches (ok, depending on which kind of polymorphism, and how it
> is implemented and used).
Before:
switch on X {
case 1 then {zark()}
case 2 then {grog()}
}
After:
if x=1 then {zark()}
if x=2 then {grog()}
I removed mutual-exlusiveness without moving implementation code
around. I just changed the case block to IF blocks. Now stuff can be
both. For example, a bank may start out with Checking accounts *or*
Savings accounts. I once heard on the radio that a bank was offering an
account that was *both*. The fees were based on how many checks you
wrote IIRC, not an up-front classification. If you wrote few or no
checks, then you had the same fees as a Savings account. The poly OO'er
would have more code rework to undo mutual exclusiveness.
> > I
> > find them far more promising than polymorphism. (RDBMS are currently
> > the best available Set tools.)
>
> It seems to be commonly agreed on cdt that SQL DBMS are not really
> "relational" DBMS (in that they don't fully implement the relationel
> model), and that there's in fact actually no available "RDBMS" - at most
> SQL DBMS.
I would indeed change a lot of things about the implementation of RDBMS
and their query languages. But even *with* their warts, they beat most
OO designs.
>
> BTW, there's much more to the relational model than just "sets"...
True, but this topic is about polymorphism and variation management,
and that is where sets shine.
>
> > If there is a Silver bullet,
>
> There's none.
Sets are a brass bullet. Poly is a wooden one.
-T-
Frans Bouma
Why don't you come up with an example where you show that OO is so
incredibly bad. ?
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
AndrewMcDonagh
> Bruno Desthuilliers wrote:
>> topmind a écrit :
>>> Bruno Desthuilliers wrote:
>>>
>>>> topmind a écrit :
>>>> (snip)
>>>>> IF statements are simply more bendable and flexible to handle real-world
>>>>> changes. You can refine them without moving lots of code around.
>>>> But not without modifying existing code. And in a lot of cases modifying
>>>> it in *many* places. What polymorphism brings is mainly using another
>>>> way of doing the dispatch that doesn't require explicit branching - so
>>>> it doesn't require modification of the calling code. This is of course
>>>> not enough to isolate all code of all possible change, but it's still a
>>>> pretty useful tool -- and a very often used, one way or another.
>>>
>>> When I see it in my domain, I will beleive you.
>> I just don't give a damn whether you "believe" it or not. You have the
>> right not to believe the earth turn around the sun too.
>
> But code could in theory be presented that shows OOP being better for
> custom biz apps if OO is better there. I just have not seen it.
Does this help....
http://www.industriallogic.com/xp/refactoring/conditionalWithStrategy.html
>
>>> It does not work in the
>>> real world like it does in shape, animal, and device-driver book
>>> examples.
>> Which "real world" ?
>
> As I observe it.
>
>>> The real world (at least in my domain) does not change that
>>> way.
>> Which way ?
>
> A way that polymorphism simplifies. For a simple example, in typical
> OOP textbook shape examples, they often talk about how poly makes it
> easier to add another shape.
Can we forget books? By their very nature they can only show limited
detail and so there examples are usually very minor. But thats what
examples are for. Books tend to set the scene and leave it as an
exercise for the reader to extrapolate the examples and text into their
own domain.
>But, the case statement approach could
> make it easier to add another operation to all shapes, such as
> "rotate".
Easier - maybe.
But, you would have to edit, recompile
With OO we can support the Open-Closed Principle.
"SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.)
SHOULD BE OPEN FOR EXTENSION , BUT CLOSED FOR MODIFICATION"
See http://www.objectmentor.com/resources/articles/ocp.pdf
>I don't have to necessarily touch other routines, just make
> a new Rotate() routine. I am not recommending it, only giving an
> example of a chage that poly makes harder than case statements.
Actually, I'd find OO's poly makes it easier. YMMV
>
> If you agree with this, then you must agree that polymorphism does not
> make *all* changes easier. It comes down to probability: which changes
> are more common.
>
>>> The books set up an artificial strawman, and then knock it down
>>> with polymorphism.
>> wrt/ shapes, it's certainly not an "artificial strawman".
>
> The implication is that one should sub-type *everything*. This is the
> strawman.
>
Why?
Its certainly true that over use of Inheritence (either Type inheritance
or Implementation Inheritance) can cause problems. But this is true for
any mechanism poly or not.
This is a complete straw man argument in my opinion. Sure OO'ers can
create designs that dont allow flexibility just like any other.
Sasa
> Fine. Oop is great for device drivers (like print drivers above),
> animals, and shapes. But can we pleaaaaaase get something that reflects
> what real people see in the real workplace? The vast majority of
Um, drivers are prety real life example, just as any other "non custom
business software" example mentioned in this thread (sorry for nitpicking).
In my fairly limited experience, we had following stuff:
1) Paralel versions of essentially same application.
There were medium to large variations in look&feel (but not in the data
being edited on the forms), the business part was the same, but some
features were enabled in some versions.
2) Business validation and reporting the invalid data
Essentially we had 4 levels of business rules and 4 different situations
of presenting them, where situations do not map to the levels. I.e. in
every possible situation some subset of rules (based on levels
combinations and the current context) would be executed over the current
state of data.
BTW. it was required that data is not always persisted, that is - when
user is on the form, the control contents is not suppose to be stored.
However the rules had to be executed over this "in memory" data. The
rules also had to be executed over the persisted data.
3) The data is highly hierarchical, as presented in the UI. Logically,
some actions on the higher level can affect some or all parts of the
subtree.
4) Some simple DSL exists to enable non programmers, domain specialists,
to manage validation rules, dynamics of the hierachy (when should some
elements appear/disappear depending on the user input).
5) There are ca. 700 input dialogs. Some of those appear more than once
in different contexts (same form, for editing different data). Some are
dynamic in the sense that they can appear zero, once or any number of
times, depending on user input.
There is not OO model such as employees, orders, order items, ...
Rather, there is a metamodel which describes the hierarchy. The leafs
map to data either entered by user or computed. There is small engine
which evaluates the metamodel and performs significant actions
(transfering data to database, evaluating rules, showing/hiding UI
elements depending on the user input). The "engine" is implemented in
OO. It is not complex, but there were couple of occasions where
polymorphism fit nicely.
6) Metamodel is stored in SQL, however, the data is stored in non
relational database (essentially flat files).
It is the mid term goal that the database (for the data) gets changed.
Admittedly, the original selection of database was poor, in addition the
database dependent statements are all over the code (and not just the
engine), and it will be fairly painful to replace it.
I'm definitely OO biased (influence of my education), and came to this
system when it was already shaped. It is my belief that OO is good for
managing such complex stuff, much more appropriate and useful than
something procedural. It doesn't amount only to polymorphism, but rather
to the whole process of creating small, independent, reusable modules
which are easy to understand, maintain and improve. When good designed,
the changes usually do not ripple accross the entire system, and I feel
much less paranoic when editing the code. It is also easier for me to
analyze the code. We worked in fairly high paralelised mode, due to
strict interfaces and separation of concerns, we managed to work
independently and integrate without significant problems.
I'm willing to give the benefit of the doubt that OO is not optimal, but
I still fail to see the arguments coming from the hard OO critics.
Other than that the case for polymorphism (which to me means programming
to interface and varying implementations) would be unit testing - you
want to test a module and want the test to fail only if there is error
in that module and not in any other on which it depends.
As for swapping databases, I already mentioned in some other thread the
contrived example - imagine writing the application for one bank, now
imagine you want to sell it to some other bank. The business process is
essentially the same, the existing UI is perfectly fine. However, they
insist that you use their existing database which is from a different
vendor, and the structure is different than the one you use originally.
Well, this was somewhat unstructured (sorry), but I hope it does shed
some light on my thinking process. Any feedback is appriciated.
Sasa
Alvin Ryder
Before games my niche was, like yours, "custom biz software".
For a season all I had was SQL access and all I could do was dump
queries out, use unix shell scripts, AWK and Perl to crunch and then
output the results. UNIX filter style. Here OOP just got in the way!
Another time for simple web apps, all I needed was to parse some
parameters, tickle a model and spit out a page, again OOP was best left
out.
But other than that I often found great uses for inheritence and
polymorphism. Ok sometimes templates were better and these are not
strictly speaking OOP, they just happen to be going along for the ride.
At other times the relational model was the ants pants ... So I'm no
techno-bigot, I'll just use whatever it takes to get the job done but
I'd hate to loose the options OOP brings.
> >
> > You appear to understand the value of "driver" and "shape" examples but
> > can you see how far reaching they are? ;-) There are literally
> > thousands of GUI apps in this category!
> >
> >
> > GUI apps)
> > In general rich GUI's are composed of increasingly complex components,
> > inheritence is very useful here.
>
>
> I personally think that GUI's should be mostly declarative. For one,
> this would allow multiple languages to use the same GUI engine rather
> than write a different GUI engine for each language. Declarative,
> procedural, and relational are more sharable across languages in
> general. OO engines are tough to share across languages because some
> langs only offer single inheritence, some have dynamic objects and
> others static, etc. If you write to the lowest common denominator, you
> almost have a declarative interface anyhow.
>
It would be great to have declarative GUIs, I've spent a lot of time on
the subject but I'm afraid I've hit dry ground too many times ;-|
Meantime if I can't beat 'em I've gotta join 'em.
I'm not a fan of lowest common denominator though, I like to see the
processor cook and the GPU squeal, every last drop of computer juice
squeezed out.
>
> >
> > Again how many GUI apps are there on your PC? Ever tried to implement a
> > rich UI without OOP?
>
>
> No, but that is not what I do for a living. The issue is whether OO is
> good for all domains or a specific set. I won't dispute that OO may
> have decent uses for some domains, just not for custom biz software.
> Before somebody goes around telling everyone that OOP is a magic tool
> for every piece of software, they should add the proper disclaimers
> about the range of the claims.
>
Hey I agree whole-heartedly. I've always wished software came with
limitation sheets like electronics does. Resistor with value 100 ohms
+/- 2%, temperature range x - y etc etc but in software we just wave
magic dust around and play with $nake oil.
I just don't know enough about your type of custom biz software to
provide better examples. As I've already said for me, at times, OOP was
worse than useless! A great and futile distraction actually. At other
times it saved the day and it was supurb.
I took a post-grad OOP subject once, the professor did rattle off a
list of cases were OOP was *not* good, pitty my recollection is only
foggy. I'm pretty sure parsing was on there (that's still a good place
to use goto's), filters, reports? I dunno. I remember great case
studies that showed it improved productivity and all that spine
tingling stuff by about 10 to 20%, I was severely disappointed - I was
expecting 1000% like the buzz generator$ were saying.
>
> >
> > Topmind I agree all that glitters is not gold, all the hype in OOP does
> > not equal a silver bullet and all $nake oil doesn't help me do my job
> > better but can you see any value in what I've said? OOP *can* be very
> > useful to *some* people.
>
> Or some niches/domains.
>
Agreed.
>
> >
> > HTH,
> > Cheers.
>
> -T-
Cheers.
Dmitry A. Kazakov
> I took a post-grad OOP subject once, the professor did rattle off a
> list of cases were OOP was *not* good, pitty my recollection is only
> foggy. I'm pretty sure parsing was on there (that's still a good place
> to use goto's),
Actually OO is very good for parsing. I did it a lot, both without and with
OO, even in assembly language. The advantage of OO is that you can abstract
away many things irrelevant to the core parsing. For example, the source
code is abstracted as an interface. This makes the parser working with
files, streams, strings, text widgets, whatsoever. Another thing is the
parser output. OO allows you to define semantic callbacks. It is far
superior to dealing with some fixed output format, because the output can
be any. The same parser will give a parsing tree in a compiler, execute the
program in an interpreter, or colorize the source in an IDE. Error handling
implemented though exceptions is the best technique I know. A message is
constructed upon exception propagation with each handler adding its piece
of information to it.
> filters,
It is not my field, but I doubt it. Filters get connected through inputs
and outputs. It would be quite difficult to do without polymorphism.
Consider connecting unknown in advance filters in a loopback.
> reports? I dunno. I remember great case
> studies that showed it improved productivity and all that spine
> tingling stuff by about 10 to 20%, I was severely disappointed - I was
> expecting 1000% like the buzz generator$ were saying.
Yes, because bad programmers write bad programs in all languages using any
tools.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Davor
> Not necessarily. It depends on the coder. SQL is often not as
> expressive as I would like, so I shift that to procedural for some
> parts. (SQL's faults are generally language-specific, not the fault of
> relational in general. SQL is kind of long in the tooth.)
OK, what I am saying, to have people can meaningfully respond to your
challenge,
1. find a set of requirements for an application X for an application
from that domain of yours,
2. one should clearly define which part should be properly done using
relational processing and ignore it for the purposes of comparison,
3. define what "better" is (probably most important part), and
4. make in parallel an OOP and structured programming solution for the
part requiring procedural processing.
If you don't want to do (2), then make a comparison for such a system
without using relational processing on each side, i.e., make one purely
structured programming solution, and the other one OOP...
Also, I have read that article of yours on OOP Myths... I really feel
that you are not doing right thing with it. I have the impression that
you are really frustrated with early/current OO propaganda and OO
zealots, but your article is really not attacking this propaganda and
those guys who are making unjustified generalizations, but rather OOP
itself. I think you should clarify what you are going against. And you
don't seem to have anything against structured programming, so I really
do not know what you should have against OOP, which just makes
structured programming (slightly) more structured and provides few
additional mechanisms for code reuse and management. It does not
subtract anything from structured programming, and it does not force
you to use any of the features added to structured programming part, so
again there is really no need being against OOP...
Davor
Davor
systems still have a large number of features that very nicely map to
OO philosophy - so that both non-OO and OO folks can work happily with
the same system:
http://api.drupal.org/api/HEAD/file/developer/topics/oop.html
It's all about doing good design.
topmind
> topmind wrote:
> > Not necessarily. It depends on the coder. SQL is often not as
> > expressive as I would like, so I shift that to procedural for some
> > parts. (SQL's faults are generally language-specific, not the fault of
> > relational in general. SQL is kind of long in the tooth.)
>
> OK, what I am saying, to have people can meaningfully respond to your
> challenge,
>
> 1. find a set of requirements for an application X for an application
> from that domain of yours,
I've suggested the "Campus" example already, not because it is a
perfect representative, but because it is familiar to anybody who went
to college.
>
> 2. one should clearly define which part should be properly done using
> relational processing and ignore it for the purposes of comparison,
I don't see why this has to be the case. OO overlaps with both the
procedural and relational parts. OO'ers would be more likely to do
stuff in app code than in the DB/query. Good p/r apps shift a lot of
the burden to the DB.
>
> 3. define what "better" is (probably most important part), and
I don't see why that is up to me. I did not claim OOP is objectively
better nor objectively worse. I've tentatively concluded that it is a
subjective preference. Dispite OO and navigational looking like a pile
of flaming crap to me, some love and will probably always love it. It
fits their mind.
The metrics would have to be provided by those who claim that something
is objectively better or worse than another. I am *not* one of those
people.
I don't see how it can be any other way. In short, the OO crowd is
making a bunch of claims that they cannot objectively back, expecting
people to just trust them.
>
> 4. make in parallel an OOP and structured programming solution for the
> part requiring procedural processing.
>
> If you don't want to do (2), then make a comparison for such a system
> without using relational processing on each side, i.e., make one purely
> structured programming solution, and the other one OOP..
Procedural without relational can get pretty ugly. If Nygaard had a
good DB, I bet he would not need/try to invent OO.
>
> Also, I have read that article of yours on OOP Myths... I really feel
> that you are not doing right thing with it. I have the impression that
> you are really frustrated with early/current OO propaganda and OO
> zealots, but your article is really not attacking this propaganda and
> those guys who are making unjustified generalizations, but rather OOP
> itself. I think you should clarify what you are going against.
I debunk OO arguments as I encounter each them and even have a
disclaimer that they may not be globally accepted characteristics. If
OO or "good" OO is not clearly defined enough, that itself is a problem
with OO, not me. Not being consistent *is* one of my listed complaints
agains OO.
I cannot attack "proper" OO until a consensus of what proper OO is
appears. In the meantime, I explore specific claims of OO proponents.
If they are all dummies, then perhaps that too says something about OO.
> And you
> don't seem to have anything against structured programming, so I really
> do not know what you should have against OOP, which just makes
> structured programming (slightly) more structured and provides few
> additional mechanisms for code reuse and management.
How are you measuring "more structured"?
> It does not
> subtract anything from structured programming, and it does not force
> you to use any of the features added to structured programming part, so
> again there is really no need being against OOP...
Not entirely true. For example, in Java there can be no global Print()
function. It always has to have a noun or handle hooked to it. Further,
if the API's are OOP, you are generally stuck with using OO syntax,
giving us crap like:
(a.xx + b.yy).String.len
Instead of
len(xx + yy)
Besides my criticisms are about OO, not imperative. I thus don't
understand your complaint.
>
> Davor
-T-
topmind
> topmind wrote:
> > Bruno Desthuilliers wrote:
> >> topmind a écrit :
> >>> Bruno Desthuilliers wrote:
> >>>
> >>>> topmind a écrit :
> >>>> (snip)
> >>>>> IF statements are simply more bendable and flexible to handle real-world
> >>>>> changes. You can refine them without moving lots of code around.
> >>>> But not without modifying existing code. And in a lot of cases modifying
> >>>> it in *many* places. What polymorphism brings is mainly using another
> >>>> way of doing the dispatch that doesn't require explicit branching - so
> >>>> it doesn't require modification of the calling code. This is of course
> >>>> not enough to isolate all code of all possible change, but it's still a
> >>>> pretty useful tool -- and a very often used, one way or another.
> >>>
> >>> When I see it in my domain, I will beleive you.
> >> I just don't give a damn whether you "believe" it or not. You have the
> >> right not to believe the earth turn around the sun too.
> >
> > But code could in theory be presented that shows OOP being better for
> > custom biz apps if OO is better there. I just have not seen it.
>
> Does this help....
>
> http://www.industriallogic.com/xp/refactoring/conditionalWithStrategy.html
How is this better than a procedural/relational version?
>
>
> >
> >>> It does not work in the
> >>> real world like it does in shape, animal, and device-driver book
> >>> examples.
> >> Which "real world" ?
> >
> > As I observe it.
> >
> >>> The real world (at least in my domain) does not change that
> >>> way.
> >> Which way ?
> >
> > A way that polymorphism simplifies. For a simple example, in typical
> > OOP textbook shape examples, they often talk about how poly makes it
> > easier to add another shape.
>
> Can we forget books? By their very nature they can only show limited
> detail and so there examples are usually very minor. But thats what
> examples are for. Books tend to set the scene and leave it as an
> exercise for the reader to extrapolate the examples and text into their
> own domain.
I am only illustrating the fact that not all changes are beneficial to
the poly version. It is a technical illustration to at least establish
that fact. Thus, the practicality is not important for this stage of
the argument I was making.
If you agree with what I am illustrating, then you MUST agree that
polymorphism does not improve on ALL changes. That is all I am strying
to establish with that.
>
> >But, the case statement approach could
> > make it easier to add another operation to all shapes, such as
> > "rotate".
>
> Easier - maybe.
>
> But, you would have to edit, recompile
>
> With OO we can support the Open-Closed Principle.
>
> "SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.)
> SHOULD BE OPEN FOR EXTENSION , BUT CLOSED FOR MODIFICATION"
>
> See http://www.objectmentor.com/resources/articles/ocp.pdf
1. Strait polymorphism does NOT support O.C. for adding new functions
to all shapes. You must visit each shape class (unless some inherit).
You can add indirection maybe to get such, but that is true of
anything. We are comparing plane-jane poly here, not strategy and
visitor.
2. I've used languages where I could add a new subroutine *without*
having to recompile. C is not the pinnical of procedural. Even for
languages that do need compiling, I still don't have to touch any
*existing* code to add a new method that every shape can use. Regular
poly can't do this.
>
> >I don't have to necessarily touch other routines, just make
> > a new Rotate() routine. I am not recommending it, only giving an
> > example of a chage that poly makes harder than case statements.
>
> Actually, I'd find OO's poly makes it easier. YMMV
Show me the code.
If you are not defending polymorphism, then what are you defending?
Massive composition is ugly navigational. You turn your code into a
(crappy) database or a Rube Goldburg mess.
-T-
Robert Martin
> Well, it is a technique that is waaaaaaay oversold. It has duped
> Dilbertian bosses the world over. And even many OO affectionado's will
> admit that too many newbies abuse it and go hog-wild with class
> hierarchies. Plus, if we load up our toolbox with every marginally good
> idea, we would have 10 paradigms in there such that nobody can read our
> code. It may be good job security for the purpretrator, but not very
> economical.
On the other hand, it seems that your position is that though the tool
can be useful, nobody should use it because it has been abused, and
because too many tools leads to confusion. I think that's a silly
position.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Robert Martin
> I would welcome some coded examples, something like the Campus example
Can you point me to a description of the campus example?
topmind
Sasa wrote:
> topmind wrote:
> > Fine. Oop is great for device drivers (like print drivers above),
> > animals, and shapes. But can we pleaaaaaase get something that reflects
> > what real people see in the real workplace? The vast majority of
>
> Um, drivers are prety real life example, just as any other "non custom
> business software" example mentioned in this thread (sorry for nitpicking).
>
>
> In my fairly limited experience, we had following stuff:
>
> 1) Paralel versions of essentially same application.
> There were medium to large variations in look&feel (but not in the data
> being edited on the forms), the business part was the same, but some
> features were enabled in some versions.
Why did you have parellel versions?
Plus, the pattern of the parellel version differences is NOT
tree-shaped in my observation. It is more or less like the "cartesian
join of features" example that I gave to R. Martin.
>
> 2) Business validation and reporting the invalid data
> Essentially we had 4 levels of business rules and 4 different situations
> of presenting them, where situations do not map to the levels. I.e. in
> every possible situation some subset of rules (based on levels
> combinations and the current context) would be executed over the current
> state of data.
> BTW. it was required that data is not always persisted, that is - when
> user is on the form, the control contents is not suppose to be stored.
> However the rules had to be executed over this "in memory" data. The
> rules also had to be executed over the persisted data.
I am not sure what you mean. Good tools would allow "in memory" copies
of schemas and data tables such that I could query them just as if they
were in a database. This used to be fairly common in 80's tools. Only
ColdFusion supports this now that I know of (and those left over from
the 80's, such as FoxPro.)
If you want to claim that OO is the consolution prize for lame database
tools, then you may have a point.
>
> 3) The data is highly hierarchical, as presented in the UI. Logically,
> some actions on the higher level can affect some or all parts of the
> subtree.
What data is hierarchical? I would like to inspect the hierarchy.
>
> 4) Some simple DSL exists to enable non programmers, domain specialists,
> to manage validation rules, dynamics of the hierachy (when should some
> elements appear/disappear depending on the user input).
>
> 5) There are ca. 700 input dialogs. Some of those appear more than once
> in different contexts (same form, for editing different data). Some are
> dynamic in the sense that they can appear zero, once or any number of
> times, depending on user input.
Why couldn't p/r do the same thing?
>
> There is not OO model such as employees, orders, order items, ...
> Rather, there is a metamodel which describes the hierarchy. The leafs
> map to data either entered by user or computed. There is small engine
> which evaluates the metamodel and performs significant actions
> (transfering data to database, evaluating rules, showing/hiding UI
> elements depending on the user input). The "engine" is implemented in
> OO. It is not complex, but there were couple of occasions where
> polymorphism fit nicely.
Again, I would like to see an example of this hierarchy. There are not
too many real biz things that fit nicely into a hierarchy. If you found
a blue moon oncer, then so be it. Every dog has its day, even OO.
>
> 6) Metamodel is stored in SQL, however, the data is stored in non
> relational database (essentially flat files).
Why?
> It is the mid term goal that the database (for the data) gets changed.
> Admittedly, the original selection of database was poor, in addition the
> database dependent statements are all over the code (and not just the
> engine), and it will be fairly painful to replace it.
I rarely had to replace DB engines. Plus, one could put all the SQL in
one place *without* OOP if you really want to take that odd approach.
Thus, that is not really an OOP-vs-p/r issue.
>
> I'm definitely OO biased (influence of my education), and came to this
> system when it was already shaped. It is my belief that OO is good for
> managing such complex stuff, much more appropriate and useful than
> something procedural.
I keep hearing such claims over and over from OO affectionados, but
never see the actual code being better. Is it possible that you never
mastered procedural/relational because lack of exposure or good
training?
> It doesn't amount only to polymorphism, but rather
> to the whole process of creating small, independent, reusable modules
> which are easy to understand, maintain and improve. When good designed,
> the changes usually do not ripple accross the entire system,
Isn't that true of anything?
> and I feel
> much less paranoic when editing the code. It is also easier for me to
> analyze the code. We worked in fairly high paralelised mode, due to
> strict interfaces and separation of concerns, we managed to work
> independently and integrate without significant problems.
Schemas can do something similar. Each section only worrys about what
it puts or reads onto the DB and not other code modules (other than
shared libraries).
>
> I'm willing to give the benefit of the doubt that OO is not optimal, but
> I still fail to see the arguments coming from the hard OO critics.
>
> Other than that the case for polymorphism (which to me means programming
> to interface and varying implementations) would be unit testing - you
> want to test a module and want the test to fail only if there is error
> in that module and not in any other on which it depends.
I would like to inspect such code.
>
> As for swapping databases, I already mentioned in some other thread the
> contrived example - imagine writing the application for one bank, now
> imagine you want to sell it to some other bank. The business process is
> essentially the same, the existing UI is perfectly fine. However, they
> insist that you use their existing database which is from a different
> vendor, and the structure is different than the one you use originally.
Okay, but that is a known up-front need. Plus, it can be done with
functions. Generally you would target about 4 vendors (SQL-Server,
Oracle, DB-2, Postgre), and thus infrequentally have to add new CASE
items. You can't target every DB vendor because then you would have to
test all jillion vendors. And if you did have that many, why not put
the SQL in the database and then dispatch it that way? Special
characters would mark variable insertion place-holders in the SQL.
table: SQLstatements
------------
queryID
DBvendorID
descript
SQLtext
parameterDescript // (perhaps use a param table for this)
table: DBvendors
-----------
venderID
venderDescript // example: Oracle, DB2, SQL-Server
useAltID // vendor to use if statement not available for given
vendor
This way you could make some nice screens to bring up, report on, and
inspect all the SQL statements for the different vendors. I've seen
similar tools to allow DBA's to change SQL without having to fiddle
with code, although it had nothing to do with vendors.
One can add a new DB vendor without compiling a single line of new
code.
How's that for abstraction? The mother of all DB-vendor-wrappers is a
DB! Out-poly that!
>
> Well, this was somewhat unstructured (sorry), but I hope it does shed
> some light on my thinking process. Any feedback is appriciated.
>
> Sasa
-T-
topmind
> On 2006-07-07 16:07:53 -0500, "topmind" <top...@technologist.com> said:
>
> > Well, it is a technique that is waaaaaaay oversold. It has duped
> > Dilbertian bosses the world over. And even many OO affectionado's will
> > admit that too many newbies abuse it and go hog-wild with class
> > hierarchies. Plus, if we load up our toolbox with every marginally good
> > idea, we would have 10 paradigms in there such that nobody can read our
> > code. It may be good job security for the purpretrator, but not very
> > economical.
>
> On the other hand, it seems that your position is that though the tool
> can be useful, nobody should use it because it has been abused, and
> because too many tools leads to confusion. I think that's a silly
> position.
Then why not include ess-expressions and functional and logical in an
application also if we go that route? I don't think it is economical to
pile on the paradigms and techniques if each adds only marginal
improvement. From the stock-holder's perspective they would rather pay
something who knows just 2 paradigms than somebody who knows 8 unless
the 8-er can demonstrate they are worth the extra bucks. At best the OO
improvements mount to only something like 2% and maybe 5% on a good
day.
Consultants and mentors like Paradigm Potpourri because they get paid
more. But that does not mean it is economical. Is it possible you are
biased toward such because of your position? I am just asking, not
accusing. Being in a position for a long time sometimes makes one lose
perspective of other points of view, such as the owner's.
Paradigm Potpourri complicates staffing.
> --
> Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
-T-
Davor
> Besides my criticisms are about OO, not imperative. I thus don't
> understand your complaint.
OK, maybe this will help, my feeling is that you are throwing at
comp.object community a challenge that follows following pattern:
In *my* application area people write text. That text is data that
people constantly manipulate. I think OOP solution to this type of data
manipulation sucks. In particular in my application area, I use text
editor with advanced text processing capabilities, including regex, and
so on, that completely satisfies all my needs. If your OOP is so good,
show me a better way of doing what I do regularly using my VIM editor.
Here is a concrete example that everyone who has went to a college has
accounted:
In the following text replace all occurrences of "bla" with "alb":
aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla
aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla
aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla
My solution is
:%s/bla/alb/g
Let me see your OOP solution to this problem if OOP is so good!
Davor
topmind
Alvin Ryder wrote:
> topmind wrote:
> > Alvin Ryder wrote:
> > > topmind wrote:
> > > > Robert Martin wrote:
> > > > > On 2006-07-07 07:32:30 -0500, "Alvin Ryder" <alvi...@telstra.com> said:
>
> It would be great to have declarative GUIs, I've spent a lot of time on
> the subject but I'm afraid I've hit dry ground too many times ;-|
> Meantime if I can't beat 'em I've gotta join 'em.
It think it takes many people experimenting to get a GUI framework
right regardless of whether it is declarative or imperative. The best
ones are more or less accidents that catch on because they got enough
of it right. Look how many times Java tried (and is still trying).
> > > Again how many GUI apps are there on your PC? Ever tried to implement a
> > > rich UI without OOP?
> >
> >
> > No, but that is not what I do for a living. The issue is whether OO is
> > good for all domains or a specific set. I won't dispute that OO may
> > have decent uses for some domains, just not for custom biz software.
> > Before somebody goes around telling everyone that OOP is a magic tool
> > for every piece of software, they should add the proper disclaimers
> > about the range of the claims.
> >
>
> Hey I agree whole-heartedly. I've always wished software came with
> limitation sheets like electronics does. Resistor with value 100 ohms
> +/- 2%, temperature range x - y etc etc but in software we just wave
> magic dust around and play with $nake oil.
>
> I just don't know enough about your type of custom biz software to
> provide better examples. As I've already said for me, at times, OOP was
> worse than useless! A great and futile distraction actually. At other
> times it saved the day and it was supurb.
It would be nice if somebody documented what how and why OO was
"supurb". Also, "saving the day" is sometimes cooincidental. Software
design is like financial investing, you make the best decision you can
about the paths of the future, and sometimes you are right and
somethings you get it really wrong and buy Petfood.com just before the
Big Crash.
>
> I took a post-grad OOP subject once, the professor did rattle off a
> list of cases were OOP was *not* good, pitty my recollection is only
> foggy. I'm pretty sure parsing was on there (that's still a good place
> to use goto's), filters, reports? I dunno. I remember great case
> studies that showed it improved productivity and all that spine
> tingling stuff by about 10 to 20%, I was severely disappointed - I was
> expecting 1000% like the buzz generator$ were saying.
I would like to see such studies. I've read about one they did at a
university, but you have to pay to get it. Further, the programmers
didn't have DB's as a tool. I agree that OO is probably better than
procedural withOUT DB's. Xbase (dBase dialects) changed my view on how
powerful and nimble tables can be. It was a yawny language, but the
tabling features and integration more than made up for that fact. It is
unfortunate that most people just see the Big-Iron Oracle side of DB's.
-T-
Dmitry A. Kazakov
And if somebody pointed out that this solution won't work if bla shouldn't
be replaced in quoted strings and comments, because standard regular
expressions fundamentally cannot match nested things. He would answer that
it is academic and out of biz.
Alvin Ryder
> On 8 Jul 2006 05:09:05 -0700, Alvin Ryder wrote:
>
> > I took a post-grad OOP subject once, the professor did rattle off a
> > list of cases were OOP was *not* good, pitty my recollection is only
> > foggy. I'm pretty sure parsing was on there (that's still a good place
> > to use goto's),
>
> Actually OO is very good for parsing. I did it a lot, both without and with
> OO, even in assembly language. The advantage of OO is that you can abstract
> away many things irrelevant to the core parsing. For example, the source
> code is abstracted as an interface. This makes the parser working with
> files, streams, strings, text widgets, whatsoever. Another thing is the
> parser output. OO allows you to define semantic callbacks. It is far
> superior to dealing with some fixed output format, because the output can
> be any. The same parser will give a parsing tree in a compiler, execute the
> program in an interpreter, or colorize the source in an IDE. Error handling
> implemented though exceptions is the best technique I know. A message is
> constructed upon exception propagation with each handler adding its piece
> of information to it.
>
Arh, yes that makes sense, I'm sure you are right. I should've thought
about my comment more deeply rather than relying on dim memories.
Thanks for clearing that up.
Cheers.
topmind
> On 8 Jul 2006 12:46:09 -0700, Davor wrote:
>
> > topmind wrote:
> >> Besides my criticisms are about OO, not imperative. I thus don't
> >> understand your complaint.
> >
> > OK, maybe this will help, my feeling is that you are throwing at
> > comp.object community a challenge that follows following pattern:
> >
> > In *my* application area people write text. That text is data that
> > people constantly manipulate. I think OOP solution to this type of data
> > manipulation sucks. In particular in my application area, I use text
> > editor with advanced text processing capabilities, including regex, and
> > so on, that completely satisfies all my needs. If your OOP is so good,
> > show me a better way of doing what I do regularly using my VIM editor.
> >
> > Here is a concrete example that everyone who has went to a college has
> > accounted:
> >
> > In the following text replace all occurrences of "bla" with "alb":
> >
> > aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla
> > aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla
> > aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla aaaa bla
> >
> > My solution is
> >
> >:%s/bla/alb/g
> >
> > Let me see your OOP solution to this problem if OOP is so good!
In this twisted analogy, what is my counterpart to VIM and reg-ex?
>
> And if somebody pointed out that this solution won't work if bla shouldn't
> be replaced in quoted strings and comments, because standard regular
> expressions fundamentally cannot match nested things. He would answer that
> it is academic and out of biz.
Are you accusing me of intentionally misrepresenting what my domain
requires? Where have I done such? Your analogies make no sense.
>
> --
> Regards,
> Dmitry A. Kazakov
-T-
Davor
> In this twisted analogy, what is my counterpart to VIM and reg-ex?
VIM = (let's say) Microsoft Access
(both very complex systems)
reg-ex = SQL
(both very nice domain specific declarative languages based on solid
mathematical theory)
> >
> > And if somebody pointed out that this solution won't work if bla shouldn't
> > be replaced in quoted strings and comments, because standard regular
> > expressions fundamentally cannot match nested things. He would answer that
> > it is academic and out of biz.
>
> Are you accusing me of intentionally misrepresenting what my domain
> requires? Where have I done such? Your analogies make no sense.
(I did not write this comment so skipping reply to it.)
Davor
topmind
Davor wrote:
> topmind wrote:
>
> > In this twisted analogy, what is my counterpart to VIM and reg-ex?
>
> VIM = (let's say) Microsoft Access
>
> (both very complex systems)
Perhaps unnecessarily so :-)
>
> reg-ex = SQL
>
> (both very nice domain specific declarative languages based on solid
> mathematical theory)
This implies that if you have relational tools, you don't need OO. Is
this what you are implying or agreeing to?
How many others would consider relational a "domain specific" tool?
>
> Davor
-T-
Sasa
> Sasa wrote:
>
>>topmind wrote:
>>
>>>Fine. Oop is great for device drivers (like print drivers above),
>>>animals, and shapes. But can we pleaaaaaase get something that reflects
>>>what real people see in the real workplace? The vast majority of
>>
>>Um, drivers are prety real life example, just as any other "non custom
>>business software" example mentioned in this thread (sorry for nitpicking).
>>
>>
>>In my fairly limited experience, we had following stuff:
>>
>>1) Paralel versions of essentially same application.
>>There were medium to large variations in look&feel (but not in the data
>>being edited on the forms), the business part was the same, but some
>>features were enabled in some versions.
>
>
> Why did you have parellel versions?
Because it was requested from us :-)
Essentially - different versions for different clients. For example,
there was full blown version with relatively classic UI and there was
stripped down version with fancy looking UI. I think total number of
versions was >10.
> Plus, the pattern of the parellel version differences is NOT
> tree-shaped in my observation. It is more or less like the "cartesian
> join of features" example that I gave to R. Martin.
Whatever. It comes down to having some common logic and some variations.
For example - the forms have different look & feel. But the
communication mechanism with the database remains the same. If you use
some mediator between the view and the model where view is abstracted
with interfaces, you can easily switch implementations.
>
>
>>2) Business validation and reporting the invalid data
>>Essentially we had 4 levels of business rules and 4 different situations
>>of presenting them, where situations do not map to the levels. I.e. in
>>every possible situation some subset of rules (based on levels
>>combinations and the current context) would be executed over the current
>>state of data.
>>BTW. it was required that data is not always persisted, that is - when
>>user is on the form, the control contents is not suppose to be stored.
>>However the rules had to be executed over this "in memory" data. The
>>rules also had to be executed over the persisted data.
>
>
> I am not sure what you mean. Good tools would allow "in memory" copies
> of schemas and data tables such that I could query them just as if they
> were in a database. This used to be fairly common in 80's tools. Only
> ColdFusion supports this now that I know of (and those left over from
> the 80's, such as FoxPro.)
I never said OO is the only way to resolve it. To me is the most elegant
to deal with such differences. By using interfaces, I can remove details
from the evaluation logic which really shouldn't care where the data
resides. Some simmple factory mechanism would deal with that.
BTW. this allows me unit testing of the evaluation logic, because I can
provide "test" data source which feeds the evaluation engine with test data.
> If you want to claim that OO is the consolution prize for lame database
> tools, then you may have a point.
I made no such claim. To me OO is nice general purpose mainstream tool
for dealing with complexity and developing agile code.
>>3) The data is highly hierarchical, as presented in the UI. Logically,
>>some actions on the higher level can affect some or all parts of the
>>subtree.
>
>
> What data is hierarchical? I would like to inspect the hierarchy.
Maybe I wasn't clear enough. The requirements wanted that the data is
presented as the hierarchy. Consider something like windows explorer -
tree on the left, input dialogs on the right. If you are on the level 2
and edit some stuff, some subset of the subhierarchy could change
(entire tree items could appear/disappear, some subcontrols on one
dialog in subhierarchy could be disabled or disappear)
>>4) Some simple DSL exists to enable non programmers, domain specialists,
>>to manage validation rules, dynamics of the hierachy (when should some
>>elements appear/disappear depending on the user input).
>>
>>5) There are ca. 700 input dialogs. Some of those appear more than once
>>in different contexts (same form, for editing different data). Some are
>>dynamic in the sense that they can appear zero, once or any number of
>>times, depending on user input.
>
>
> Why couldn't p/r do the same thing?
What's a p/r?
>>There is not OO model such as employees, orders, order items, ...
>>Rather, there is a metamodel which describes the hierarchy. The leafs
>>map to data either entered by user or computed. There is small engine
>>which evaluates the metamodel and performs significant actions
>>(transfering data to database, evaluating rules, showing/hiding UI
>>elements depending on the user input). The "engine" is implemented in
>>OO. It is not complex, but there were couple of occasions where
>>polymorphism fit nicely.
>
>
> Again, I would like to see an example of this hierarchy. There are not
> too many real biz things that fit nicely into a hierarchy. If you found
You mean in your experience/opinion, or there is some definite formal
proof of it?
> a blue moon oncer, then so be it. Every dog has its day, even OO.
:-)
>>6) Metamodel is stored in SQL, however, the data is stored in non
>>relational database (essentially flat files).
>
>
> Why?
I never asked, but everyone agrees it was a bad decision.
>
>
>>It is the mid term goal that the database (for the data) gets changed.
>>Admittedly, the original selection of database was poor, in addition the
>>database dependent statements are all over the code (and not just the
>>engine), and it will be fairly painful to replace it.
>
>
> I rarely had to replace DB engines. Plus, one could put all the SQL in
> one place *without* OOP if you really want to take that odd approach.
> Thus, that is not really an OOP-vs-p/r issue.
In that sense, nothing is - you can do almost anything with any type of
system.
>>I'm definitely OO biased (influence of my education), and came to this
>>system when it was already shaped. It is my belief that OO is good for
>>managing such complex stuff, much more appropriate and useful than
>>something procedural.
>
>
> I keep hearing such claims over and over from OO affectionados, but
> never see the actual code being better. Is it possible that you never
It is hard to prove. Imagine complex system which took collective effort
of couple of man years (only developers time included). How can you
prove that it has (or has not) the best possible choice of languages, or
that its architecture and design are optimal?
The best I can do is, observe in every day work where does it hurt me to
work with the code, and where does it feel simple and intuitive. Nicely
designed OO code works for me and my colleagues. That doesn't mean that
other languages (such as sql, prolog or lisp) are excluded. But I like
to deal with complexity mostly by thinking in objects.
> mastered procedural/relational because lack of exposure or good
> training?
It is possible. My experience is most certainly small, so I give the
benefit of the doubt to any claims, including the ones where OO gets
completely downgraded.
Could you answer the same question for yourself?
>>It doesn't amount only to polymorphism, but rather
>>to the whole process of creating small, independent, reusable modules
>>which are easy to understand, maintain and improve. When good designed,
>>the changes usually do not ripple accross the entire system,
>
>
> Isn't that true of anything?
Most probably. My prefered dialect is OO.
>>and I feel
>>much less paranoic when editing the code. It is also easier for me to
>>analyze the code. We worked in fairly high paralelised mode, due to
>>strict interfaces and separation of concerns, we managed to work
>>independently and integrate without significant problems.
>
>
> Schemas can do something similar. Each section only worrys about what
> it puts or reads onto the DB and not other code modules (other than
> shared libraries).
>
>
>>I'm willing to give the benefit of the doubt that OO is not optimal, but
>>I still fail to see the arguments coming from the hard OO critics.
>>
>>Other than that the case for polymorphism (which to me means programming
>>to interface and varying implementations) would be unit testing - you
>>want to test a module and want the test to fail only if there is error
>>in that module and not in any other on which it depends.
>
>
> I would like to inspect such code.
I'm no unit testing expert. Keeping that in mind, consider following
example:
I1 <- TestableModule -> I2
Since testable module depends on interfaces, by providing simple test
implementations, one can test the module in the isolation. Tests will
fail only if there is an error in TestableModule or in the test itself.
The implementations used in production are not included in the test.
>>As for swapping databases, I already mentioned in some other thread the
>>contrived example - imagine writing the application for one bank, now
>>imagine you want to sell it to some other bank. The business process is
>>essentially the same, the existing UI is perfectly fine. However, they
>>insist that you use their existing database which is from a different
>>vendor, and the structure is different than the one you use originally.
>
>
> Okay, but that is a known up-front need. Plus, it can be done with
Not always, and it can be secondary. Consider that you deal with single
client. So you start with your application, code it, test it and deploy
it. And then the company tries to sell application to other potential
clients. And one client says "This is great, but we require that you use
our existing database".
My general point is that you usually don't know where the change will
be. By breaking the system into small, independent, cohesive components
(which to me means decoupling), one has the system which is easier to
change. Sure, it will not cover all possible change scenarios, but IMHO
it still helps a lot.
The finer the granule of the module division, the better the chance that
modules will get reused - both in the changed version of the same
system, as well as in some other system.
Dealing with future changes is not the only motivator. IMHO it is easier
to develop and work with small, independent modules, they are easier to
develop, integrate, analyze, debug and test.
What if structure of the database varies, and you have business
calculations (which is common for all systems) in SQL?
To put it more systematically - consider following constraints:
1. You ship the application to multiple clients.
2. The databases systems (both vendors, and the structure of database)
are different. The clients don't allow you to use your own database, or
to change the structure of the existing one, which you must use.
3. The business logic is mostly common. Some subtle variations can exist.
> How's that for abstraction? The mother of all DB-vendor-wrappers is a
> DB! Out-poly that!
You might be right, wrong, or it comes down to cultural differences.
I somehow don't fancy the idea of having a lot of code snippets stored
in the database. I prefer OO with statically typed language for the code
(but of course, it depends on the nature of the problem). With
appropriate IDE, I can work easily with the code, and have features such
as refactoring, debugging and compile time checking. It doesn't resolve
all possible problems, but it helps dealing with some of them.
Sasa
Dmitry A. Kazakov
No, it is merely a refutation of your argumentation. You voluntarily vary
the borders of what you call your domain to elude uncomfortable questions
about applicability of the methods you propose. If you want to convince
other people, show how your methods work in their domains!
--
Regards,
Dmitry A. Kazakov
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>
>>
>>>The real world (at least in my domain) does not change that
>>>way.
>>
>>Which way ?
>
>
> A way that polymorphism simplifies. For a simple example, in typical
> OOP textbook shape examples, they often talk about how poly makes it
> easier to add another shape. But, the case statement approach could
> make it easier to add another operation to all shapes, such as
> "rotate". I don't have to necessarily touch other routines, just make
> a new Rotate() routine.
Nor do I. You don't have to touch any existing method to add a method to
a class (or to an object). You may also want to have a look at
multimethods, which is yet another application of polymorphism.
> I am not recommending it, only giving an
> example of a chage that poly makes harder than case statements.
Wrong example.
> If you agree with this, then you must agree that polymorphism does not
> make *all* changes easier.
No single technic makes "all" changes easier. The right application of
the right technics at the right place can make some changes easier.
> It comes down to probability: which changes
> are more common.
Where and how you have to apply decoupling (whatever the technic used
for it) indeed depends on where you expect what kind of changes. This
not big news.
>
>>>The books set up an artificial strawman, and then knock it down
>>>with polymorphism.
>>
>>wrt/ shapes, it's certainly not an "artificial strawman".
>
>
> The implication is that one should sub-type *everything*. This is the
> strawman.
for which definition of "sub-typing" ? The problem is not with
polymorphism, but to how and where you use it. If you can't see that,
you're rejecting a useful tool for no other reason than a
misunderstanding of how to use the tool.
(snip)
>>>But *overall* I find Sets one
>>>of the best tools for managing changes.
>>
>>A valid definition of a type is "a set of values + a set of operations
>>on these values". If so, if types are sets and sets are a good tool for
>>managing change, then types are a good tool for managing change.
>
>
> Types tend to be a directed acyclic graph (did I say that right?),
Care to explain ?
> while sets can represent *any* graph.
And ?
> Adding cycles to types is not
> something people have a lot of experience with, and may be inharently
> messy.
>
>>>For one, they don't have the
>>>mutual-exclusiveness problems that poly tends to.
>>
>>I don't see how polymorphism implies more "mutual exclusiveness" than
>>ifs or switches (ok, depending on which kind of polymorphism, and how it
>>is implemented and used).
>
>
> Before:
>
> switch on X {
> case 1 then {zark()}
> case 2 then {grog()}
> }
>
> After:
>
> if x=1 then {zark()}
> if x=2 then {grog()}
>
> I removed mutual-exlusiveness
Err... I don't know where you get the idea that 1 == 2.
> without moving implementation code
> around.
This is debatable - you had to modify existing code. And in much
"real-world" (your label) applications, this kind of changes usually
have to be reported in many places (my experience with 50+KLOC
procedural business apps).
(snip)
> Now stuff can be
> both. For example, a bank may start out with Checking accounts *or*
> Savings accounts. I once heard on the radio that a bank was offering an
> account that was *both*. The fees were based on how many checks you
> wrote IIRC, not an up-front classification.
Ever heard of strategy pattern ?
> If you wrote few or no
> checks, then you had the same fees as a Savings account. The poly OO'er
> would have more code rework to undo mutual exclusiveness.
Which "mutual exclusiveness" ?
You fail to provide a working "foobar example" *and* to explain why
polymorporphism would necessarily imply "mutual exclusiveness" (hints :
read about the template method pattern and multimethods).
>>>I
>>>find them far more promising than polymorphism. (RDBMS are currently
>>>the best available Set tools.)
>>
>>It seems to be commonly agreed on cdt that SQL DBMS are not really
>>"relational" DBMS (in that they don't fully implement the relationel
>>model), and that there's in fact actually no available "RDBMS" - at most
>>SQL DBMS.
>
> I would indeed change a lot of things about the implementation of RDBMS
> and their query languages. But even *with* their warts, they beat most
> OO designs.
On what points, according to which metric ?
>
>>BTW, there's much more to the relational model than just "sets"...
>
> True, but this topic is about polymorphism and variation management,
> and that is where sets shine.
Please elaborate. You haven't demonstrated anything yet - not even with
a "lab example".
>
>>>If there is a Silver bullet,
>>
>>There's none.
>
>
> Sets are a brass bullet.
So if I understand correctly, you don't believe in silver-bullets, but
you do believe in brass-bullets ?