in reply to Often Overlooked OO Programming Guidelines
I seriously disagree with the first section "useless OO". There is simpy no such thing as "useless OO".
When we look at this issue, we don't look at it from a programming point of view, but rather should look at it from a methodology point of view:
- Everything in the real world is an object (class is the collective abstraction of object).
- Programming is the way used to resolve real world problems.
- In order to be able to resolve the problem, especially through a machine, you need a way to (observe and ) describe the entities concerned, and the process to resolve the problem.
- OO is one way to describe real world (or to be precise, to perceive it and then describe it.)
The essential reason for the existance of objects is not for programming, but to descibe the world, however it helps programming. As long as an object matches an entity in the real world, the object has every reason to exist, and those reasons are beyond programming itself.
Acme::Playmate is not the best example for "useless OO". It is not even an example, and there is no example to prove there is useless OO.
On the contrary, to me, Acme::Playmate is a very good example of a simple object, and it encapsulates at least those three attributes you had in your sample code. Most importantly, the class does abstract an entity the author perceives. Whether it has any method other than the constructor can not be used to disqualify Acme::Playmate as a class (As those three attributes are by default exposed to outside world, there is no need for accessors, where there usually should be, and this is just due to the nature of the programming, and not really related to our discussion).
However there are cases, that objects are poorly defined and designed (the real world is perceived in a messy way, rather than a clear and precise way), but that's a different issue beyond this discussion.
For the rest of your note, you have given some very good tips on Perl OO programming. But I had a general observation that it is a mixture of two totally different aspects: programming skill and programming methodology. Sometime, the note intends to use programming skill to guide programming methodology, when the proper way is simply the opposite.