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

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