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

Re: [XP] YAGNI and Abstraction

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.