The O'Reilly network is starting a series on Perl Design Patterns

...many of the problems the GoF is trying to solve are better solved in Perl-specific ways, using techniques not open to Java developers or those C developers who insist on using only objects.
That is so true. In particular doing the structural patterns (and associated behavioral ones) in pure GoF style is completely wrong when a dynamic language with open class implementations is available.
I remember reading about double dispatch problems and realizing that contrived calls through two class hierarchies are irrelevant due to perl's dynamic inheritance model: There is no static type, so methods are dispatched to the dynamic type of an object even if that type was unknown to the calling context.
If you need more control use Conway's multimethods.