Re: What databases have taught me

From: Frans Bouma <perseus.usenetNOSPAM_at_xs4all.nl>
Date: 28 Jun 2006 09:26:44 GMT
Message-Id: <xn0eo0evq74vv1002_at_news.xs4all.nl>


Bob Badour wrote:

> Frans Bouma wrote:
> > frebe73_at_gmail.com wrote:
> >
> > > > Strategy pattern doesn't imply subtyping, cf above.
> > >
> > > http://en.wikipedia.org/wiki/Strategy_pattern
> > > http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/Strate
> > > gyPa ttern.htm
> > >
> > > It seem to me that subtyping is used. Maybe this is an issue about
> > > typeless vs types languages.
> >
> > No, the strategy pattern can also be used with plug-in style object
> > usage at runtime. Code calls a generic method, that method checks
> > the active object which has to handle the call and if it's present
> > it calls into that object. You then can swap out algorithms by
> > swapping out the object and replace it with another one. Very
> > common in a lot of software, like oh, operating systems.
>
> With all due respect, the generic method makes all these types
> subtypes regardless whether one declares them that way or even uses a
> language that allows one to. They are all subtypes of the union of
> types defining the method.

         you mean 'part of the code the generic method is in' ? strictly speaking, in memory, THAT's correct. For example if you use function pointers in C to mimic this behavior, you effectively inject code in your total code. But that's not the same as being part of the type, as that's not true. The code in generic method can be completed by programming against an interface. Which code implements that interface at runtime is of no concern of the generic method.

> > > > I'm afraid that the problem is more with silver-bullet dealers
> > > > than with OO itself. If you (ie : a 'generic' you - not
> > > > necessarily th person named Fredrik Bertilsson) believe that
> > > > just using a braindead so-called "OO" language and following
> > > > the braindead "OO 101" tutorials is enough to get any advantage
> > > > from OO, then you're in deep deep trouble... And you can
> > > > s/OO/whatever/g IMHO.
> > >
> > > The reason that OO is misused is that nobody really knows what OO
> > > is. OO also seem to change by time.
> >
> > if you apply a given algorithm A, and in 1980 it was called X and
> > today it's called Y, did A change because of that name change? No.
>
> That wasn't his argument though. If you call one algorithm X in 1980
> and today another algorithm is called X, are they the same
> algorithm? No.
>
> Thus, speaking sensibly about X becomes extremely difficult. See
> Date's _Principle of Incoherence_.

        of course if the same name means 2 things, speaking about any of these two things by using that ambiguous name is difficult. However 'OO' means 'object oriented', i.e.: it's a snipped acronym, it's incomplete. So actually it doesn't mean anything. Now, if you look at when 'OO' is used stand along as an acronym, it's so diverse, it's irrelevant what meaning the standalone acronym 'OO' stands for

> > Funny thing is that if you give 3 randomly chosen database
> > architects (or whatever the f... some people want to call these
> > people) the task to develop the RDM for a big hospital (so you end
> > up with at least 700 or so tables), you will definitely get 3
> > completely different models.
>
> I will assume that by 'models' above you mean logical designs. The
> differences should come as no surprise because they start from
> requirements and not from a conceptual analysis, which creates the
> starting point for logical design. Conceptual analysis is 'anything
> goes' and is well outside the scope of the relational model.

        true, but that's the same with OOAD.

> If all three designers started from the same conceptual analysis, the
> logical designs would be very similar; although, the theory related
> to higher normal forms proves that in at least some cases there are
> multiple equivalent non-loss decompositions using project/join.
> Making those minor differences meaningless.
>
> While a graph of the relations and references among them might look
> different when drawn by the three designers, they would be
> pretty-much the same graph.

        exactly. though the WHOLE process makes it that there can be 3 different graphs which all could be completely correct in their RDM form.

        If you solely use the term 'OO', which is fuzzy at best, and you pick 3 random system architects, everyone using a different target platform/language and therefore are bound to the technical aspects of their target platform/language (platform == java/C++/Smalltalk etc. + RTL) you get 3 completely different class models which might be correct for their target platform/language. If you pick a dedicated platform and language, and do the same thing, and start from the conceptual analysis, you also end up with pretty much the same class models. So OO as a standalone term is ambiguous, hardly effectively usable, though if you're talking about real platforms/languages, and see that as an analogy of the RM in this, it's not ambigous anymore.

> > Which one is right? Which one is wrong? A matter of argumentation
> > and discussion, not something you can test with a hardened testsuit
> > you pull off the shelve. Is RM then an ambiguous technique?
>
> No. The conceptual analysis is the ambiguous part of the example,
> which is totally irrelevant to the RM.

        exactly. With OOAD, if you don't know the target platform/language and thus also not the technical details of these, it's IMHO impossible to design a class model which you can use to write your software, so 'OO' is too vague to be useful in this context. You too would agree on the fact that you can't design an RDM if you don't know what 'RM' is all about.

> > > > OO is just a way to organize code.
> > >
> > > Do you think everybody at comp.object agree?
> >
> > I'm certain not everyone agrees, also because it's irrelevant. This
> > isn't comp.OO
>
> When all the OO proponents at c.o agree on what object means, your
> response might begin to approach something valid. As it is, your
> reply was just meaningless handwaving.

        I don't see it that B/W. Dr. Chen defined 'Entity' years ago, still the term is also used in various contexts of which I think it has nothing to do with what Chen meant in the context in which he meant it. 'Object' is such a broad term, it more or less follows the same path as 'Entity' has followed and will follow.

        The thing is that even though for example C# and C++ have one fundamental element of OOP NOT in common, namely multiple implementation inheritance, you can still discuss object oriented development ideas and algorithms/patterns with eachother, as most of them arent tied to a 'language' but to the ideas behind OOAD.

        IMHO it's similar to that I can defined derived tables in postgresql but can't do that in sqlserver 2000. It has nothing to do with RM, but it has everything to do with the implementation of the constructed RM in a RDBMS.

                FB

        ps: I'm happy you avoided the insults so we could discuss things.

-- 
------------------------------------------------------------------------
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#) 
------------------------------------------------------------------------
Received on Wed Jun 28 2006 - 11:26:44 CEST

Original text of this message