The principle of encapsulation is that you want to localize assumptions about the internal implementation into one section with a well-defined and simple interface to the outside world. The point of that is so that you can change the implementation if you need to. (Part and parcel of this is that you don't expose any piece of functionality in your interface until you need it. After all the richer your interface, the harder it is to change the implementation.)
That does not mean that you intentionally choose an implementation you are likely to want to change. Given the fact that get/set methods are so much slower than direct access of attributes, unless you need the extra flexibility from the start of being able to override the implementation in subclasses, by default start with an implementation that is fast.
Another way to put it is design your program so that you can change your implementation at will (and make a practice of doing proactive tweaks from time to time just to keep you aware of things that you do which make those changes hard) but also try to find implementations that you don't think you will want to change...
In reply to Re (tilly) 4: Benchmarks: Costs of OO Perl
by tilly
in thread Dice::Die
by coreolyn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |