Loading ...
Sorry, an error occurred while loading the content.

(OTUG) How to use design patterns.

Expand Messages
  • rmartin@objectmentor.com
    There has recently been a conjecture placed on the extreme programming mail group that Design Patterns are harmful. The complaint is that designers try to
    Message 1 of 11 , Apr 27, 2001
    • 0 Attachment
      There has recently been a conjecture placed on the extreme programming
      mail group that Design Patterns are harmful. The complaint is that
      designers try to force patterns into a design rather than trying to
      determine the best structure for the design.

      I am sympathetic to this view. However I don't think design patterns
      are harmful. Indeed, I consider lack of knowledge of design patterns
      a mark of irresponsibility in a software professional. Design
      Patterns represent an invaluable body of knowledge that describes how
      past engineers have solved common problems. This cannot help but be
      of aid to future engineers facing those problems.

      Still, patterns are not a panacea. They do not solve all design
      problems. Nor do they represent a tool, method, or recipe for solving
      design problems. Rather they are simply descriptions of what has
      worked in a few situations in the past.

      How should designers employ design patterns? In my opinion they
      should not *try* to employ them at all. Rather designers need to
      become so intimately familiar with design patterns that they simply
      know when a given pattern fits into their design or not.

      This notion of "fit" is a tricky one. It is easy to face a design
      problem and leap to a pattern that solves it. But does that pattern
      provide a solution that is appropriate to the context? Or might there
      be a simpler solution?

      Design patterns should not be used in lieu of finding the best design.
      A designer might consider a particular pattern to help solve a
      problem; but should not assume that the pattern is the best solution.
      A pattern is not "best" simply because it is a pattern.

      One can view the choice of a pattern as a hypothesis: "I hypothesize
      that the observer pattern is a good solution to this problem." A good
      designer will then set about to choose a set of experiments that will
      verify this hypothesis. Those experiments are likely to be tiny
      stepwise implementations if test cases that, bit by bit, implement the
      problem to be solved. At any time during this implementation, the
      pattern should be viewed only as a vague direction, not as the law.
      And should the experiments show that the pattern is not optimal, the
      pattern should be abandoned.

      I have an article that demonstrates this technique appearing in my
      column in an upcoming Java Report.


      Robert C. Martin | "Uncle Bob" | Software Consultants
      Object Mentor Inc. | rmartin@... | We'll help you get
      PO Box 5757 | Tel: (800) 338-6716 | your projects done.
      565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
      Suite 135 | | www.XProgramming.com
      Vernon Hills, IL, | Training and Mentoring | www.junit.org
      60061 | OO, XP, Java, C++, Python|

      "One of the great commandments of science is:
      'Mistrust arguments from authority.'" -- Carl Sagan

      -----------------------------------------------------------------
      To unsubscribe from OTUG, send an email to majordomo@...
      with the word 'unsubscribe' in the body of the message.
    • Joshua Macy/Towers Perrin
      I find Design Patterns most useful in communication about the code, rather than in writing the code itself; patterns provide a consistent common vocabulary for
      Message 2 of 11 , May 1, 2001
      • 0 Attachment
        I find Design Patterns most useful in communication about the code, rather
        than in writing the code itself; patterns provide a consistent common
        vocabulary for talking about code at a higher level of abstraction than
        objects, methods, functions and the like. I would even agree that if you
        know (as in have fully internalized) many of the patterns found in Design
        Patterns, you are likely to be a good coder (or at least a better code than
        you were before you knew the patterns)--on the other hand, it seems to me
        that attempting to become a better coder by setting out to learn patterns
        from Design Patterns and to use them is much like attempting to become a
        better coder by setting out to learn jargon from the Jargon File and to use
        that. The high degree of correlation between the accumulated experience
        that makes the jargon second nature and good coding isn't the same as a
        cause and effect relationship between knowing the terms and being able to
        fluently use the concepts...

        Joshua
      • Gauti Thor Reynisson
        Joshua Macy: ...-on the other hand, it seems to me that attempting to become a better coder by setting out to learn patterns from Design Patterns and to use
        Message 3 of 11 , May 1, 2001
        • 0 Attachment
          Joshua Macy:

          "...-on the other hand, it seems to me
          that attempting to become a better coder by setting out to learn patterns
          from Design Patterns and to use them is much like attempting to become a
          better coder by setting out to learn jargon from the Jargon File and to use
          that."


          Being one of the "bad and inexperienced" coders of this planet (seriously),
          I'm trying to find a way to get better. Experience is good to have, but to
          me, it's a question of how should I get it. One of the things I did so far,
          was to attend to Joshua Kerievsky's Design Patterns course
          (www.industriallogic.com).

          I would say that this course opened up new perspectives in coding for me. I
          also realised that there are many ways in which you can "learn" patterns.
          You can sit down with the famous book and "study" it, OR you can read
          through it pattern by pattern, try to shoot holes in it, come up with
          possible situation where something like that pattern would be a good
          solution, come up with alternative solutions, contrast them etc. etc.

          My point is, there is a difference between "learning patterns" and "learning
          patterns". Patterns provide the vocabulary and ideas for beginners and the
          more experienced and I think we should rather be spending our time on
          finding out how we can learn more about those patterns.

          cheers,

          Gauti
        • Dan Palanza
          ... I take the above to mean that patterns are experientially learned; they are not learned vicariously. If that is consistent with Joshua s intent, then I
          Message 4 of 11 , May 1, 2001
          • 0 Attachment
            At 07:38 AM 5/1/01 -0400, Joshua Macy wrote:

            >I find Design Patterns most useful in communication about the code, rather
            >than in writing the code itself; patterns provide a consistent common
            >vocabulary for talking about code at a higher level of abstraction than
            >objects, methods, functions and the like. I would even agree that if you
            >know (as in have fully internalized) many of the patterns found in Design
            >Patterns, you are likely to be a good coder (or at least a better code than
            >you were before you knew the patterns)--on the other hand, it seems to me
            >that attempting to become a better coder by setting out to learn patterns
            >from Design Patterns and to use them is much like attempting to become a
            >better coder by setting out to learn jargon from the Jargon File and to use
            >that. The high degree of correlation between the accumulated experience
            >that makes the jargon second nature and good coding isn't the same as a
            >cause and effect relationship between knowing the terms and being able to
            >fluently use the concepts...

            I take the above to mean that patterns are experientially learned; they are
            not learned vicariously. If that is consistent with Joshua's intent, then I
            agree completely. Without shared experience among a discipline's users, a
            pattern is simply a metaphor with no body of supporting facts--words
            without deeds.

            Dan
          • Keith Nicholas
            I think this is well and good, however! There is three kinds of people we are addressing here, experienced developers who know design patterns, ,developers who
            Message 5 of 11 , May 1, 2001
            • 0 Attachment
              I think this is well and good, however!

              There is three kinds of people we are addressing here, experienced
              developers who know design patterns, ,developers who don't know design
              patterns but want to use them, cut'n'paste wannabe developers

              For people with experience in design patterns I think its important to
              follow the principles you outline. Its important to have a wide knowledge
              of patterns and personal experience so that you can make intelligent design
              choices based on the problem at hand.

              You then have the people who want to learn how to apply design patterns,
              work their way up the learning curve, etc. For these people I would say
              learn how to Refactor code first. Then look into design patterns, quite
              quickly you'll say "hey, I can apply XYZ pattern to this". I think this is
              not a bad thing, go ahead, try it, play with it, does it work? is it
              overkill? does it need modifying to better suit your needs? is it really the
              simplest thing you could of done? Refactor. Its ok to make mistakes while
              learning as long as you correct them and learn from them.

              The last lot of people who I don't think its really worth catering for
              (unless your an author then these people are GREAT) is the cut'n'pasters.
              These are the people that patch pre written code together without
              necessarily understanding it, they'll put in design patterns willy nilly,
              they are more concerned with an end result and trying to rely on other
              peoples design decisions to solve their problems. They are less concerned
              with becoming a good designer.



              Keith Nicholas

              > -----Original Message-----
              > From: owner-otug@... [mailto:owner-otug@...]On Behalf
              > Of rmartin@...
              > Sent: Saturday, April 28, 2001 7:53 AM
              > To: extremeprogramming@yahoogroups.com; otug@...
              > Subject: [XP] (OTUG) How to use design patterns.
              >
              >
              > There has recently been a conjecture placed on the extreme programming
              > mail group that Design Patterns are harmful. The complaint is that
              > designers try to force patterns into a design rather than trying to
              > determine the best structure for the design.
              >
              > I am sympathetic to this view. However I don't think design patterns
              > are harmful. Indeed, I consider lack of knowledge of design patterns
              > a mark of irresponsibility in a software professional. Design
              > Patterns represent an invaluable body of knowledge that describes how
              > past engineers have solved common problems. This cannot help but be
              > of aid to future engineers facing those problems.
              >
              > Still, patterns are not a panacea. They do not solve all design
              > problems. Nor do they represent a tool, method, or recipe for solving
              > design problems. Rather they are simply descriptions of what has
              > worked in a few situations in the past.
              >
              > How should designers employ design patterns? In my opinion they
              > should not *try* to employ them at all. Rather designers need to
              > become so intimately familiar with design patterns that they simply
              > know when a given pattern fits into their design or not.
              >
              > This notion of "fit" is a tricky one. It is easy to face a design
              > problem and leap to a pattern that solves it. But does that pattern
              > provide a solution that is appropriate to the context? Or might there
              > be a simpler solution?
              >
              > Design patterns should not be used in lieu of finding the best design.
              > A designer might consider a particular pattern to help solve a
              > problem; but should not assume that the pattern is the best solution.
              > A pattern is not "best" simply because it is a pattern.
              >
              > One can view the choice of a pattern as a hypothesis: "I hypothesize
              > that the observer pattern is a good solution to this problem." A good
              > designer will then set about to choose a set of experiments that will
              > verify this hypothesis. Those experiments are likely to be tiny
              > stepwise implementations if test cases that, bit by bit, implement the
              > problem to be solved. At any time during this implementation, the
              > pattern should be viewed only as a vague direction, not as the law.
              > And should the experiments show that the pattern is not optimal, the
              > pattern should be abandoned.
              >
              > I have an article that demonstrates this technique appearing in my
              > column in an upcoming Java Report.
              >
              >
              > Robert C. Martin | "Uncle Bob" | Software Consultants
              > Object Mentor Inc. | rmartin@... | We'll help you get
              > PO Box 5757 | Tel: (800) 338-6716 | your projects done.
              > 565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
              > Suite 135 | | www.XProgramming.com
              > Vernon Hills, IL, | Training and Mentoring | www.junit.org
              > 60061 | OO, XP, Java, C++, Python|
              >
              > "One of the great commandments of science is:
              > 'Mistrust arguments from authority.'" -- Carl Sagan
              >
              > -----------------------------------------------------------------
              > To unsubscribe from OTUG, send an email to majordomo@...
              > with the word 'unsubscribe' in the body of the message.
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              > extremeprogramming-unsubscribe@...
              >
              > Don't miss XP UNIVERSE, the first US conference on XP and Agile
              > Methods. Early registration discounts EXTENDED until May 1,
              > 2001. www.xpuniverse.com for details and registration.
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >
              >
              >
            • Robert C. Martin
              ... Touche! I agree that it may not be easy for the median software developer to Leap to the pattern that solves a problem. I agree that folks need to
              Message 6 of 11 , May 2, 2001
              • 0 Attachment
                > -----Original Message-----
                > From: Joshua Kerievsky [mailto:joshua@...]
                > Sent: Monday, April 30, 2001 9:18 PM
                > To: extremeprogramming@yahoogroups.com
                > Subject: Re: [XP] (OTUG) How to use design patterns.
                >
                >
                > >This notion of "fit" is a tricky one. It is easy to face a design
                > >problem and leap to a pattern that solves it. But does that pattern
                > >provide a solution that is appropriate to the context? Or
                > might there
                > >be a simpler solution?
                >
                > Easy for whom, Bob? An OO expert? Most folks who are hired
                > to program on
                > projects these days barely know one pattern, and it's usually
                > Singleton.

                Touche! I agree that it may not be easy for the median software developer
                to "Leap" to the pattern that solves a problem. I agree that folks need to
                learn those patterns and internalize them. I think the ability to "Leap" to
                the pattern that solves a problem is a good thing.

                Leaping, on the other hand, is a different matter. The more mature a
                developer becomes, the more patterns will suggest themselves for every
                different design problem. Indeed, we have all seen designs done by over
                enthusiastic leapers; and they are filled with patterns from stem to stern.
                The designer has done too much leaping and not enough careful discerning.

                In the end, we must value both the ability to leap, and the courage not to
                leap.

                Robert C. Martin | "Uncle Bob" | Software Consultants
                Object Mentor Inc. | rmartin@... | We'll help you get
                PO Box 5757 | Tel: (800) 338-6716 | your projects done.
                565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
                Suite 135 | | www.XProgramming.com
                Vernon Hills, IL, | Training and Mentoring | www.junit.org
                60061 | OO, XP, Java, C++, Python|

                "One of the great commandments of science is:
                'Mistrust arguments from authority.'" -- Carl Sagan
              • Robert C. Martin
                ... The way I teach patterns to my students is to derive them step by step from the problem and environment. This is an interesting excersize because it makes
                Message 7 of 11 , May 2, 2001
                • 0 Attachment
                  > -----Original Message-----
                  > From: Gauti Thor Reynisson [mailto:gautithor.reynisson@...]

                  > I also realised that there are many ways in which you can
                  > "learn" patterns.
                  > You can sit down with the famous book and "study" it, OR you can read
                  > through it pattern by pattern, try to shoot holes in it, come up with
                  > possible situation where something like that pattern would be a good
                  > solution, come up with alternative solutions, contrast them etc. etc.

                  The way I teach patterns to my students is to derive them step by step from
                  the problem and environment. This is an interesting excersize because it
                  makes you realize that the pathway to a pattern is composed of many tiny
                  steps; each one of which represents an improvement to the design of the
                  code. You also realize that each one of those micro steps could be a
                  stopping point if the environmental forces are satisfied.

                  I have an article about this in an upcoming Java Report issue.

                  Robert C. Martin | "Uncle Bob" | Software Consultants
                  Object Mentor Inc. | rmartin@... | We'll help you get
                  PO Box 5757 | Tel: (800) 338-6716 | your projects done.
                  565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
                  Suite 135 | | www.XProgramming.com
                  Vernon Hills, IL, | Training and Mentoring | www.junit.org
                  60061 | OO, XP, Java, C++, Python|

                  "One of the great commandments of science is:
                  'Mistrust arguments from authority.'" -- Carl Sagan
                • Joshua Kerievsky
                  ... Well said, Bob. ... It always comes down to paradox doesn t it. :-) regards jk _______________________________ Industrial Logic, Inc. Joshua Kerievsky,
                  Message 8 of 11 , May 2, 2001
                  • 0 Attachment
                    >Leaping, on the other hand, is a different matter. The more mature a
                    >developer becomes, the more patterns will suggest themselves for every
                    >different design problem. Indeed, we have all seen designs done by over
                    >enthusiastic leapers; and they are filled with patterns from stem to stern.
                    >The designer has done too much leaping and not enough careful discerning.

                    Well said, Bob.

                    >In the end, we must value both the ability to leap, and the courage not to
                    >leap.

                    It always comes down to paradox doesn't it. :-)

                    regards
                    jk


                    _______________________________
                    Industrial Logic, Inc.
                    Joshua Kerievsky, founder
                    mailto:joshua@...
                    http://industriallogic.com
                    415-292-6266
                    415-292-6267 (fax)
                  Your message has been successfully submitted and would be delivered to recipients shortly.