Front page | perl.moose |
Postings from October 2011
Re: OO Design Principles/Patterns
Thread Previous
From:
Stevan Little
Date:
October 11, 2011 08:45
Subject:
Re: OO Design Principles/Patterns
Message ID:
F86331C2-9292-42B9-86A3-55EEA9A594CB@iinteractive.com
On Oct 11, 2011, at 11:33 AM, John Napiorkowski wrote:
> ----- Original Message -----
>> From: Steve <steve@matsch.com>
>> To: Stevan Little <stevan.little@iinteractive.com>
>> Cc: Moose ML <moose@perl.org>; John Napiorkowski <jjn1056@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<steve@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
Thread Previous