in reply to OO Getters/Setters

An object's interface to the "outside" is its methods. The methods should be thought out well, because refactoring and upward compatibility demand that those methods retain the same or better functionality over time when installing "plug-replacable" parts.

There are times when a method's natural implementation is to take a parameter and alter an instance variable directly, or to fetch an instance variable and return it with minimal fuss. For these, an automatically-constructed getter or setter is quite expedient.

But the blanket "give every instance variable a getter/setter" strategy is nearly always a sign that the coder is not yet "thinking objects", as you point out. Methods should be named by the "what" it does, and not "how" it gets done.

For example, consider a two-space point type, with a natural X and Y value for the addressing. I might initially create the traditional getter/setter for these two independent values. But let's say later that I discover that more often than not, I need these values as rho and theta in polar space, so I decide to change the internal representation to polar space. With separate X and Y setters, I have to perform more needless calculations as I update each one, where if I had just given an interface initially that only set both at once, my calculation burden would have been reduced.

Yes, there are holes in that example... that's just a quick thought. The point is that providing attribute-based setters instead of functional interfaces means you are bound to support an interface that may be expensive later when you change the design. I hope that's clear.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re: •Re: OO Getters/Setters
by theAcolyte (Pilgrim) on Jan 01, 2004 at 08:43 UTC

    Ok -- this makes more sense to me, but I'm going to restate in my own words, and if you have a second to let me know if I'm understanding, I'd appreciate it.

    Generic get/set methods can be bad - especially with anything more complicated then a piece of information that's unlikely to change.

    There's nothing inherently wrong with 

    $object->get("theIDData")

    [download]

    Except it isn't entirely object oriented in terms of thought process (what vs how), and that it limits you if you decide to make changes later. Example: if an object instance has an "id" attribute, you may someday want to take that id from, say, a database, and change it before you hand it back to the calling program, because there's a new ID structure in place, but the old database can't (for some mythical reason) be changed.

    So .. a simple ->get ->set set of methods can be appropriate, but only if you never expect to have to do any work with the data placed inside the object.

    I'm slowly getting my mind wrapped around the basics of OO with the help of this site, and all its tutorials. Thanks again for everyone's input.

    # Erik

[reply]
[d/l]
      I will offer this final piece of advise. Encapsulation is always your friend. Many would disagree, but my experience affirms this truth. Whether or not it is trivial encapsulation, it will save you from unforeseen headaches %99.9999 of the time. If you use the encapsulation that you've built within your object instead of direct member access, you can take advantage of the encapsulation within as without. Remember the goal of OOP is to bundle data with behavior, so that the rest of your code doesn't have to know the details. OOP is not just some convenient function access technique. Perl does lots of things well, but I think that it helps teach and propagate bad OOP habits. Some have argued here that creating trivial accessors/mutators is no different than making them public. Logically that is true, however, the difference will be seen on the maintenance side. If you start setting and getting values via the member variables (a.k.a attributes) now, sure they may be static, but now you have code spattered around that are using the members directly, and when the time comes that you want to update a persistence store, or calculate some value before presentation or persistence, you have a lot more code to change when you compare it with no code changes. I guess if it's a 5 line script that's not too bad, but if so why use objects? Remember objects aren't data structures, they're state machines. Would you want to cross wires just to change the channel on your tv? No, you want to use the remote. You want those attributes of managing the tv to be abstracted away from you. Then when you get a new tv, sure there might be more buttons, but the interface is the same.

      And in the "For What It's worth" department, the
      $obj->get("SomeKey");
      $obj->set("SomeKey", "some val");
      Notation makes me cringe, IMHO no encapsulation is better than that.

[reply]

In Section Seekers of Perl Wisdom