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.
    • 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 2 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 3 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 4 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 5 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.