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
  • 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 1 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 2 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 3 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 4 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 5 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.