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

Re: [XP] YAGNI and Abstraction

Expand Messages
  • Ilja Preuss
    ... Which might be as soon as you write unit tests for FileSearcher. Cheers, Ilja
    Message 1 of 26 , Sep 2, 2007
    • 0 Attachment
      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
    • Phlip
      ... 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
      Message 2 of 26 , Sep 2, 2007
      • 0 Attachment
        Ilja Preuss wrote:

        >> 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.

        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.

        --
        Phlip
        http://www.oreilly.com/catalog/9780596510657/
        "Test Driven Ajax (on Rails)"
        assert_xpath, assert_javascript, & assert_ajax
      • George Dinwiddie
        ... Maybe. Or maybe not. The bog-standard FileCounter might provide everything my test need. - George -- ... * George Dinwiddie *
        Message 3 of 26 , Sep 2, 2007
        • 0 Attachment
          Ilja Preuss wrote:
          > 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.

          Maybe. Or maybe not. The bog-standard FileCounter might provide
          everything my test need.

          - George

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Ron Jeffries
          Hello, Phlip. On Sunday, September 2, 2007, at 3:07:44 PM, you ... Yes. I find that when building up, avoiding /all/ file accesses is overkill. In legacy
          Message 4 of 26 , Sep 2, 2007
          • 0 Attachment
            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.

            Ron Jeffries
            www.XProgramming.com
            I could be wrong, of course. It's just not the way to bet.
          • John Roth
            From: Ron Jeffries To: Sent: Sunday, September 02, 2007 6:09 PM Subject: Re: [XP] YAGNI
            Message 5 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 6 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 7 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 8 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 9 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 10 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 11 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.