in reply to Law of Demeter and Class::DBI

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.

Replies are listed 'Best First'.
Re^2: Law of Demeter and Class::DBI
by Anonymous Monk on Nov 16, 2004 at 18:22 UTC
    "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]
        I agree that accessing the underlying hash is a bad idea, but that's not the point. Among other things, OO is about putting the logic near the data.

        Let's say we want to indicate that a logger object should flush itself to disk when it's appropriate (it may take some time, so we can't do it right away). An example of not so good OO design: 

        #in a time sensitive loop
$logger->isFlushPending(1);

#later on
if($logger->isFlushPending) {
  $logger->flush();
  $logger->isFlushPending(0);
}

        [download]

        It's bad OO design to use getters to read the state of an object and then use that information to make decisions about how to use the object. The logic controlling the object is now located outside of the object rather than inside it.

        So you avoid the getters (asking the object what state it has) and instead tell the object what you want it to do and it can sort out how to do that itself. 

        #in a time sensitive loop
$logger->setFlushPending();

#later on
$logger->flushPending();

        [download]

        and the logic controlling whether to flush the log data to disk is now implemented in the flushPending() method. Inside the object, not outside.

        See also: TellDontAsk

        /J

[reply]
[d/l]
[select]

In Section Meditations