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

Re: [XP] [OT] Delegation and YAGNI!

Expand Messages
  • Ron Jeffries
    ... I like to consider issues like these by looking at the code. Have you some code we could look at, simplified, perhaps? Ideally with tests? Ron Jeffries
    Message 1 of 24 , Dec 1, 2004
      On Wednesday, December 1, 2004, at 11:52:47 AM, Stede Troisi wrote:

      > I was thinking about YAGNI yesterday. Normally, I see
      > most people create a customer class that holds domain
      > information and another class, say CustomerDb that
      > persists the information from customer to a database.
      > This makes sense, becuase if I want to persist to
      > something different (like a flat file) I can create a
      > new class to handle it while leaving the domain class
      > intact.

      > But two objects that share the same basic fields
      > (customer) seems to go against YAGNI. Is this how most
      > people solve the problem or is there a better
      > solution?

      I like to consider issues like these by looking at the code. Have you some
      code we could look at, simplified, perhaps? Ideally with tests?

      Ron Jeffries
      www.XProgramming.com
      This is how I develop software.
      Take the parts that make sense to you.
      Ignore the rest.
    • Ramon Leon
      YouArentGonnaNeedIt is only one of many principles, you have to balance it with the others. OnceAndOnlyOnce and DoSimpleThings will lead you to making sure
      Message 2 of 24 , Dec 1, 2004
        YouArentGonnaNeedIt is only one of many principles, you have to balance
        it with the others. OnceAndOnlyOnce and DoSimpleThings will lead you to
        making sure each class only has one responsibility, and you are gonna
        need that. YouArentGonnaNeedIt is not a justification to violate basic
        good OO principles like SingleResponsibilityPrinciple. In the java
        community, I'm pretty sure most people just use existing open source
        object mapping layers, in the .NET world, most are still hacking up
        their own private implementation because there isn't any really
        outstanding open source implementations yet.

        > -----Original Message-----
        > From: Stede Troisi [mailto:stedetro@...]
        > Sent: Wednesday, December 01, 2004 9:53 AM
        > To: extremeprogramming@yahoogroups.com
        > Subject: [XP] [OT] Delegation and YAGNI!
        >
        >
        > I was thinking about YAGNI yesterday. Normally, I see most
        > people create a customer class that holds domain information
        > and another class, say CustomerDb that persists the
        > information from customer to a database.
        > This makes sense, becuase if I want to persist to something
        > different (like a flat file) I can create a new class to
        > handle it while leaving the domain class intact.
        >
        > But two objects that share the same basic fields
        > (customer) seems to go against YAGNI. Is this how most people
        > solve the problem or is there a better solution?
        >
        > Thanks,
        > Stede
        >
        >
        >
        >
        > __________________________________
        > Do you Yahoo!?
        > The all-new My Yahoo! - What will yours do?
        > http://my.yahoo.com
        >
        >
        > 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
        >
        >
        >
        >
        >
        >
        >
        >
      • Jeff Grigg
        ... In other words, put all persistence code in /one/ place -- not one per business class. Most per-class logic will be data driven, and hence generic. ...
        Message 3 of 24 , Dec 1, 2004
          --- "Ramon Leon" <rleon@i...> wrote:
          > [...] In the java community, I'm pretty sure most people
          > just use existing open source object mapping layers, in
          > the .NET world, most are still hacking up their own
          > private implementation because there isn't any really
          > outstanding open source implementations yet.

          In other words, put all persistence code in /one/ place -- not one
          per business class. Most per-class logic will be data driven, and
          hence generic.


          > --- From: Stede Troisi [mailto:stedetro@y...]
          >> I was thinking about YAGNI yesterday. [...]
          >> [...] if I want to persist to something different (like
          >> a flat file) I can create a new class to handle it while
          >> leaving the domain class intact.

          *This* is the right point to say "You Aren't Going to Need It" --
          *don't* complicate your design now with the justification that, "Some
          day we might want to persist to XML instead of the database."

          >> Is this how most people solve the problem or is there
          >> a better solution?

          Sure there's a better solution: Object Prevalence. Don't persist
          your objects to a relational database. You don't need it. ;->

          http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ
        • Steven Gordon
          Why was this considered OT?? One way YAGNI applies in this kind of situation is that the stories asking for visible business functionality should be separate
          Message 4 of 24 , Dec 1, 2004
            Why was this considered OT??

            One way YAGNI applies in this kind of situation is that the stories
            asking for visible business functionality should be separate from
            the stories asking for persistance functionality. Given the
            dependencies between those stories, the business functionality
            stories almost always have greater business value to the customer
            than the persistance stories.

            Persistance is totally YAGNI when implementing the business
            functionality stories, so you first end up with a Customer class
            that provides the visible functionality your customer needs (via
            iterative feedback) with tests that verify its behavior.

            Then, when the persistance stories are the highest priority
            stories not yet implemented, persistance is no longer YAGNI.
            DoSimpleThings, ExpressiveCode, SingleResponsibilityPrinciple,
            etc. will then lead to building a data access layer (or
            leveraging an existing framework). Refactoring (i.e.,
            continuously applying OnceAndOnlyOnce) will keep it as simple
            as possible.

            If the original question was whether having virtually identical
            field names in the Customer object, the database, and the data
            access layer mediating them constitutes duplication, that appears
            to me to be a form of duplication whose elimination would likely
            lead to code that is far more difficult to understand and maintain
            than the code with the duplicative field names.

            Consider CMP in J2EE which is essentially driven by meta-data
            expressed in XML files. I have found CMP frustrating because I
            cannot refactor the code (or the database) without carefully
            editing that XML file. It does not feel like OnceAndOnlyOnce when
            I have to keep the database, code, and XML descriptors in synch.
            Of course, an Eclipse Plugin with XDOCLET-like functionality
            could automate a lot of the synchronization issues away.

            Steven A. Gordon, Ph.D.
            Manager, Software Factory
            Arizona State University
            PO Box 875506
            Tempe, AZ 85287-9509
            http://sf.asu.edu
            (480)-727-6271



            -----Original Message-----
            From: Ramon Leon [mailto:rleon@...]
            Sent: Wednesday, December 01, 2004 11:29 AM
            To: extremeprogramming@yahoogroups.com
            Subject: RE: [XP] [OT] Delegation and YAGNI!



            YouArentGonnaNeedIt is only one of many principles, you have to balance
            it with the others. OnceAndOnlyOnce and DoSimpleThings will lead you to
            making sure each class only has one responsibility, and you are gonna
            need that. YouArentGonnaNeedIt is not a justification to violate basic
            good OO principles like SingleResponsibilityPrinciple. In the java
            community, I'm pretty sure most people just use existing open source
            object mapping layers, in the .NET world, most are still hacking up
            their own private implementation because there isn't any really
            outstanding open source implementations yet.

            > -----Original Message-----
            > From: Stede Troisi [mailto:stedetro@...]
            > Sent: Wednesday, December 01, 2004 9:53 AM
            > To: extremeprogramming@yahoogroups.com
            > Subject: [XP] [OT] Delegation and YAGNI!
            >
            >
            > I was thinking about YAGNI yesterday. Normally, I see most
            > people create a customer class that holds domain information
            > and another class, say CustomerDb that persists the
            > information from customer to a database.
            > This makes sense, becuase if I want to persist to something
            > different (like a flat file) I can create a new class to
            > handle it while leaving the domain class intact.
            >
            > But two objects that share the same basic fields
            > (customer) seems to go against YAGNI. Is this how most people
            > solve the problem or is there a better solution?
            >
            > Thanks,
            > Stede
            >
            >
            >
            >
            > __________________________________
            > Do you Yahoo!?
            > The all-new My Yahoo! - What will yours do?
            > http://my.yahoo.com
            >
            >
            > 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
            >
            >
            >
            >
            >
            >
            >
            >


            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
          • Luiz Esmiralha
            ... You stole my words. RDBMS, YAGNI. Definitely. Oh, by the way, Prevayler was created in Brazil. :)
            Message 5 of 24 , Dec 1, 2004
              On Wed, 01 Dec 2004 18:57:14 -0000, Jeff Grigg <jeffgrigg@...> wrote:
              >
              > >> Is this how most people solve the problem or is there
              > >> a better solution?
              >
              > Sure there's a better solution: Object Prevalence. Don't persist
              > your objects to a relational database. You don't need it. ;->
              >
              > http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ
              >

              You stole my words. RDBMS, YAGNI. Definitely. Oh, by the way,
              Prevayler was created in Brazil. :)
            • Jeff Grigg
              ... And so would a good naming standard. With appropriate automation. Consider: Suppose the Customer class was stored in the CUSTOMER table, and the Employee
              Message 6 of 24 , Dec 1, 2004
                --- Steven Gordon <sagordon@a...> wrote:
                > [...] It does not feel like OnceAndOnlyOnce when I have
                > to keep the database, code, and XML descriptors in synch.
                > Of course, an Eclipse Plugin with XDOCLET-like functionality
                > could automate a lot of the synchronization issues away.

                And so would a good naming standard. With appropriate automation.

                Consider:
                Suppose the Customer class was stored in the CUSTOMER table, and the
                Employee class in the EMPLOYEE table. Why is the source of this
                cross-reference data an XML file, rather than a general rule?

                Same for columns: Suppose the 'firstName' attribute is stored in
                the 'FIRST_NAME' column. If you had naming standards and rules,
                you'd hardly need a cross-reference file.
              • Olson, Curtis B
                ... OK, but.... Legacy databases are not always so clean. Sometimes the attributes of a single object may come from more than one source table (or even from
                Message 7 of 24 , Dec 1, 2004
                  > From: Jeff Grigg [mailto:jeffgrigg@...]
                  > Sent: Wednesday, December 01, 2004 4:13 PM

                  > Consider:
                  > Suppose the Customer class was stored in the CUSTOMER table, and the
                  > Employee class in the EMPLOYEE table. Why is the source of this
                  > cross-reference data an XML file, rather than a general rule?
                  >
                  > Same for columns: Suppose the 'firstName' attribute is stored in
                  > the 'FIRST_NAME' column. If you had naming standards and rules,
                  > you'd hardly need a cross-reference file.

                  OK, but....

                  Legacy databases are not always so clean. Sometimes the attributes of a
                  single object may come from more than one source table (or even from
                  non-DBMS sources).

                  Cheers,
                  Curtis
                • Luiz Esmiralha
                  ... And I don t think that a 1 to 1 relationship between tables and classes is the best way to go.
                  Message 8 of 24 , Dec 1, 2004
                    On Wed, 1 Dec 2004 16:21:27 -0500, Olson, Curtis B <olsoncb@...> wrote:
                    >
                    > > From: Jeff Grigg [mailto:jeffgrigg@...]
                    > > Sent: Wednesday, December 01, 2004 4:13 PM
                    >
                    > > Consider:
                    > > Suppose the Customer class was stored in the CUSTOMER table, and the
                    > > Employee class in the EMPLOYEE table. Why is the source of this
                    > > cross-reference data an XML file, rather than a general rule?
                    > >
                    > > Same for columns: Suppose the 'firstName' attribute is stored in
                    > > the 'FIRST_NAME' column. If you had naming standards and rules,
                    > > you'd hardly need a cross-reference file.
                    >
                    > OK, but....
                    >
                    > Legacy databases are not always so clean. Sometimes the attributes of a
                    > single object may come from more than one source table (or even from
                    > non-DBMS sources).
                    >
                    > Cheers,
                    > Curtis
                    >

                    And I don't think that a 1 to 1 relationship between tables and
                    classes is the best way to go.
                  • Steven Gordon
                    If you are persisting in a relational database, impedance mismatch suggests that at some point the 1-1 correspondence will break down. One could elaborate the
                    Message 9 of 24 , Dec 1, 2004
                      If you are persisting in a relational database, impedance
                      mismatch suggests that at some point the 1-1 correspondence
                      will break down. One could elaborate the naming convention
                      to distinguish the names the classes and properties that
                      have a 1-1 correspondence with a database entity from those
                      that do not. Once you start down that road, it is difficult
                      to know when to stop elaborating the naming convention. In
                      any case, you would still need a mechanism to handle the
                      mismatches.

                      In a language like C#, using attributes to define the
                      database mapping might be an interesting approach that
                      would allow you to keep the mapping information with the
                      class itself. Has anybody tried using attributes for that
                      purpose?

                      -----Original Message-----
                      From: Jeff Grigg [mailto:jeffgrigg@...]
                      Sent: Wednesday, December 01, 2004 2:13 PM
                      To: extremeprogramming@yahoogroups.com
                      Subject: Re: [XP] [OT] Delegation and YAGNI! And XML xref




                      --- Steven Gordon <sagordon@a...> wrote:
                      > [...] It does not feel like OnceAndOnlyOnce when I have
                      > to keep the database, code, and XML descriptors in synch.
                      > Of course, an Eclipse Plugin with XDOCLET-like functionality
                      > could automate a lot of the synchronization issues away.

                      And so would a good naming standard. With appropriate automation.

                      Consider:
                      Suppose the Customer class was stored in the CUSTOMER table, and the
                      Employee class in the EMPLOYEE table. Why is the source of this
                      cross-reference data an XML file, rather than a general rule?

                      Same for columns: Suppose the 'firstName' attribute is stored in
                      the 'FIRST_NAME' column. If you had naming standards and rules,
                      you'd hardly need a cross-reference file.
                    • Steve Bate
                      ... I ve done it in Java using XDoclet and Hibernate. I ve also used O/R mapping attributes for automatically creating the database schema and associated
                      Message 10 of 24 , Dec 1, 2004
                        > From: Steven Gordon [mailto:sagordon@...]
                        > ...
                        > In a language like C#, using attributes to define the
                        > database mapping might be an interesting approach that
                        > would allow you to keep the mapping information with the
                        > class itself. Has anybody tried using attributes for that
                        > purpose?

                        I've done it in Java using XDoclet and Hibernate. I've also
                        used O/R mapping attributes for automatically creating
                        the database schema and associated tables. It's worked well
                        for my purposes.

                        Steve
                      • Steven Gordon
                        Did it ever constrain your ability to refactor your code? ... From: Steve Bate [mailto:steve@xplanner.org] Sent: Wednesday, December 01, 2004 4:00 PM To:
                        Message 11 of 24 , Dec 1, 2004
                          Did it ever constrain your ability to refactor your code?

                          -----Original Message-----
                          From: Steve Bate [mailto:steve@...]
                          Sent: Wednesday, December 01, 2004 4:00 PM
                          To: extremeprogramming@yahoogroups.com
                          Subject: RE: [XP] [OT] Delegation and YAGNI! And XML xref



                          > From: Steven Gordon [mailto:sagordon@...]
                          > ...
                          > In a language like C#, using attributes to define the
                          > database mapping might be an interesting approach that
                          > would allow you to keep the mapping information with the
                          > class itself. Has anybody tried using attributes for that
                          > purpose?

                          I've done it in Java using XDoclet and Hibernate. I've also
                          used O/R mapping attributes for automatically creating
                          the database schema and associated tables. It's worked well
                          for my purposes.

                          Steve
                        • Steve Bate
                          I don t think that it constrains it, although it can make it more challenging at times. The IDE doesn t always keep metadata in sync with the code after code
                          Message 12 of 24 , Dec 1, 2004
                            I don't think that it constrains it, although it can make
                            it more challenging at times. The IDE doesn't always keep
                            metadata in sync with the code after code elements have
                            been renamed. For example, metadata describing a relational
                            foreign key reference might be broken after renaming a
                            method. A good set of tests will catch these problems.

                            Steve

                            > -----Original Message-----
                            > From: Steven Gordon [mailto:sagordon@...]
                            > Sent: Wednesday, December 01, 2004 5:21 PM
                            > To: extremeprogramming@yahoogroups.com
                            > Subject: RE: [XP] [OT] Delegation and YAGNI! And XML xref
                            >
                            >
                            > Did it ever constrain your ability to refactor your code?
                            >
                            > -----Original Message-----
                            > From: Steve Bate [mailto:steve@...]
                            > Sent: Wednesday, December 01, 2004 4:00 PM
                            > To: extremeprogramming@yahoogroups.com
                            > Subject: RE: [XP] [OT] Delegation and YAGNI! And XML xref
                            >
                            >
                            >
                            > > From: Steven Gordon [mailto:sagordon@...]
                            > > ...
                            > > In a language like C#, using attributes to define the
                            > > database mapping might be an interesting approach that
                            > > would allow you to keep the mapping information with the
                            > > class itself. Has anybody tried using attributes for that
                            > > purpose?
                            >
                            > I've done it in Java using XDoclet and Hibernate. I've also
                            > used O/R mapping attributes for automatically creating
                            > the database schema and associated tables. It's worked well
                            > for my purposes.
                            >
                            > Steve
                            >
                            >
                            >
                            >
                            >
                            > 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
                            >
                            >
                            >
                            >
                            >
                            >
                          • Karl Scotland
                            ... Hi Ben, Have you looked at any of the Theory of Constraints literature? I m no expert, as I m only just discovering this aspect for myself, but it seems
                            Message 13 of 24 , Dec 2, 2004
                              > -----Original Message-----
                              > From: Ben Hogan [mailto:bwhogan@...]
                              >
                              > Does anyone have any references or other support for the
                              > suggestion that on a software development team if your goal
                              > it to deliver to market as quickly as possible, the best
                              > thing you can do is take your time, and avoid time pressure
                              > within the team?

                              Hi Ben,

                              Have you looked at any of the Theory of Constraints literature? I'm no
                              expert, as I'm only just discovering this aspect for myself, but it
                              seems that there may be something there which will help you. I'm sure
                              there's someone on this list who may be able to be more specific! I'd
                              be interested if there is aswell...

                              Karl
                            Your message has been successfully submitted and would be delivered to recipients shortly.