Re^5: Law of Demeter and Class::DBI

I largely agree* with the principle of Tell Don't Ask. It's basically saying that where possible you should not expose the field. This is fair enough but some objects require exposed fields. For example an Employee has a Salary field which you should be able to set and get. There's no way around that. The fact that it is a get/settable field is a fundamental part of the interface for an Employee.

What I'm saying is that in the situation where you must expose a field then it should be exposed in a way that allows you to control and customise the sets and gets and in Perl and most other languages that means having getters and setters.

The original post that I replied to said

Good OO code does not NEED getters and setters

The only way you can write OO code without getters and setters is to either have no fields or to have fields but access them directly. The first is impossible (applying Tell Don't Ask might give you less fields but can't eliminate them all) and the second is a bad idea as you said yourself.

* I think the idea of putting the logic beside the data is ok up to a point but I'm really starting to wish for good multimethods in Perl. In the example you gave, it's possible that your log flushing method would be useful for many types of object (basically any object that implemented isFlushPending and flush). So attaching it to a particular class means that all these objects which would find it useful will have to inherit from this class. This brings in the perils of multiple inheritance (perilous in most languages anyway).

Comment on Re^5: Law of Demeter and Class::DBI

Replies are listed 'Best First'.
Re^6: Law of Demeter and Class::DBI by jplindstrom (Monsignor) on Nov 20, 2004 at 12:34 UTC
Good point with the Salary field. That could be considered a part of the public interface of the Empoyee class. And querying the Salary or Name of an Employee in order to display them or something, that would be okay. But as soon as you start comparing the Salary with something else that was taken out from inside the object, you're losing cohesion. After I read about this the first time, I thought I'd try to follow the sentiment of the principle, and that has resulted in better designed OO code, without me doing much designing. It just falls out of the principle. The wiki page really states the principle so much more succinct than what I wrote above: "It is okay to use accessors to get the state of an object, as long as you don't use the result to make decisions outside the object." Something I've noticed is that sometimgs it's vague where a piece of logic belongs: which class should implement the method, taking a property from another object as a parameter. For example: "is the Employee's Salary above average in her Department?" Should that go in the Employee class, or the Department class? It depends on the rest of the design. /J	[reply]

Replies are listed 'Best First'.

Re^6: Law of Demeter and Class::DBI
by jplindstrom (Monsignor) on Nov 20, 2004 at 12:34 UTC

After I read about this the first time, I thought I'd try to follow the sentiment of the principle, and that has resulted in better designed OO code, without me doing much designing. It just falls out of the principle.

The wiki page really states the principle so much more succinct than what I wrote above: "It is okay to use accessors to get the state of an object, as long as you don't use the result to make decisions outside the object."

Something I've noticed is that sometimgs it's vague where a piece of logic belongs: which class should implement the method, taking a property from another object as a parameter.

For example: "is the Employee's Salary above average in her Department?" Should that go in the Employee class, or the Department class? It depends on the rest of the design.

[reply]