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

Re: [XP] YAGNI & MVC

Expand Messages
  • mstriebeck@vasoftware.com
    Hi Dave, we are trying to solve such arguments (and we have them too) with our overall architecture and standards. If it is your standard to implement your
    Message 1 of 17 , Jun 28, 2003
    • 0 Attachment
      Hi Dave,

      we are trying to solve such arguments (and we have them too) with our overall
      architecture and standards.

      If it is your standard to implement your frontend as MVC components, then
      everyone should stick to that (otherwise you end up with a non-normalized
      architecture).

      The decision to standardaze on MVC (or any other pattern) should be YAGNI. Don't
      start using them just because it seems to be the right thing. There should be
      good reasons (complexity, number of pages, ...) to use such a pattern.

      MarkS

      Dave Jones wrote:

      >Hi,
      >I'm enjoying the ongoing conversations debating the merits of
      >YAGNI in various situations and contexts. Reading these various
      >points of view is helping me better understand how to 'think'
      >YAGNI in approaching design and development.
      >
      >One basic question occurs to me. I'd like to understand how YAGNI
      >proponents reconcile YAGNI with MVC. For example, say I need to
      >add a new report to a web application. The fastest and most
      >direct way to do this is to put everything into a JSP, with the
      >queries and any prelim code at the top and scriptlets scattered thru the page.
      >
      >The MVC approach says adding a new page requires building an
      >action servlet and associated bean, adding the necessary XML
      >associations, then building the light-weight JSP.
      >
      >Does YAGNI make certain assumptions about the environment, such
      >as MVC, and then operates in the leanest fashion within that
      >environment? So in the example above, it says to build the
      >simplest report possible (using MVC) that fully meets the
      >client's requirements (and no more)?
      >
      >Or, does YANGI always start with a clean slate, making no
      >assumptions and always striving for the simplest solution? So in
      >the above example, it says to build the report as a JSP and only
      >later should the need arise to apply MVC to the application would
      >the application be refactored to use MVC?
      >
      >I look forward to hearing the comments of more experienced YAGNI
      >practitioners on this.
      >
      >Thanks,
      >Dave Jones
      >NetEffect
      >
      >
      >To Post a message, send it to: extremeprogramming@...
      >
      >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      >ad-free courtesy of objectmentor.com
      >
      >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
    • Jeff Grigg
      ... Right. Start the project knowing what MVC is, how it s done, and how it can help you. But don t do it... yet. A page or two into the project, you can
      Message 2 of 17 , Jun 28, 2003
      • 0 Attachment
        --- mstriebeck@v... wrote:
        > we are trying to solve such arguments (and we have them too)
        > with our overall architecture and standards.
        >
        > [...]
        >
        > The decision to standardaze on MVC (or any other pattern)
        > should be YAGNI. Don't start using them just because it
        > seems to be the right thing. There should be good reasons
        > (complexity, number of pages, ...) to use such a pattern.

        Right. Start the project knowing what MVC is, how it's done, and
        how it can help you. But don't do it... yet.

        A page or two into the project, you can start saying, "Ewwww! This
        STINKS!" when you look at a JSP page and see Java code. Refactor,
        keeping MVC in mind.

        If you're building an application that will benefit from MVC, you'll
        get there. You just don't have to start there.


        > Dave Jones wrote:
        >>One basic question occurs to me. I'd like to understand how YAGNI
        >>proponents reconcile YAGNI with MVC. For example, say I need to
        >>add a new report to a web application. The fastest and most
        >>direct way to do this is to put everything into a JSP, with the
        >>queries and any prelim code at the top and scriptlets scattered
        >>thru the page.

        "Ick. That stinks."
        That means that you need to refactor.

        Write the page to make it work. It's OK to write "bad code." Once
        the tests pass, refactor to standard. Don't tolerate "bad code."


        >>Does YAGNI make certain assumptions about the environment, such
        >>as MVC, and then operates in the leanest fashion within that
        >>environment? [...]
        >>
        >>Or, does YANGI always start with a clean slate, making no
        >>assumptions and always striving for the simplest solution? So in
        >>the above example, it says to build the report as a JSP and only
        >>later should the need arise to apply MVC to the application would
        >>the application be refactored to use MVC?

        My experience is that when doing Test Driven Development,
        implementing functionality with independently testable modules is
        the easiest way to do it. It's more classes and interfaces, but
        it's a lot easier to test. So it is the simplest thing that could
        possibly work -- within the framework that you must follow Test
        Driven Development rules.
      • Phlip
        ... I have this friend who is a rabid slavering XP zealot. He claims if you go in not
        Message 3 of 17 , Jun 28, 2003
        • 0 Attachment
          > A page or two into the project, you can start saying, "Ewwww! This
          > STINKS!" when you look at a JSP page and see Java code. Refactor,
          > keeping MVC in mind.

          I have this friend who is a rabid slavering XP zealot.

          He claims if you go in >not< thinking of any given pattern, duplication
          removal will force the correct one to emerge.

          So, given a business model and a GUI model, removing duplication among all
          the custom calls to update each other's state creates the Observer Design
          Pattern, and that the least duplicitous arrangement lets logic variables
          directly observe GUI variables, without intervening dispatchers or "switch"
          statements. So MVC (and its three-way decoupling) emerge spontaneously.

          My friend claims to have >done< all that once, too!

          I need to upgrade my friend set...

          --
          Phlip
          http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
        • yahoogroups@jhrothjr.com
          ... From: Phlip To: extremeprogramming@yahoogroups.com
          Message 4 of 17 , Jun 28, 2003
          • 0 Attachment
            ----- Original Message -----
            From: "Phlip" <plumlee.at.systransoft.com@...>
            To: "extremeprogramming@yahoogroups.com"
            <extremeprogramming.at.yahoogroups.com@...>
            Sent: Saturday, June 28, 2003 6:17 PM
            Subject: Re: [XP] YAGNI & MVC


            > > A page or two into the project, you can start saying, "Ewwww! This
            > > STINKS!" when you look at a JSP page and see Java code. Refactor,
            > > keeping MVC in mind.
            >
            > I have this friend who is a rabid slavering XP zealot.
            >
            > He claims if you go in >not< thinking of any given pattern, duplication
            > removal will force the correct one to emerge.
            >
            > So, given a business model and a GUI model, removing duplication among all
            > the custom calls to update each other's state creates the Observer Design
            > Pattern, and that the least duplicitous arrangement lets logic variables
            > directly observe GUI variables, without intervening dispatchers or
            "switch"
            > statements. So MVC (and its three-way decoupling) emerge spontaneously.
            >
            > My friend claims to have >done< all that once, too!
            >
            > I need to upgrade my friend set...

            When are we going to see the article? You promised [whine...]

            John Roth
            >
            > --
            > Phlip
            > http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
            >
          • Phlip
            ... Not that I remember promising anything... (Love those automated tests, remembering things for me, though!) But I promise there s one in the oven! ... --
            Message 5 of 17 , Jun 28, 2003
            • 0 Attachment
              > When are we going to see the article? You promised [whine...]
              >
              > John Roth

              Not that I "remember" promising anything... (Love those automated tests,
              remembering things for me, though!)

              But I promise there's one in the oven!

              > > http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

              --
              Phlip
            • Jeff Grigg
              ... Yes, it s been a controversial topic. As you can tell, I m on the side of knowing patterns is good. I recall a meeting, some years ago, where we were
              Message 6 of 17 , Jun 29, 2003
              • 0 Attachment
                >> A page or two into the project, you can start saying,
                >> "Ewwww! This STINKS!" when you look at a JSP page and
                >> see Java code. Refactor, keeping MVC in mind.

                --- "Phlip" <plumlee@s...> wrote:
                > I have this friend who is a rabid slavering XP zealot.
                >
                > He claims if you go in >not< thinking of any given pattern,
                > duplication removal will force the correct one to emerge.
                >
                > [...], removing duplication [...]. So MVC (and its three-way
                > decoupling) emerge spontaneously.
                >
                > My friend claims to have >done< all that once, too!

                Yes, it's been a controversial topic. As you can tell, I'm on the
                side of "knowing patterns is good."

                I recall a meeting, some years ago, where we were implementing a
                Composite and we were disturbed by the amount of use-specific code
                we had to put in it. We talked about it within the team: The code
                had obvious smells, but we couldn't immediately think of any
                sensible way of avoiding them. A few months later I read about the
                Visitor pattern. Darn. "If only we had known..."


                I say that one's ability to detect and fix smells depends on your
                knowledge. Knowledge is good.

                Others emphasize the danger of misusing your knowledge. I don't
                think that encouraging ignorance is the best solution to that
                problem. ;->
              • Ron Jeffries
                ... Yes. Knowing and thinking is good. Refactor towards patterns when the code wants to go that way. Ron Jeffries www.XProgramming.com A lot of preconceptions
                Message 7 of 17 , Jun 29, 2003
                • 0 Attachment
                  On Sunday, June 29, 2003, at 8:17:05 AM, Jeff Grigg wrote:

                  > Others emphasize the danger of misusing your knowledge. I don't
                  > think that encouraging ignorance is the best solution to that
                  > problem. ;->

                  Yes. Knowing and thinking is good. Refactor towards patterns when the code
                  wants to go that way.

                  Ron Jeffries
                  www.XProgramming.com
                  A lot of preconceptions can be dismissed when you actually
                  try something out. -- Bruce Eckel
                • Curtis Cooley
                  ... This reminds me of the discussion I was in at Agile Universe on Are Design Patterns Dead? Personally I thought Martin Fowler had put this topic to rest
                  Message 8 of 17 , Jul 1, 2003
                  • 0 Attachment
                    On Sun, 2003-06-29 at 16:30, Ron Jeffries wrote:
                    > On Sunday, June 29, 2003, at 8:17:05 AM, Jeff Grigg wrote:
                    >
                    > > Others emphasize the danger of misusing your knowledge. I don't
                    > > think that encouraging ignorance is the best solution to that
                    > > problem. ;->
                    >
                    > Yes. Knowing and thinking is good. Refactor towards patterns when the code
                    > wants to go that way.
                    >
                    This reminds me of the discussion I was in at Agile Universe on "Are
                    Design Patterns Dead?" Personally I thought Martin Fowler had put this
                    topic to rest with his paper of the same name, but apparently there are
                    those that still need to talk about it.

                    I know Ron has wondered what would happen if all you paid attention to
                    were the simplicity rules. Especially tolerate no duplication and reveal
                    all intent. Others claim you must arrive at a pattern before hand.

                    I don't think everyone had thought and wondered enough about the
                    interesting orthogonality that can exist between removing duplication
                    and revealing intent. If all you really paid attention to was removing
                    duplication and revealing intent, and you really really really tried to
                    do both, you would soon discover that a pattern exists that will help
                    you do both.

                    I've often wondered which one was more important because I thought there
                    just had to be situations where you could not possibly do both.
                    Something Ron said last week made me realize that you can and must do
                    both. I wish I could remember what it was.

                    So, yes, knowing design patterns and knowing about design principles is
                    very important to being a good developer because there will be times
                    where you will have to be very creative in removing duplication and
                    knowing design patterns and design principles will help you remove the
                    duplication without hiding the intent. And that's what keeping it simple
                    is all about.

                    --
                    ======================
                    Curtis R Cooley
                    RADSoft
                    Better software faster
                    curtis@...
                    ----------------------
                    Dr. Zoidberg: "Okay, so you're nonchalant, stop rubbing our noses in it.
                  • Pieter Nagel
                    ... I look at it this way: suppose you pick up a patterns book and want to judge for yourself whether it is snakeoil or not. What do you do? You judge each
                    Message 9 of 17 , Jul 2, 2003
                    • 0 Attachment
                      On Tue, Jul 01, 2003 at 02:53:01PM -0700, Curtis Cooley wrote:

                      > I know Ron has wondered what would happen if all you paid attention to
                      > were the simplicity rules. Especially tolerate no duplication and reveal
                      > all intent. Others claim you must arrive at a pattern before hand.

                      I look at it this way: suppose you pick up a patterns book and want to
                      judge for yourself whether it is snakeoil or not. What do you do? You
                      judge each pattern you read from first principles. And those first
                      principles are, IMHO, much the same as XP's rules about no duplication,
                      simplicity and revealing intent.

                      So, if you just apply the simplicity rules, you might end up at a known
                      pattern, because both you and the pattern guys are often trying to solve
                      the same problem. Conversely, often you can take a pattern off the shelf
                      to help you with the simplicity rules.

                      --
                      ,_
                      /_) /| /
                      / i e t e r / |/ a g e l
                      http://www.nagel.co.za
                    • Joshua Kerievsky
                      ... I so love to argue with Ron about this subject that I must jump in here (and procrastinate from finishing Refactoring to Patterns). So, I refactor *to* a
                      Message 10 of 17 , Jul 2, 2003
                      • 0 Attachment
                        >>Others emphasize the danger of misusing your knowledge. I don't
                        >>think that encouraging ignorance is the best solution to that
                        >>problem. ;->
                        >
                        >
                        > Yes. Knowing and thinking is good. Refactor towards patterns when the code
                        > wants to go that way.

                        I so love to argue with Ron about this subject that I must jump in here
                        (and procrastinate from finishing Refactoring to Patterns).

                        So, I refactor *to* a Template Method when my code wants to go that way.
                        I refactor *to* Null Object when my code wants to go that way. Those
                        are cases of to, not towards. There are also cases when I go towards
                        and not "to." I experiment with a refactoring towards Decorator and
                        discover it's overkill - I rewind, think a bit and then refactor in
                        another direction. Yes. Knowing and thinking is good. And knowing
                        when to refactor all the way to a pattern is part of being a good
                        refactorer. Agreed? ;-)

                        best regards,
                        jk
                      • mstriebeck@vasoftware.com
                        So, if you always start with VERY simple design and refactor to / towards a pattern, at which point would you actually use an available library/tool/module.
                        Message 11 of 17 , Jul 2, 2003
                        • 0 Attachment
                          So, if you always start with VERY simple design and refactor to / towards a
                          pattern, at which point would you actually use an available library/tool/module.

                          Let's take the example of Struts:

                          - I could start with a very simple design, refactor, come to an MVC-like
                          implementation and the at some point realize that I maintain too much code
                          myself and kick my code out and replace with Struts.

                          - If I know that my application will get fairly complex and that I will end up
                          that route anyway (just assume that I did a similar project before) what would
                          be wrong to start with Struts right away. Wouldn't that save time in the end? I
                          would put that under good usage of knowledge and experience.

                          MarkS

                          Quoting Joshua Kerievsky <joshua@...>:

                          > >>Others emphasize the danger of misusing your knowledge. I don't
                          > >>think that encouraging ignorance is the best solution to that
                          > >>problem. ;->
                          > >
                          > >
                          > > Yes. Knowing and thinking is good. Refactor towards patterns when the
                          > code
                          > > wants to go that way.
                          >
                          > I so love to argue with Ron about this subject that I must jump in here
                          > (and procrastinate from finishing Refactoring to Patterns).
                          >
                          > So, I refactor *to* a Template Method when my code wants to go that way.
                          > I refactor *to* Null Object when my code wants to go that way. Those
                          > are cases of to, not towards. There are also cases when I go towards
                          > and not "to." I experiment with a refactoring towards Decorator and
                          > discover it's overkill - I rewind, think a bit and then refactor in
                          > another direction. Yes. Knowing and thinking is good. And knowing
                          > when to refactor all the way to a pattern is part of being a good
                          > refactorer. Agreed? ;-)
                          >
                          > best regards,
                          > jk
                          >
                          >
                          > To Post a message, send it to: extremeprogramming@...
                          >
                          > To Unsubscribe, send a blank message to:
                          > extremeprogramming-unsubscribe@...
                          >
                          > ad-free courtesy of objectmentor.com
                          >
                          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                          >
                          >
                          >
                        • Ron Jeffries
                          ... If during our refactoring, the forces do not change substantially, then refactoring in the direction of the pattern will get us there. If we refactor all
                          Message 12 of 17 , Jul 2, 2003
                          • 0 Attachment
                            On Wednesday, July 2, 2003, at 10:59:33 PM, Joshua Kerievsky wrote:

                            >> Yes. Knowing and thinking is good. Refactor towards patterns when the code
                            >> wants to go that way.

                            > I so love to argue with Ron about this subject that I must jump in here
                            > (and procrastinate from finishing Refactoring to Patterns).

                            > So, I refactor *to* a Template Method when my code wants to go that way.
                            > I refactor *to* Null Object when my code wants to go that way. Those
                            > are cases of to, not towards. There are also cases when I go towards
                            > and not "to." I experiment with a refactoring towards Decorator and
                            > discover it's overkill - I rewind, think a bit and then refactor in
                            > another direction. Yes. Knowing and thinking is good. And knowing
                            > when to refactor all the way to a pattern is part of being a good
                            > refactorer. Agreed? ;-)

                            If during our refactoring, the forces do not change substantially, then
                            refactoring in the direction of the pattern will get us there. If we
                            refactor all the way to the pattern without reassessing the forces along
                            the way, that seems fraught to me. If we reassess the forces and they are
                            now pointing in another direction, what should we do?

                            Seems to me that going from an unknown starting location all the way to a
                            pattern is likely to be a big bite, and likely to be suboptimal. If it is
                            optimal to go all the way there, going incrementally will still get us
                            there.

                            But what do I know? Practically nothing.

                            Ron Jeffries
                            www.XProgramming.com
                            Maybe it is like green shoes. Interesting, but not sought after. -- Dick Jeffries
                          • William Pietri
                            ... I have recently tried both routes on different projects. For Struts in particular, my feeling is that you have programmers who are solid enough to build
                            Message 13 of 17 , Jul 2, 2003
                            • 0 Attachment
                              On Wed, 2003-07-02 at 20:18, mstriebeck@... wrote:
                              > So, if you always start with VERY simple design and refactor to / towards a
                              > pattern, at which point would you actually use an available library/tool/module.
                              >
                              > Let's take the example of Struts:
                              >
                              > - I could start with a very simple design, refactor, come to an MVC-like
                              > implementation and the at some point realize that I maintain too much code
                              > myself and kick my code out and replace with Struts.
                              >
                              > - If I know that my application will get fairly complex and that I will end up
                              > that route anyway (just assume that I did a similar project before) what would
                              > be wrong to start with Struts right away. Wouldn't that save time in the end? I
                              > would put that under good usage of knowledge and experience.

                              I have recently tried both routes on different projects.

                              For Struts in particular, my feeling is that you have programmers who
                              are solid enough to build the framework organically, that's a better
                              route.

                              Struts touches the rest of my code in a number of places, and even
                              mediates between my components. This makes it very hard to isolate
                              effectively, so there are some Struts architectural issues that we're
                              stuck with for now. It also has a relatively steep learning curve for my
                              tastes.

                              When I rolled my own it was a little frustrating at first, but I think
                              the code and config files for that project are much more expressive. I
                              also had a much better grip on what was going on; with struts, we often
                              have moments of bafflement.


                              On the other hand, there are some places I'm very happy we used external
                              libraries. If you have to use a relational database, Hibernate is pretty
                              swell, and you can wrap it pretty completely so that if you want to swap
                              it out for some other O/R mapper, it should be pretty easy.

                              I think the same applies to XML parsers, encryption code, regexp
                              engines, and some of the Apache Commons stuff. All of that is discrete,
                              isolateable, and relatively easy to replace if it turns out to be not
                              what I need.


                              So I'd say that the judgment should be made on a case-by-case basis, but
                              that people should be wary, especially where the external framework
                              forces you into a certain architecture.

                              William

                              --
                              brains for sale: http://scissor.com/
                            • Joshua Kerievsky
                              ... Sometimes refactorings make code uglier before further refactorings can the code pretty again. What do you reassess when that happens? Or is your code
                              Message 14 of 17 , Jul 2, 2003
                              • 0 Attachment
                                Ron Jeffries wrote:

                                >If during our refactoring, the forces do not change substantially, then
                                >refactoring in the direction of the pattern will get us there. If we
                                >refactor all the way to the pattern without reassessing the forces along
                                >the way, that seems fraught to me. If we reassess the forces and they are
                                >now pointing in another direction, what should we do?
                                >
                                Sometimes refactorings make code uglier before further refactorings can
                                the code pretty again. What do you reassess when that happens?
                                Or is your code somehow always pretty when you refactor?

                                >Seems to me that going from an unknown starting location all the way to a
                                >pattern is likely to be a big bite, and likely to be suboptimal. If it is
                                >optimal to go all the way there, going incrementally will still get us
                                >there.
                                >
                                >
                                The two examples I mentioned, refactoring to Tempate Method and
                                refactoring to Null Object, both of which come from Martin's Refactoring
                                book, each contain mechanics that show how to refactor to those
                                patterns. Those mechanics direct one to take small steps -- called
                                refactorings -- to get to an end point, a pattern. No big bites,
                                nothing sub-optimal. We take small steps and keep our bar green. It's
                                possible to stop mid-way , go backwards or go forwards and all the way
                                to a pattern. You keep thinking and experimenting as you go.

                                The birthplace of every pattern is in the act of refactoring. When
                                people loose touch with the birthplace of a pattern, they often misuse
                                it. So I like to have folks re-live the birthing of a pattern. I do
                                that by showing them the refactorings that led up to the end result, the
                                pattern. It's all in the name of getting better and learning how to
                                make our code solid, small, simple and straightforward.

                                regards,
                                jk
                              • Joshua Kerievsky
                                ... Yes, Hibernate is nice. We talked about using it on a project here in Berkeley. We are likely to use it at some point. Yet we ve been coding for a week
                                Message 15 of 17 , Jul 2, 2003
                                • 0 Attachment
                                  William Pietri wrote:

                                  >On the other hand, there are some places I'm very happy we used external
                                  >libraries. If you have to use a relational database, Hibernate is pretty
                                  >swell, and you can wrap it pretty completely so that if you want to swap
                                  >it out for some other O/R mapper, it should be pretty easy.
                                  >
                                  Yes, Hibernate is nice. We talked about using it on a project here in
                                  Berkeley. We are likely to use it at some point. Yet we've been coding
                                  for a week and a half and still haven't found we need it. We do some
                                  simple JDBC, talk to an rdb and build some domain objects. Nothing
                                  fancy, nothing difficult. When the time comes, we'll likely refactor to
                                  Hibernate. Till them, we don't need it. My point, which I'm sure you
                                  know, is that even the useful, off-the-shelf, open-source stuff, isn't
                                  needed till its needed.

                                  regards
                                  jk
                                • Ron Jeffries
                                  ... I do have goals when I refactor. They are generally not of the form get all the way to this pattern, but of the form make this code better. However, it
                                  Message 16 of 17 , Jul 3, 2003
                                  • 0 Attachment
                                    On Thursday, July 3, 2003, at 12:23:24 AM, Joshua Kerievsky wrote:

                                    > Ron Jeffries wrote:

                                    >>If during our refactoring, the forces do not change substantially, then
                                    >>refactoring in the direction of the pattern will get us there. If we
                                    >>refactor all the way to the pattern without reassessing the forces along
                                    >>the way, that seems fraught to me. If we reassess the forces and they are
                                    >>now pointing in another direction, what should we do?
                                    >>
                                    > Sometimes refactorings make code uglier before further refactorings can
                                    > the code pretty again. What do you reassess when that happens?
                                    > Or is your code somehow always pretty when you refactor?

                                    I do have goals when I refactor. They are generally not of the form "get
                                    all the way to this pattern," but of the form "make this code better."

                                    However, it happens sometimes that I take a step which I know will make the
                                    code uglier (e.g. increasing the duplication in preparation for taking it
                                    out) and then the new shape of the code speaks to me in a new way, and I
                                    don't go where I expected to.

                                    >>Seems to me that going from an unknown starting location all the way to a
                                    >>pattern is likely to be a big bite, and likely to be suboptimal. If it is
                                    >>optimal to go all the way there, going incrementally will still get us
                                    >>there.
                                    >>
                                    > The two examples I mentioned, refactoring to Tempate Method and
                                    > refactoring to Null Object, both of which come from Martin's Refactoring
                                    > book, each contain mechanics that show how to refactor to those
                                    > patterns. Those mechanics direct one to take small steps -- called
                                    > refactorings -- to get to an end point, a pattern. No big bites,
                                    > nothing sub-optimal. We take small steps and keep our bar green. It's
                                    > possible to stop mid-way , go backwards or go forwards and all the way
                                    > to a pattern. You keep thinking and experimenting as you go.

                                    Ah, my point exactly. If we commit to refactoring /to/ a pattern, we are
                                    committing to doing all the little steps. If we commit to refactoring
                                    /toward/ a pattern, we invite ourselves to reassess after each step.

                                    I'm not objecting to getting all the way to the pattern. I'm objecting to
                                    committing to get there. To me, "Refactoring to patterns" suggests less
                                    sensitivity to feedback than "refactoring toward patterns".

                                    > The birthplace of every pattern is in the act of refactoring. When
                                    > people loose touch with the birthplace of a pattern, they often misuse
                                    > it. So I like to have folks re-live the birthing of a pattern. I do
                                    > that by showing them the refactorings that led up to the end result, the
                                    > pattern. It's all in the name of getting better and learning how to
                                    > make our code solid, small, simple and straightforward.

                                    Yes. It's a good thing. Like other good things, I object to the name of the
                                    thing, not to the practice of it. There might be a pattern here ...

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Hold on to your dream. --ELO
                                  • Steve Berczuk
                                    ... A better way to judge whether a pattern is a good pattern is to look at how well it fits in with other patterns (in this case in the book). Patterns
                                    Message 17 of 17 , Jul 9, 2003
                                    • 0 Attachment
                                      Pieter Nagel wrote:
                                      > On Tue, Jul 01, 2003 at 02:53:01PM -0700, Curtis Cooley wrote:
                                      >
                                      >
                                      >>I know Ron has wondered what would happen if all you paid attention to
                                      >>were the simplicity rules. Especially tolerate no duplication and reveal
                                      >>all intent. Others claim you must arrive at a pattern before hand.
                                      >
                                      >
                                      > I look at it this way: suppose you pick up a patterns book and want to
                                      > judge for yourself whether it is snakeoil or not. What do you do? You
                                      > judge each pattern you read from first principles. And those first
                                      > principles are, IMHO, much the same as XP's rules about no duplication,
                                      > simplicity and revealing intent.

                                      A better way to judge whether a "pattern" is a good pattern is to look
                                      at how well it fits in with other patterns (in this case in the book).
                                      Patterns taken one at a time can easily lead you to implementing a
                                      pattern for the pattern's sake. Patterns viewed as part of a pattern
                                      language are more likely to help you build a good system.

                                      > So, if you just apply the simplicity rules, you might end up at a known
                                      > pattern, because both you and the pattern guys are often trying to solve
                                      > the same problem. Conversely, often you can take a pattern off the shelf
                                      > to help you with the simplicity rules.

                                      You need a lot of experience to take a pattern 'off the shelf.' For
                                      example Visitor can be a great solution with the qualities of
                                      simplicity, no duplication etc when used in context of the other
                                      patterns in your system. Trying to implement a Visitor to solve your
                                      problem in other situations can make things more complicated...
                                      (just as an example...)

                                      Patterns taken alone can be tricky to use correctly..

                                      -steve

                                      --
                                      Steve Berczuk | steve@... | http://www.berczuk.com
                                      SCM Patterns: Effective Teamwork, Practical Integration
                                      www.scmpatterns.com
                                    Your message has been successfully submitted and would be delivered to recipients shortly.