Re: What databases have taught me

frebe73_at_gmail.com wrote:

> > > > > That's my point, most OO people claim that the query result
> > > > > should be mapped to a "domain objects".
> > > >
> > > > Correction: Most 'OO people' (whatever that means) who think
> > > > Domain Driven Design (DDD) is key to success. I'm not one of
> > > > them btw, and I'm sure a lot of others who happen to use an
> > > > OOPL to write their software with also think DDD is overdoing
> > > > things.
> > >
> > > So you agree that making classes like customer, employee, product
> > > is a bad idea?
> >
> > No, I find sticking every little method which consumes customer
> > data into the customer entity class a bad idea.
>
> I am a little bit confused here. First you say that you don't belong
> to the group of people thinking that domain objects should be used.
> But still you want to create a "customer" class? Maybe we have
> different definitions of "domain objects". Like everything else in
> OO, it is hard to debate because every word has different meanings.

        Erm... 'domain object' is associated with 'domain driven design (DDD)', so if you think that DDD == OOAD then that's not true, DDD is a way to design your class model, but you can also do that without DDD.

        For example 'customer' can also be a DTO without any behavior, and I can for example plug-in validation rules by a validator object (just an example).

        What I find so tiresome about this thread is that the same group of people keeps yapping about "What does OO mean" and related nonsense, and these questions all come down to silly wordgames. Several people in this thread have already mentioned that OOAD is about the IDEAS, not about a definition mentioned in some textbook, like RM perhaps also has a textual definition but RM is much much broader than that and also requires you to read up and understand the IDEAS behind it, which can span perhaps a whole book.

> > > I don't know how many times I have seen people at comp.object
> > > refusing to use any solution that doesn't hide database column
> > > names.
> >
> > that doesn't mean everyone from c.o thinks the same, like not
> > everyone in c.d.t. thinks the same about databases (otherwise there
> > wouldn't be any discussion ;))
>
> I am not a regular of c.d.t, so I don't know about that forum, but the
> lack of consensus regarding basic concepts is remarkable high in the
> OO community.

        erm... if you think every class which COULD represent an entity is a 'domain object', like you seem to suggest, who is lacking in the basic concept department, eh? ;)

        But I don't really care about wordgames, Fredrik. I also don't share your opinion about lack of consensus of basic concepts in the OO world. If I ask 100 random OOPL-using developer what a class is, what inheritance means and what polymorphism means, I won't get 100 different answers.

> Everything seem to be able to qualify as OO only if you
> skip the words table and record and name it object instead. You can
> even make a clone of SQL and name HQL, EJBQL, JDOQL and it will be
> accepted as a OO concept.

        no, that won't be an OO _concept_. OO concepts are inheritance, polymorphism etc. not the result of applying OO concepts in practise.

> > > The difference between the relational model and the OO model is
> > > that the relational model has a formal definition.
> >
> > you're talking about apples and oranges. it's great that the
> > relational model has a formal definition, but a DBA using mysql will
> > have to work hard to get it working in practise.
>
> Yes, tuning a database may be difficult, but anyway you will not have
> to change the application. The logical and physical concerns of a
> RDBMS are well separated. And normally, if the performance
> requirements are modest, tuning a RDBMS is not that hard.

        no I wasn't talking about tuning a database. I was talking about the severe lack of availability of RM elements in 'databases' like Mysql.

> > The "OO model" might
> > not have a mathematical based definition, that doesn't mean it's
> > therefore something not usable. The procedural model also doesn't
> > have a formal definition, so you would argue it's also not usable?
>
> That is why I don't use the words "procedural model". Anyway, every
> programming language has a formal definition (event OO languages). But
> the problem with the words "object orientation" is the it is so much
> more than a set of programming languages.

        that's why, for the gazillionth time, talking about what "OO" means, is pretty useless and won't give you any information. You should talk about what OOAD means, what an OOPL is etc. Hammering on and on what "OO" means and that it is so vague is what we call in holland "vragen naar de bekende weg.".

                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#) 
------------------------------------------------------------------------