in reply to
Many books and tutorials have been written on using
objects in Perl, but as you said, you want to learn
OO design, not just OO syntax.
Most OO code is horrid. It completely misses the point
of writing OO code. It was tought incorrectly for decades,
resulting in vast quantities of truely wretched OO code.
Students see shining examples of OO principles, but when
they're put into the wildness of writing code, they can't
produce the same results. How to get from here to there is
lacking. Merely inheriting rather than cutting and pasting
was insufficient - the structure of code is still rigid,
and different implementations can't be easily swapped
out in favor of another during development or runtime.
The names of classes are still hardcoded into each
other. Things are abstracted, but the abstracted
interfaces are difficult to use, and the implementations
are horrid and gain little from being hidden. OO design is
just as, if not more, laiden with traps as any other
aspect of software engineering.
Starting with Java or Python would help. If you already
know Perl, then using the optional stricture might be
enough. Class::Contract on CPAN allows you specify
compile-time interface/implements relationships - a
key concept. Rough edges around the Perl object system
can be overcome with other modules as Object::Lexical
(blantent self plug number 1). Still, Perl has no type
safety unless you steal from
which might be useful for design and development, but should
probably be disabled for production. It is still only
run time. Normally, type safety (another corner stone
concept to OO design) is checked at compile time. This
is important, and makes sense if you realize that objects
are themselves types, and expecting the right species
of object and then getting it is critically important.
In fact, you can think of types and subtypes and
interfaces and so forth as sets. Set theory absolutely
applies to OO design.
To finally answer your question, I highly recommend
Object Oriented Design Heuristics. Perl Design Patterns itself (free online book, blantent self
plug #2) is heavily based on this text. Dispite its cliche
free name, I found it far superior to other, more trendy
OO texts, such as the namesake of Perl Design Patterns,
Design Patterns: Elements of Reusable bleah bleah bleah.
Taking this full circle, In My Humble Opinion, Refactoring,
Design Patterns, etc are finally OO design done right.
Applying known idioms, watching for tell tale signs to
know which idioms to implement, and stepwise moving away
from weak structures to stronger ones is the only way to
apply OO to a program that grows, gains features, or
isn't designed in minute detail before implementation begins.