Re: •Re: OO Getters/Setters

[theAcolyte]

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

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

[linux454]

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.