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

Re: [XP] YAGNI and Abstraction

Expand Messages
  • George Dinwiddie
    ... 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
    Message 1 of 26 , Aug 27, 2007
      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.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • Manuel Klimek
      I d say: it depends. /If/ it makes your design more understandable in the context of developers you are working with, it isn t YAGNI - it adds value (in form
      Message 2 of 26 , Aug 27, 2007
        I'd say: it depends.
        /If/ it makes your design more understandable in the context
        of developers you are working with, it isn't YAGNI - it adds value
        (in form of understandable design or decoupling). Perhaps you
        need the interface for the test, in this case it isn't YAGNI, too.

        /If/ you add the interface just because "somewhen in the future
        you will most certainly need it", chances are high that you will
        not - although I personally violated YAGNI two or three times,
        which resulted in less work (C++ isn't the best refactorable
        language out there - who wanted to write the tools? ;-)

        There seems to be quite some disagreement on this forum
        on the necessity of interfaces. This is why I conclude that it
        mainly depends on the programming background / education.

        Cheers,
        Manuel

        On 8/27/07, George Dinwiddie <lists@...> 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.
        >
        > - George
        >
        > --
        > ----------------------------------------------------------
        > * George Dinwiddie * http://blog.gdinwiddie.com
        > Software Development http://www.idiacomputing.com
        > Consultant and Coach http://www.agilemaryland.org
        > ----------------------------------------------------------
        >
        >
        >



        --
        http://klimek.box4.net


        [Non-text portions of this message have been removed]
      • Seyit Caglar Abbasoglu
        If 1. you don t need polymorphic behavior for the injection, 2. you don t need to fake FileCounter for tests of FileSearcher, 3. A named interface does not
        Message 3 of 26 , Aug 27, 2007
          If

          1. you don't need polymorphic behavior for the injection,
          2. you don't need to fake FileCounter for tests of FileSearcher,
          3. A named interface does not needed to clarify your intend,

          then I vote for YAGNI. I don't have much knowledge about refactoring tools
          on other languages but for Java or C# it's fairly easy to extract an
          interface if you need later. So why would you bother (spend time to write
          and maintain) now.

          On 8/27/07, Ricardo Mayerhofer <ricardo@...> 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.
          >
          > How does these two principles relates with each other? Is it
          > possible or recommended to use both?
          > Any thoughts?
          >
          > Thanks.
          >
          > Ricardo
          >
          >


          [Non-text portions of this message have been removed]
        • Cory Foy
          ... When you inject it, are you using the actual FileCounter or a stub? ... This is pretty much what I do. However, I almost always end up creating a stub
          Message 4 of 26 , Aug 27, 2007
            Ricardo Mayerhofer wrote:
            > For example, I'm developing a class named FileSearcher that depends
            > on another class named FileCounter.So I inject FileCounter in FileSearcher.

            When you inject it, are you using the actual FileCounter or a stub?

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

            This is pretty much what I do. However, I almost always end up creating
            a stub class to pass in instead of the actual implementation, so in that
            case, the interface comes in very handy.

            --
            Cory Foy
            http://www.cornetdesign.com
          • Ricardo Mayerhofer
            Hello all, When doing TDD, I get confused sometimes regarding two principles: YAGNI and depends on abstraction not on concretion . For example, I m
            Message 5 of 26 , Aug 27, 2007
              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.

              How does these two principles relates with each other? Is it
              possible or recommended to use both?
              Any thoughts?

              Thanks.

              Ricardo
            • Corey Haines
              +1 for Manuel. YAGNI should encompass everything. Tests are an essential part of your code, at least (if not more) as important as the production code. If the
              Message 6 of 26 , Aug 27, 2007
                +1 for Manuel.

                YAGNI should encompass everything. Tests are an essential part of your code,
                at least (if not more) as important as the production code. If the tests
                asks for an interface, so that you can effectively mock the dependency (you
                don't ALWAYS have to mock the dependency), then YA(ren't)GNI becomes YD(o)NI

                -Corey


                On 8/27/07, Manuel Klimek <klimek@...> wrote:
                >
                > I'd say: it depends.
                > /If/ it makes your design more understandable in the context
                > of developers you are working with, it isn't YAGNI - it adds value
                > (in form of understandable design or decoupling). Perhaps you
                > need the interface for the test, in this case it isn't YAGNI, too.
                >
                > /If/ you add the interface just because "somewhen in the future
                > you will most certainly need it", chances are high that you will
                > not - although I personally violated YAGNI two or three times,
                > which resulted in less work (C++ isn't the best refactorable
                > language out there - who wanted to write the tools? ;-)
                >
                > There seems to be quite some disagreement on this forum
                > on the necessity of interfaces. This is why I conclude that it
                > mainly depends on the programming background / education.
                >
                > Cheers,
                > Manuel
                >
                > On 8/27/07, George Dinwiddie <lists@...<lists%40idiacomputing.com>>
                > 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.
                > >
                > > - George
                > >
                > > --
                > > ----------------------------------------------------------
                > > * George Dinwiddie * http://blog.gdinwiddie.com
                > > Software Development http://www.idiacomputing.com
                > > Consultant and Coach http://www.agilemaryland.org
                > > ----------------------------------------------------------
                > >
                > >
                > >
                >
                > --
                > http://klimek.box4.net
                >
                > [Non-text portions of this message have been removed]
                >
                >
                >



                --
                http://www.coreyhaines.com


                [Non-text portions of this message have been removed]
              • Cory Foy
                ... Have you ever encountered problems because of it? Have you ever wished that you had used interfaces from the beginning? In short - is what you are doing
                Message 7 of 26 , Aug 27, 2007
                  Ricardo Mayerhofer wrote:
                  > Sometimes I use a stub, but even tough I don't need a interface. I just
                  > derive it from the actual FileCounter, and overide its methods.
                  >
                  > What do you think about this?

                  Have you ever encountered problems because of it? Have you ever wished
                  that you had used interfaces from the beginning?

                  In short - is what you are doing now working for you?


                  --
                  Cory Foy
                  http://www.cornetdesign.com
                • Ricardo Mayerhofer
                  Sometimes I use a stub, but even tough I don t need a interface. I just derive it from the actual FileCounter, and overide its methods. What do you think about
                  Message 8 of 26 , Aug 27, 2007
                    Sometimes I use a stub, but even tough I don't need a interface. I just
                    derive it from the actual FileCounter, and overide its methods.

                    What do you think about this?

                    Ricardo

                    Cory Foy escreveu:
                    >
                    > Ricardo Mayerhofer wrote:
                    > > For example, I'm developing a class named FileSearcher that depends
                    > > on another class named FileCounter.So I inject FileCounter in
                    > FileSearcher.
                    >
                    > When you inject it, are you using the actual FileCounter or a stub?
                    >
                    > > 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.
                    >
                    > This is pretty much what I do. However, I almost always end up creating
                    > a stub class to pass in instead of the actual implementation, so in that
                    > case, the interface comes in very handy.
                    >
                    > --
                    > Cory Foy
                    > http://www.cornetdesign.com <http://www.cornetdesign.com>
                    >
                    >


                    --
                    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.
                    --
                  • Tim Ottinger
                    I m foolishly simpleminded enough to rely on the three numbers. If it s zero, then I do nothing at all (even if that s likely to change later). If it s one, I
                    Message 9 of 26 , Aug 27, 2007
                      I'm foolishly simpleminded enough to rely on the three numbers.
                      If it's zero, then I do nothing at all (even if that's likely to change later).
                      If it's one, I do a simple implementation -- for Ottinger-like value of simple.
                      If it's many, I do an interface. If I have one real one and one mock it counts as "many".

                      ----- Original Message ----
                      From: Seyit Caglar Abbasoglu <scabbasoglu@...>
                      To: extremeprogramming@yahoogroups.com
                      Sent: Monday, August 27, 2007 9:09:57 AM
                      Subject: Re: [XP] YAGNI and Abstraction

                      If

                      1. you don't need polymorphic behavior for the injection,
                      2. you don't need to fake FileCounter for tests of FileSearcher,
                      3. A named interface does not needed to clarify your intend,

                      then I vote for YAGNI. I don't have much knowledge about refactoring tools
                      on other languages but for Java or C# it's fairly easy to extract an
                      interface if you need later. So why would you bother (spend time to write
                      and maintain) now.

                      On 8/27/07, Ricardo Mayerhofer <ricardo@...> 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.
                      >
                      > How does these two principles relates with each other? Is it
                      > possible or recommended to use both?
                      > Any thoughts?
                      >
                      > Thanks.
                      >
                      > Ricardo
                      >
                      >


                      [Non-text portions of this message have been removed]



                      To Post a message, send it to: extremeprogramming@...

                      To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

                      ad-free courtesy of objectmentor.com
                      Yahoo! Groups Links










                      ____________________________________________________________________________________
                      Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7


                      [Non-text portions of this message have been removed]
                    • Seyit Caglar Abbasoglu
                      ... I think it s fair. But as an exception, sometimes although it s one, I tend to use an interface to make code more readable. Most of the time, that
                      Message 10 of 26 , Aug 27, 2007
                        >
                        > I'm foolishly simpleminded enough to rely on the three numbers.
                        > If it's zero, then I do nothing at all (even if that's likely to change
                        > later).
                        > If it's one, I do a simple implementation -- for Ottinger-like value of
                        > simple.
                        > If it's many, I do an interface. If I have one real one and one mock it
                        > counts as "many".
                        >

                        I think it's fair. But as an exception, sometimes although it's one, I tend
                        to use an interface to make code more readable. Most of the time, that
                        interface extracts as a class and I remove it again later.

                        Probably given example does not like that exception, so I'd go for
                        "Ottinger-like value of simple" :)

                        On 8/28/07, Tim Ottinger <linux_tim@...> wrote:
                        >
                        > I'm foolishly simpleminded enough to rely on the three numbers.
                        > If it's zero, then I do nothing at all (even if that's likely to change
                        > later).
                        > If it's one, I do a simple implementation -- for Ottinger-like value of
                        > simple.
                        > If it's many, I do an interface. If I have one real one and one mock it
                        > counts as "many".
                        >
                        > ----- Original Message ----
                        > From: Seyit Caglar Abbasoglu <scabbasoglu@...<scabbasoglu%40gmail.com>
                        > >
                        > To: extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>
                        > Sent: Monday, August 27, 2007 9:09:57 AM
                        > Subject: Re: [XP] YAGNI and Abstraction
                        >
                        > If
                        >
                        > 1. you don't need polymorphic behavior for the injection,
                        > 2. you don't need to fake FileCounter for tests of FileSearcher,
                        > 3. A named interface does not needed to clarify your intend,
                        >
                        > then I vote for YAGNI. I don't have much knowledge about refactoring tools
                        > on other languages but for Java or C# it's fairly easy to extract an
                        > interface if you need later. So why would you bother (spend time to write
                        > and maintain) now.
                        >
                        > On 8/27/07, Ricardo Mayerhofer <ricardo@...<ricardo%40ssitec.com.br>>
                        > 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.
                        > >
                        > > How does these two principles relates with each other? Is it
                        > > possible or recommended to use both?
                        > > Any thoughts?
                        > >
                        > > Thanks.
                        > >
                        > > Ricardo
                        > >
                        > >
                        >
                        > [Non-text portions of this message have been removed]
                        >
                        > To Post a message, send it to: extremeprogramming@...<extremeprogramming%40eGroups.com>
                        >
                        > To Unsubscribe, send a blank message to:
                        > extremeprogramming-unsubscribe@...<extremeprogramming-unsubscribe%40eGroups.com>
                        >
                        > ad-free courtesy of objectmentor.com
                        > Yahoo! Groups Links
                        >
                        > __________________________________________________________
                        > Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user
                        > panel and lay it on us.
                        > http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
                        >
                        > [Non-text portions of this message have been removed]
                        >
                        >
                        >


                        [Non-text portions of this message have been removed]
                      • Ron Jeffries
                        Hello, Ricardo. On Monday, August 27, 2007, at 1:15:46 PM, you ... I always write the simpler code and put in more complex elements such as interfaces only
                        Message 11 of 26 , Aug 28, 2007
                          Hello, Ricardo. On Monday, August 27, 2007, at 1:15:46 PM, you
                          wrote:

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

                          > How does these two principles relates with each other? Is it
                          > possible or recommended to use both?
                          > Any thoughts?

                          I always write the simpler code and put in more complex elements
                          such as interfaces only when the code calls for them. It's not the
                          only way, but it works nicely for me.

                          Ron Jeffries
                          www.XProgramming.com
                          That's my opinion and I agree with it. -- Julio Santos
                        • Carfield Yim
                          ... I will think if the abstraction is not required by any test and other code, it should be remove. At least in most of the case.
                          Message 12 of 26 , Aug 28, 2007
                            > 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.
                            >
                            > How does these two principles relates with each other? Is it
                            > possible or recommended to use both?
                            > Any thoughts?
                            >
                            I will think if the abstraction is not required by any test and other
                            code, it should be remove. At least in most of the case.
                          • Charlie Poole
                            Hi Ron, ... I just realized something reading this. I find that interfaces sometimes make my code simpler- at least to my perception. For example, I ll often
                            Message 13 of 26 , Aug 28, 2007
                              Hi Ron,

                              > I always write the simpler code and put in more complex
                              > elements such as interfaces only when the code calls for
                              > them. It's not the only way, but it works nicely for me.

                              I just realized something reading this. I find that interfaces
                              sometimes make my code simpler- at least to my perception.

                              For example, I'll often create an interface that is intended
                              for users of an object, leaving out the methods meant
                              for the creator of the object. That means I have fewer
                              choices when I go to use the object - fewer items in the
                              Intellisense - and that simplifies my life and seems to
                              make the code easier to understand.

                              When I use an interface this way - as opposed to the more
                              usual usage for allowing substitution - I typically put
                              the definition at the top of the same file where the
                              sole implementing class is defined.

                              Of course, this doesn't work for all purposes and may not
                              appeal to those who aren't fans of interface in the first place. :-)

                              Charlie
                            • Tim Ottinger
                              Zero is important. http://blog.objectmentor.com/articles/2007/03/22/zero ... From: Carfield Yim To: extremeprogramming@yahoogroups.com
                              Message 14 of 26 , Aug 28, 2007
                                Zero is important.
                                http://blog.objectmentor.com/articles/2007/03/22/zero

                                ----- Original Message ----
                                From: Carfield Yim <carfield@...>
                                To: extremeprogramming@yahoogroups.com
                                Sent: Tuesday, August 28, 2007 10:01:09 AM
                                Subject: Re: [XP] YAGNI and Abstraction

                                > 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.
                                >
                                > How does these two principles relates with each other? Is it
                                > possible or recommended to use both?
                                > Any thoughts?
                                >
                                I will think if the abstraction is not required by any test and other
                                code, it should be remove. At least in most of the case.


                                To Post a message, send it to: extremeprogramming@...

                                To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

                                ad-free courtesy of objectmentor.com
                                Yahoo! Groups Links










                                ____________________________________________________________________________________
                                Luggage? GPS? Comic books?
                                Check out fitting gifts for grads at Yahoo! Search
                                http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

                                [Non-text portions of this message have been removed]
                              • Ilja Preuss
                                ... Which might be as soon as you write unit tests for FileSearcher. Cheers, Ilja
                                Message 15 of 26 , Sep 2, 2007
                                  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
                                • Ilja Preuss
                                  ... I do that, too. I think the Interface Segregation Principle is typically undervalued. Cheers, Ilja
                                  Message 16 of 26 , Sep 2, 2007
                                    Charlie Poole wrote:

                                    > For example, I'll often create an interface that is intended
                                    > for users of an object, leaving out the methods meant
                                    > for the creator of the object. That means I have fewer
                                    > choices when I go to use the object - fewer items in the
                                    > Intellisense - and that simplifies my life and seems to
                                    > make the code easier to understand.

                                    I do that, too. I think the Interface Segregation Principle is typically
                                    undervalued.

                                    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 17 of 26 , Sep 2, 2007
                                      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 18 of 26 , Sep 2, 2007
                                        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 19 of 26 , Sep 2, 2007
                                          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 20 of 26 , Sep 2, 2007
                                            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 21 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 22 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 23 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 24 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 25 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 26 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.