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

Re: [XP] YAGNI and Abstraction

Expand Messages
  • 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 1 of 26 , Sep 2, 2007
      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 2 of 26 , Sep 6, 2007
        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 3 of 26 , Sep 6, 2007
          --- 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 4 of 26 , Sep 6, 2007
            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 5 of 26 , Sep 6, 2007
              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 6 of 26 , Sep 9, 2007
                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.