On Oct 11, 2011, at 11:33 AM, John Napiorkowski wrote: > ----- Original Message ----- >> From: Steve <st...@matsch.com> >> To: Stevan Little <stevan.lit...@iinteractive.com> >> Cc: Moose ML <moose@perl.org>; John Napiorkowski <jjn1...@yahoo.com> >> Sent: Tuesday, October 11, 2011 11:19 AM >> Subject: Re: OO Design Principles/Patterns >> >> John and Stevan, >> >> Thank you both for your comments. This is pretty heady stuff for >> someone who went to college to get a business degree :) > > I have degrees in Philosophy, English and Performance Studies, so join the > Club! :)
No degree and barely 1.5 yrs towards a Fine Arts Painting BFA here, that whole CS thing is overrated :P >> I will definitely take a look at all the resources referenced, and offer >> one more that I stumbled across after my initial message: >> http://www.bryanesmith.com/documents/a2pm/design-patterns-03-16-2011.pdf. >> It is from a presentation given at a PM meeting in Ann Arbor, MI. >> Interestingly, of the five patterns described using Moose, (Singleton, >> Decorator, Adapter, Proxy, and Composite) there was no mention about the >> applicability of the pattern when using perl. That said, I do agree >> that some don't appear to be particularly relevant to our language of >> choice! >> >> Thanks again, >> Steve >> On 10/11/2011 10:01 AM, Stevan Little wrote: >>> 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>
