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

Re: [XP] YAGNI & MVC - Patterns knowledge and sensitivity to smells

Expand Messages
  • 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 1 of 17 , Jul 1, 2003
      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 2 of 17 , Jul 2, 2003
        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 3 of 17 , Jul 2, 2003
          >>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 4 of 17 , Jul 2, 2003
            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 5 of 17 , Jul 2, 2003
              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 6 of 17 , Jul 2, 2003
                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 7 of 17 , Jul 2, 2003
                  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 8 of 17 , Jul 2, 2003
                    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 9 of 17 , Jul 3, 2003
                      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 10 of 17 , Jul 9, 2003
                        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.