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

RE: [XP][OT?] Law of demeter (was: Getters, setters & "Do The Sim ples t Thing That Could Pos sibly Work")

Expand Messages
  • Torben Wölm
    I really hoped some members of the Pragmatic Programmers Gang would kick in here. It was some of them telling me to read their Tell, Don t. Ask article,
    Message 1 of 6 , Oct 31, 2000
    • 0 Attachment
      I really hoped some members of the "Pragmatic Programmers Gang" would kick
      in here.

      It was some of them telling me to read their "Tell, Don't. Ask" article, and
      I like the Law of Demeter, but never succesfully used it.

      I start out with it, but sooner or later I need a way to just get the id of
      an invoice to display in a list or something, and whoops - compliance with
      law of Demeter gone...

      So if the Pragmatic Programmers could/would give some advice on this
      specific example?

      Torben
      Practising Programmer... (-;
    • Dave Thomas
      ... This is the XP list, so we re not allowed to give advice, just ask questions. However, to my mind, and invoice class is just that: a collection of the
      Message 2 of 6 , Nov 1, 2000
      • 0 Attachment
        Torben Wvlm <torben.wolm@...> writes:

        > So if the Pragmatic Programmers could/would give some advice on this
        > specific example?

        This is the XP list, so we're not allowed to give advice, just ask
        questions.

        However, to my mind, and invoice class is just that: a collection
        of the information associated with an invoice. If I wanted to
        represent that invoice on the screen, on a printer, and to export it
        in XML, would I want to add support for all that to the invoice class
        itself? How would I then handle maintenance when new representations
        came along in the future? Would it instead be reasonable to implement
        a set of InvoiceViewer classes: InvoiceScreenViewer,
        InvoicePrintViewer, InvoiceXMLViewer, and so on?

        Most of the time, the viewer would not break the LoD when
        interrogating the actual invoice. But if it did sometimes, would that
        be such a crime, given the tightly coupled nature of the classes?

        Mostly it's good to decouple, obey the LoD, and tell, not
        ask. Sometimes it's better to produce sets of classes with tight
        coupling. These sets are then tidy little packages of classes that are
        themselves decoupled etc. from the rest of the system.

        In the pragmatic world, the measure of a good rule is how well is
        breaks. When you break the rule that says 'decouple classes', break it
        big time and tightly couple instead.

        Given that I'm answering this at 3am after feeding Henry, I may have
        missed the point totally. Was this what you were after?


        Dave
      • Dave Thomas
        ... Just one more point on this... Tell, don t ask doesn t say that you can t interrogate an object s state. What is says is that you shouldn t use that
        Message 3 of 6 , Nov 1, 2000
        • 0 Attachment
          Torben Wvlm <torben.wolm@...> writes:

          > I really hoped some members of the "Pragmatic Programmers Gang" would kick
          > in here.
          >
          > It was some of them telling me to read their "Tell, Don't. Ask" article, and
          > I like the Law of Demeter, but never succesfully used it.

          Just one more point on this...

          "Tell, don't ask" doesn't say that you can't interrogate an object's
          state. What is says is that you shouldn't use that interrogated value
          subsequently to change the state in the object. To quote from the web
          page (http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html):

          The problem is that, as the caller, you should not be making
          decisions based on the state of the called object that result in
          you then changing the state of the object. The logic you are
          implementing is probably the called object's responsibility, not
          yours. For you to make decisions outside the object violates its
          encapsulation.


          Thus

          total = invoice.getTotal

          is OK

          total = invoice.getTotal
          invoice.setTotal(total * invoice.getDiscount)

          is not. Instead write

          invoice.applyCurrentDiscount



          Regards


          Dave
        • Torben Wölm
          So classes acting as read-only structs are still complying with the law of Demeter? OK, I m going a little far out there. But if I understand you right, I ll
          Message 4 of 6 , Nov 1, 2000
          • 0 Attachment
            So classes acting as read-only structs are still complying with the law of
            Demeter?

            OK, I'm going a little far out there.

            But if I understand you right, I'll be fine (that is complying with LoD) if
            I use an Invoice-print class that reads state-information from the invoice
            class and print it out (directly without processing the obtained data).

            Then maybe I actually followed The Law succesfully, after all... (-:

            Regards,
            Torben


            > -----Original Message-----
            > From: Dave Thomas [SMTP:Dave@...]
            > Sent: Wednesday, November 01, 2000 10:38 AM
            > To: extremeprogramming@egroups.com
            > Subject: Re: [XP][OT?] Law of demeter (was: Getters, setters & "Do
            > The Sim ples t Thing That Could Pos sibly Work")
            >
            > Torben Wvlm <torben.wolm@...> writes:
            >
            > > I really hoped some members of the "Pragmatic Programmers Gang" would
            > kick
            > > in here.
            > >
            > > It was some of them telling me to read their "Tell, Don't. Ask" article,
            > and
            > > I like the Law of Demeter, but never succesfully used it.
            >
            > Just one more point on this...
            >
            > "Tell, don't ask" doesn't say that you can't interrogate an object's
            > state. What is says is that you shouldn't use that interrogated value
            > subsequently to change the state in the object. To quote from the web
            > page (http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html):
            >
            > The problem is that, as the caller, you should not be making
            > decisions based on the state of the called object that result in
            > you then changing the state of the object. The logic you are
            > implementing is probably the called object's responsibility, not
            > yours. For you to make decisions outside the object violates its
            > encapsulation.
            >
            >
            > Thus
            >
            > total = invoice.getTotal
            >
            > is OK
            >
            > total = invoice.getTotal
            > invoice.setTotal(total * invoice.getDiscount)
            >
            > is not. Instead write
            >
            > invoice.applyCurrentDiscount
            >
            >
            >
            > Regards
            >
            >
            > Dave
            >
          • Andrew Hunt
            ... Dave s the posting machine , but I d like to chime in a few thoughts as well... (Okay, my son was up from 2 to 4 as well, but *I* went back to sleep ;-)
            Message 5 of 6 , Nov 1, 2000
            • 0 Attachment
              >Torben Wvlm <torben.wolm@...> writes:
              >
              >> I really hoped some members of the "Pragmatic Programmers Gang" would kick
              >> in here.

              Dave's the "posting machine", but I'd like to chime in a few thoughts as well...
              (Okay, my son was up from 2 to 4 as well, but *I* went back to sleep ;-)

              >> It was some of them telling me to read their "Tell, Don't. Ask" article, and
              >> I like the Law of Demeter, but never succesfully used it.
              >
              >Just one more point on this...
              >
              >"Tell, don't ask" doesn't say that you can't interrogate an object's
              >state. What is says is that you shouldn't use that interrogated value
              >subsequently to change the state in the object. To quote from the web
              >page (http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html):

              It can also be helpful to use Command/Query separation -- purposefully keeping
              Query methods separate from Command methods (which may change the state of
              the object). It's important to keep Query methods side-effect free, but it's
              okay to have a Command return a value as a convenience.

              This can make it easier to spot the pattern where you Query an object, make
              a decision, then inappropriately issue a Command back to the object again.

              Another interesting side note: I wrote the "Tell, Don't Ask" paper as a result
              of reading a book on Smalltalk that advocated the principle. Given XP's origins
              in Smalltalk habits, it sort of makes you wonder if all good things can trace
              their origins back to Smalltalk :-)

              /\ndy


              --
              Andrew Hunt, The Pragmatic Programmers, LLC.
              Innovative Object-Oriented Software Development
              web: http://www.pragmaticprogrammer.com email: andy@...
              --
              Books by Andrew Hunt and David Thomas:
              "The Pragmatic Programmer" (Addison-Wesley 2000)
              "Programming Ruby" (Addison-Wesley 2001)
              --
            • David Rosenstrauch
              ... Can t speak for the person who posted the question. But as an interested party in the thread I say Yes. Thanks! DR
              Message 6 of 6 , Nov 1, 2000
              • 0 Attachment
                At 02:59 AM 11/1/00 -0600, you wrote:
                >In the pragmatic world, the measure of a good rule is how well is
                >breaks. When you break the rule that says 'decouple classes', break it
                >big time and tightly couple instead.
                >
                >Given that I'm answering this at 3am after feeding Henry, I may have
                >missed the point totally. Was this what you were after?
                >
                >
                >Dave


                Can't speak for the person who posted the question. But as an interested party in the thread I say "Yes. Thanks!"


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