While thinking about my reply to Appropriate amount of abstraction, I dug a little more into the Law of Demeter than I had previously. It occurs to me that Demeter shouldn't apply to object-relational mappers.

Relational databases are just that: relations. Crawling through multiple-table joins is normal in a reasonably complex database. When you translate these joins into an object-relational mapper like Class::DBI, these naturally break Demeter. But Demeter comes from the OO world, and joins come from the relational world. I don't think there is a good way to recincile these viewpoints that will satisify Demeter.

Of course, many say that object-relational mapping is a flawed idea, and this probably forms a good argument for that position.

Update: Minor spelling fix (s/mutiple/multiple/).

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Replies are listed 'Best First'.
Re: Law of Demeter and Class::DBI
by trammell (Priest) on Nov 15, 2004 at 17:48 UTC
[reply]
Re: Law of Demeter and Class::DBI
by itub (Priest) on Nov 15, 2004 at 17:14 UTC
    I would just consider the Law of Demeter as a good rule of thumb, and not worry too much about it.
[reply]
Re: Law of Demeter and Class::DBI
by fergal (Chaplain) on Nov 16, 2004 at 12:04 UTC
    The relational tool for demeter is the view. So you have 
    $o->thing1->thing2->thing3

    [download]
    and 
    SELECT thing2.thing3id FROM o, thing1, thing2 WHERE O.id= ? AND o.thin
+g1_id = thing1.id AND thing1.thing2id = thing2.id

    [download]
    being replaced with 
    $o->thing123

    [download]
    and 
    SELECT thing123id FROM view123 WHERE o.id = ?

    [download]

    A view allows you to reach across relations without having to explicitly traverse them. It's a bit different to a stored procedure in that it's easier to express and the DB understands what it does on a deeper level and is able to think about it and optimise. In most OO systems thing123 must be implemented like a stored procedure because the languages don't have a good way of expressing relationships. Once you're doing things the stored procedure way, the language no longer really understands what your doing and so it cannot be smart, it just has to follow your instructions to the letter, with the result that you are forced to write detailed instructions and more of them.

    In an OO language you end up with setters and getters because the language can't look inside thing123 to see that actually it's just ->thing1->thing2->thing3 and that it could use this for both the setter and the getter. Perl is different, it has lvalue subs. Lisp goes all the way with it's handling of getters, setters and macros, if you defined thing123 properly it is automatically both a getter and a setter and will interact nicely with all the other well defined getters and setters.

[reply]
[d/l]
[select]
      "In an OO language you end up with setters and getters because the language can't look"

      You get them because the developer put them in. Good OO code does not NEED getters and setters, but is merely code impersonating OO code. Not that non-OO code is wrong, but massive getter/setter combos are definitely wrong.

[reply]
        You haven't given any examples so I don't really understand what you're saying. Can you give me an example of good OO code that doesn't use getters and setters. Objects have fields (or properties or members). There needs to be a way to set and get them and it needs to be overrideable.

        In Perl for example, you can directly access the underlying hash. Are you saying that this is a good way of doing things?

        I'd say that's a bad way of doing things. This kind of code is tied to the underlying representation of the object and prevents you from reusing the code with other objects that would have had a compatible interface if you'd used getters and setters.

        By the way, when I say getters and setters I include things like Class::Accessor::Lvalue which lets you do 

        print $o->some_field;
$o->some_field = 5;

        [download]
        which gives a simple interface while still allowing override of get and set behaviour.
[reply]
[d/l]
Re: Law of Demeter and Class::DBI
by perrin (Chancellor) on Nov 22, 2004 at 22:20 UTC
    I often add methods to my Class::DBI code that perform some operation on multiple tables without the caller specifically needing to know that. There's no reason you have to expose the full underlying table structure just to use Class::DBI. Some would say Tangram does a better job of hiding this stuff though.
[reply]

Back to Meditations