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 http://perldesignpatterns.com/?TypedVariables, 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.

-scott

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.