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

Re: [XP] YAGNI and Abstraction

Expand Messages
  • John Roth
    From: Ron Jeffries To: Sent: Sunday, September 02, 2007 6:09 PM Subject: Re: [XP] YAGNI
    Message 1 of 26 , Sep 2, 2007
    • 0 Attachment
      From: "Ron Jeffries" <ronjeffries@...>
      To: <extremeprogramming@yahoogroups.com>
      Sent: Sunday, September 02, 2007 6:09 PM
      Subject: Re: [XP] YAGNI and Abstraction


      > Hello, Phlip. On Sunday, September 2, 2007, at 3:07:44 PM, you
      > wrote:
      >
      >> Not everyone follows (or has even heard of) the rubric that unit tests
      >> shall
      >> not touch the file system. Some of us might even write a searcher that
      >> populates a temporary folder with goodies and searches for them.
      >
      >> The rubric exists to force abstractions to emerge. So you have simply
      >> stated
      >> the goal of Premature Generalization in another way.
      >
      > Yes. I find that when building up, avoiding /all/ file accesses is
      > overkill. In legacy code, however, where people have all kinds of DB
      > stuff tangled with app-specific stuff, Then testing becomes really
      > hard. Somewhere from a couple of file accesses to touching Oracle on
      > every test, a line needs to be drawn. My guess is that Feathers's
      > guideline of NO such things is a good starting point to deviate from
      > ... but that wise and practiced people will deviate to advantage.

      Of course, the other issue on file system, data base, network access
      or other expensive tests is that they are expensive; most projects are
      going to hit a point where trying to run all the tests in the "TDD
      window" is going to impact the process, either by running tests
      less frequently or breaking the flow.

      Learning how to abstract expensive resources, classify tests and
      similar strategies is going to pay off. You may not need to use it
      all the time, or on all projects, but sooner or later you're going to
      find it useful.

      John Roth



      >
      > Ron Jeffries
      > www.XProgramming.com
      > I could be wrong, of course. It's just not the way to bet.
      >
      >
    • Ron Jeffries
      Hello, John. On Sunday, September 2, 2007, at 9:16:05 PM, you ... Oh yes, I completely agree. One needs to know how to do it, and important not to build
      Message 2 of 26 , Sep 2, 2007
      • 0 Attachment
        Hello, John. On Sunday, September 2, 2007, at 9:16:05 PM, you
        wrote:

        >> Yes. I find that when building up, avoiding /all/ file accesses is
        >> overkill. In legacy code, however, where people have all kinds of DB
        >> stuff tangled with app-specific stuff, Then testing becomes really
        >> hard. Somewhere from a couple of file accesses to touching Oracle on
        >> every test, a line needs to be drawn. My guess is that Feathers's
        >> guideline of NO such things is a good starting point to deviate from
        >> ... but that wise and practiced people will deviate to advantage.

        > Of course, the other issue on file system, data base, network access
        > or other expensive tests is that they are expensive; most projects are
        > going to hit a point where trying to run all the tests in the "TDD
        > window" is going to impact the process, either by running tests
        > less frequently or breaking the flow.

        > Learning how to abstract expensive resources, classify tests and
        > similar strategies is going to pay off. You may not need to use it
        > all the time, or on all projects, but sooner or later you're going to
        > find it useful.

        Oh yes, I completely agree. One needs to know how to do it, and
        important not to build things that get all entangled. At the same
        time, the tests aren't complete without SOME test of the file
        connection, DB connection, and so on. I think Feather's rule is a
        good starting point, and expect never to finish there.

        Ron Jeffries
        www.XProgramming.com
        The model that really matters is the one that people have in
        their minds. All other models and documentation exist only to
        get the right model into the right mind at the right time.
        -- Paul Oldfield
      • Abe Rodriguez
        Hi all, Just joined the group yesterday, I think my IQ has already gone up about 6 points… I think Ilja is right, you’re probably going to need the
        Message 3 of 26 , Sep 6, 2007
        • 0 Attachment
          Hi all,



          Just joined the group yesterday, I think my IQ has already gone up about 6
          points…



          I think Ilja is right, you’re probably going to need the interface as soon
          as you start unit testing, especially with tools like NMock or RhinoMocks.
          And at the end of the day, if for the cost of typing a simple interface
          declaration instead of having to manually create a stub, I think it’s well
          worth it. I don’t feel like it’s designing for a possible feature tomorrow
          (YAGNI), rather, it’s simplifying testing and giving me looser coupling as a
          byproduct. Both of which are good things.



          Just my two cents!



          From: extremeprogramming@yahoogroups.com
          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Ricardo Mayerhofer
          Sent: Thursday, September 06, 2007 6:24 PM
          To: extremeprogramming@yahoogroups.com
          Subject: Re: [XP] YAGNI and Abstraction



          Thank you all for the responses!
          Some of you adviced to create an interface if I need to replace it for
          testing purposes. Actually I usually do it.
          But why not just derive the concrete class and overide its methods if I
          need to stub it? Just wondering.

          Ricardo

          Ilja Preuss escreveu:
          >
          > George Dinwiddie wrote:
          > > On Mon, August 27, 2007 13:15, Ricardo Mayerhofer wrote:
          > >> Hello all,
          > >> When doing TDD, I get confused sometimes regarding two principles:
          > >> "YAGNI" and "depends on abstraction not on concretion".
          > >> For example, I'm developing a class named FileSearcher that depends
          > >> on another class named FileCounter.So I inject FileCounter in
          > >> FileSearcher.
          > >> Following "depends on abstraction not on concretion" principle,
          > >> FileSearcher should use a FileCounter interface. Then I create an
          > >> implementation class for that interface and inject in FileCounter.
          > >> Following YAGNI principle: man I don't need that interface, so I
          > >> will get rid of it and receive the implementation class as a parameter.
          > >> If I need two different implementations someday then I create an
          > >> interface.
          > >
          > > In this scenario, I would follow YAGNI. Not everything needs to be an
          > > abstraction, particularly if it's only used in one place. Like you say,
          > > when you need two implementations, that's the time to turn FileCounter
          > > into an interface.
          >
          > Which might be as soon as you write unit tests for FileSearcher.
          >
          > Cheers, Ilja
          >
          >

          --
          GAS Tecnologia
          Ricardo Mayerhofer
          ricardo@... <mailto:ricardo%40gastecnologia.com.br>
          http://www.gastecnologia.com.br
          Tel.: +55 61 3349-1188
          --

          --
          Esta mensagem pode conter informação confidencial e/ou privilegiada. Se você
          não for o destinatário ou a pessoa autorizada a receber esta mensagem, não
          pode usar, copiar ou divulgar as informações nela contidas ou tomar qualquer
          ação baseada nessas informações. Se você recebeu esta mensagem por engano,
          por favor avise imediatamente o remetente, respondendo o e-mail e em seguida
          apague-o.

          This message may contain confidential and/or privileged information. If you
          are not the addressee or authorized to receive this for the addressee, you
          must not use, copy, disclose or take any action based on this message or any
          information herein. If you have received this message in error, please
          advise the sender immediately by reply e-mail and delete this message.
          --





          [Non-text portions of this message have been removed]
        • Dave Nicolette
          ... Can you do this in a way that is transparent to the code under test? Dave ... parameter. ... be an ... you say, ... FileCounter ... Se você não for o
          Message 4 of 26 , Sep 6, 2007
          • 0 Attachment
            --- In extremeprogramming@yahoogroups.com, Ricardo Mayerhofer
            <ricardo@...> wrote:
            >
            > Thank you all for the responses!
            > Some of you adviced to create an interface if I need to replace it for
            > testing purposes. Actually I usually do it.
            > But why not just derive the concrete class and overide its methods if I
            > need to stub it? Just wondering.

            Can you do this in a way that is transparent to the code under test?

            Dave





            >
            > Ricardo
            >
            > Ilja Preuss escreveu:
            > >
            > > George Dinwiddie wrote:
            > > > On Mon, August 27, 2007 13:15, Ricardo Mayerhofer wrote:
            > > >> Hello all,
            > > >> When doing TDD, I get confused sometimes regarding two principles:
            > > >> "YAGNI" and "depends on abstraction not on concretion".
            > > >> For example, I'm developing a class named FileSearcher that depends
            > > >> on another class named FileCounter.So I inject FileCounter in
            > > >> FileSearcher.
            > > >> Following "depends on abstraction not on concretion" principle,
            > > >> FileSearcher should use a FileCounter interface. Then I create an
            > > >> implementation class for that interface and inject in FileCounter.
            > > >> Following YAGNI principle: man I don't need that interface, so I
            > > >> will get rid of it and receive the implementation class as a
            parameter.
            > > >> If I need two different implementations someday then I create an
            > > >> interface.
            > > >
            > > > In this scenario, I would follow YAGNI. Not everything needs to
            be an
            > > > abstraction, particularly if it's only used in one place. Like
            you say,
            > > > when you need two implementations, that's the time to turn
            FileCounter
            > > > into an interface.
            > >
            > > Which might be as soon as you write unit tests for FileSearcher.
            > >
            > > Cheers, Ilja
            > >
            > >
            >
            >
            > --
            > GAS Tecnologia
            > Ricardo Mayerhofer
            > ricardo@...
            > http://www.gastecnologia.com.br
            > Tel.: +55 61 3349-1188
            > --
            >
            > --
            > Esta mensagem pode conter informação confidencial e/ou privilegiada.
            Se você não for o destinatário ou a pessoa autorizada a receber esta
            mensagem, não pode usar, copiar ou divulgar as informações nela
            contidas ou tomar qualquer ação baseada nessas informações. Se você
            recebeu esta mensagem por engano, por favor avise imediatamente o
            remetente, respondendo o e-mail e em seguida apague-o.
            >
            > This message may contain confidential and/or privileged information.
            If you are not the addressee or authorized to receive this for the
            addressee, you must not use, copy, disclose or take any action based
            on this message or any information herein. If you have received this
            message in error, please advise the sender immediately by reply e-mail
            and delete this message.
            > --
            >
          • Nguyen Phuc Hai
            Interface is the contract between the module implementation and other modules. . YAGNI is good but please care how you can extend your program with effort as
            Message 5 of 26 , Sep 6, 2007
            • 0 Attachment
              Interface is the contract between the module implementation and other modules. . YAGNI is good but please care how you can extend your program with effort as little as possible (that means instead of guessing and do what you need in future, you just do enough but it can be easily extended later). Using concrete class is ok but it can make your program rigid and it takes a lot effort of refactoring later.

              If you are sure there it is not hard to initiate and in-mutable (no change in its behaviors), then using concrete class is ok (Does DTO need to make abstraction? or Utility class with purpose that count the sum of numbers, do I need another implement? It is depended).

              Hai
              (http://www.haiphucnguyen.net/blog)

              Ricardo Mayerhofer <ricardo@...> wrote: Thank you all for the responses!
              Some of you adviced to create an interface if I need to replace it for
              testing purposes. Actually I usually do it.
              But why not just derive the concrete class and overide its methods if I
              need to stub it? Just wondering.

              Ricardo

              Ilja Preuss escreveu:
              >
              > George Dinwiddie wrote:
              > > On Mon, August 27, 2007 13:15, Ricardo Mayerhofer wrote:
              > >> Hello all,
              > >> When doing TDD, I get confused sometimes regarding two principles:
              > >> "YAGNI" and "depends on abstraction not on concretion".
              > >> For example, I'm developing a class named FileSearcher that depends
              > >> on another class named FileCounter.So I inject FileCounter in
              > >> FileSearcher.
              > >> Following "depends on abstraction not on concretion" principle,
              > >> FileSearcher should use a FileCounter interface. Then I create an
              > >> implementation class for that interface and inject in FileCounter.
              > >> Following YAGNI principle: man I don't need that interface, so I
              > >> will get rid of it and receive the implementation class as a parameter.
              > >> If I need two different implementations someday then I create an
              > >> interface.
              > >
              > > In this scenario, I would follow YAGNI. Not everything needs to be an
              > > abstraction, particularly if it's only used in one place. Like you say,
              > > when you need two implementations, that's the time to turn FileCounter
              > > into an interface.
              >
              > Which might be as soon as you write unit tests for FileSearcher.
              >
              > Cheers, Ilja
              >
              >

              --
              GAS Tecnologia
              Ricardo Mayerhofer
              ricardo@...
              http://www.gastecnologia.com.br
              Tel.: +55 61 3349-1188
              --

              --
              Esta mensagem pode conter informação confidencial e/ou privilegiada. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não pode usar, copiar ou divulgar as informações nela contidas ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o.

              This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.
              --






              ---------------------------------
              Got a little couch potato?
              Check out fun summer activities for kids.

              [Non-text portions of this message have been removed]
            • Ricardo Mayerhofer
              Thank you all for the responses! Some of you adviced to create an interface if I need to replace it for testing purposes. Actually I usually do it. But why not
              Message 6 of 26 , Sep 6, 2007
              • 0 Attachment
                Thank you all for the responses!
                Some of you adviced to create an interface if I need to replace it for
                testing purposes. Actually I usually do it.
                But why not just derive the concrete class and overide its methods if I
                need to stub it? Just wondering.

                Ricardo

                Ilja Preuss escreveu:
                >
                > George Dinwiddie wrote:
                > > On Mon, August 27, 2007 13:15, Ricardo Mayerhofer wrote:
                > >> Hello all,
                > >> When doing TDD, I get confused sometimes regarding two principles:
                > >> "YAGNI" and "depends on abstraction not on concretion".
                > >> For example, I'm developing a class named FileSearcher that depends
                > >> on another class named FileCounter.So I inject FileCounter in
                > >> FileSearcher.
                > >> Following "depends on abstraction not on concretion" principle,
                > >> FileSearcher should use a FileCounter interface. Then I create an
                > >> implementation class for that interface and inject in FileCounter.
                > >> Following YAGNI principle: man I don't need that interface, so I
                > >> will get rid of it and receive the implementation class as a parameter.
                > >> If I need two different implementations someday then I create an
                > >> interface.
                > >
                > > In this scenario, I would follow YAGNI. Not everything needs to be an
                > > abstraction, particularly if it's only used in one place. Like you say,
                > > when you need two implementations, that's the time to turn FileCounter
                > > into an interface.
                >
                > Which might be as soon as you write unit tests for FileSearcher.
                >
                > Cheers, Ilja
                >
                >


                --
                GAS Tecnologia
                Ricardo Mayerhofer
                ricardo@...
                http://www.gastecnologia.com.br
                Tel.: +55 61 3349-1188
                --

                --
                Esta mensagem pode conter informação confidencial e/ou privilegiada. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não pode usar, copiar ou divulgar as informações nela contidas ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o.

                This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.
                --
              • Michael Feathers
                ... Ron, Yes, that was the intention. I ve been hearing discussion of that thing that I said about unit tests for a couple of years now and I think it s a
                Message 7 of 26 , Sep 9, 2007
                • 0 Attachment
                  Ron Jeffries wrote:

                  >>The rubric exists to force abstractions to emerge. So you have simply stated
                  >>the goal of Premature Generalization in another way.
                  >>
                  >>
                  >
                  >Yes. I find that when building up, avoiding /all/ file accesses is
                  >overkill. In legacy code, however, where people have all kinds of DB
                  >stuff tangled with app-specific stuff, Then testing becomes really
                  >hard. Somewhere from a couple of file accesses to touching Oracle on
                  >every test, a line needs to be drawn. My guess is that Feathers's
                  >guideline of NO such things is a good starting point to deviate from
                  >... but that wise and practiced people will deviate to advantage.
                  >
                  >

                  Ron,

                  Yes, that was the intention.

                  I've been hearing discussion of that thing that I said about unit tests
                  for a couple of years now and I think it's a great example of what I
                  call "social signal loss." People don't remember the whole statement.
                  It gets simplified to "don't access external resources in your tests,
                  ever." Here's what I said, with all of it's qualifications:
                  http://www.artima.com/weblogs/viewpost.jsp?thread=126923

                  I guess politicians live with this sort of thing also. Nuance doesn't
                  carry.


                  Michael Feathers
                  www.objectmentor.com
                Your message has been successfully submitted and would be delivered to recipients shortly.