----- 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! :)
>
> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
