Re: OO Design Principles/Patterns

----- Original Message -----
> From: Steve <[email protected]>
> To: Stevan Little <[email protected]>
> Cc: Moose ML <[email protected]>; John Napiorkowski <[email protected]>
> 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! :)

> 
> 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<[email protected]>
>>>>  To: "[email protected]"<[email protected]>
>>>>  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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>