On Oct 11, 2011, at 9:02 AM, John Napiorkowski wrote: >> From: Steve <st...@matsch.com> >> To: "moose@perl.org" <moose@perl.org> >> Sent: Tuesday, October 11, 2011 8:50 AM >> Subject: OO Design Principles/Patterns >> >> As someone who arrived somewhat late to the OO game, I have take every >> opportunity to learn some of the principles of OO design and use. I have >> been using Moose for a couple of years, primarily in the context of Catalyst >> and HTML::FormHandler. Lately though, I am studying the book 'Design >> Patterns - Elements of Reusable Object-Oriented Software', which comes >> highly recommended in OO land. >> >> I am wondering if anyone in the Moose community is: 1) aware of the book, 2) >> used the patterns with Moose, and 3) has taken time to write about >> implementing some of the patterns with Moose. >> >> The only thing I've seen referenced is how Moose 'almost' can be used to >> create an abstract class with roles. This might be good subject matter for >> a book on Moose! >> >> Steve >> > Dear Steve, > > I sorta started a project like this once, but got lazy and never got past > https://metacpan.org/release/Patterns-ChainOfResponsibility (not sure if that > is the most awesome example of the CoR pattern either) > > I think the thing was I started to think that those patterns, while > interesting, are not universally applicable to all languages and styles. For > example, a lot of the patterns seem to be to be how to make flexible code > when you are using a statically compiled languages. As a result I figured it > would be better to wait a few years and see just exactly how people use Moose > to good effect. Perhaps the community is starting to approach that critical > knowledge, although I doubt I have it! > > I guess even so, having such a thing would not be a bad exercise, and serve > as a good bit of advocacy as well as help form a bridge for programmers > coming from other languages. > > John
John, Actually, in the original book, several of the patterns were written in Smalltalk, which is a very dynamic language. However it is also an insanely strict OO-only language, so some things had to be invented in there. Steve, Mark Dominus has a great talk on this subject here ( http://perl.plover.com/yak/design/ ) I highly suggest you give it a read, it is pretty short but gets some good points across. In general the Perl community (and many of the other dynamic language communities) have decided that many of the original Gang of Four design patterns, while nice examples of OO design, are not relevant/necessary/useful as much when you are not writing in C++/C#/Java or Smalltalk. And in fact some people think (myself included) that several of the patterns exist due to (what we perceive as) deficiencies in the languages themselves ( http://en.wikipedia.org/wiki/Design_pattern_(computer_science)#Criticism ). For instance, the simplest and most often cited/used/abused pattern is the Iterator pattern. This is common in the Java standard libraries, is core to the language of C# and basically in Perl is written as: foreach my $item (@items) { ... } or map { ... } @items; Other commonly (ab)used patterns include - Singleton, which is really just a global variable by a different name in an attempt to make it acceptable (It also is a way to get around the lack of globals in Smalltalk if I recall correctly). - Abstract Factory, which is not terribly necessary in a language like Perl where you can simply do: my $classname = "Some::" . $thing; my $instance = $classname->new; - Decorator, actually I think Plack::Middleware is a great example of Decorator in action, and it barely uses any OO to do it, just anon-subroutines wrapping one another. - Interpreter, if I wanted to be a jerk, I could just say "eval", but that misses the point in some ways. However, the idea you should implement a complete language is really not acceptable in most situations either. - Memento, this is really just using Storable, it says "Without violating encapsulation" which Storable probably does, but at the interpreter level so while it might be cheating, its deep low level cheating :) - Lazy Initialization, this is built right into Moose Now, that said, other patterns are actually very useful and knowing the details of them and how others have written them will help you write them better. A short list of those would be: - Factory Method - Builder (which to some degree is just Dependency Injection) - Adapter - Facade - Command - Observer - Template method/Strategy - Visitor Others are just ill advised in my opinion, like: - State (changing behavior of a class based on internal state seems confusing to me) - Singleton (which I mentioned above) But in the end, it is important to recognize that Pattern != Library, these are not meant to be implemented and then be used from a library, they are guidelines to help you compose your larger OO design together using techniques which have already been vetted and assigned names and terminology. This gives you a common language that other people can more easily understand and get up to speed with. I have a quote from Christopher Alexander (the originator of Design Patterns (the architectural ones which the GoF took the idea from)), which is: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." I think this really captures the heart of design patterns and illustrates what so many people missed which was: "use this solution a million times over, without ever doing it the same way twice". And now it is time for my morning conference call, just made it :) - Stevan
