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

RE: [XP] Invoice layout design (was: Law of demeter)

Expand Messages
  • Torben Wölm
    Yes. This way we are back to the original thread. Should we use getters/setters or direct access to the fields. (No, please don t pick up that discussion
    Message 1 of 27 , Nov 1, 2000
    • 0 Attachment
      Yes. This way we are back to the original thread. Should we use
      getters/setters or direct access to the fields. (No, please don't pick up
      that discussion again).

      This is because the data will need to be transferred from the model to the
      controller somehow (using getters, I think we agreed on).

      I liked the excellent post from Dave Thomas (that pointed out I misread the
      Law of Demeter), stating that you can have query-methods, just do not make
      any decisions based on the returned data (requires discipline) and do not
      use the returned data to modify the object you received the data from (this
      can mostly be done by not providing the ability to do so).

      Wording the LoD this way, makes sense to me. This way we have low coupling,
      encapsulation and it is still reasonable simple -- Allen Holubs framework,
      to me, is anything but simple.

      Regards,
      Torben

      > -----Original Message-----
      > From: Malte Kroeger [SMTP:kroeger@...]
      > Sent: Tuesday, October 31, 2000 9:24 PM
      > To: extremeprogramming@egroups.com
      > Subject: Re: [XP] Invoice layout design (was: Law of demeter)
      >
      > Kevin Smith wrote:
      > >
      > > > Anyway: If you have an invoice class with line items on it. Which
      > > > object should know the layout of the printed invoice?
      >
      > Very nice line of thinking Kevin.
      >
      > For any reasonable software system I myself would always split the display
      > from the model (MVC).
      > Of course you could do it a little simpler sometimes if an invoice class
      > just prints itself, but the basic design guideling: "seperation of
      > concerns" forbids to do so.
      >
      > So just like Kevin I would use Invoice and InvoiceItem for the pure model
      > part of the problem. An Invoice doesn't know anything about display. I
      > would use something like an InvoiceFormatter or equivalent that does the
      > formatting and displaying of invoices.
      >
      > Malte
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > Ad-free courtesy of objectmentor.com
    • Dave Thomas
      ... Not really want to dilute a message that excellent post and my name in the same sentence, I fell compelled to mention that I was talking about tell,
      Message 2 of 27 , Nov 1, 2000
      • 0 Attachment
        Torben Wvlm <torben.wolm@...> writes:

        > I liked the excellent post from Dave Thomas (that pointed out I
        > misread the Law of Demeter), stating that you can have
        > query-methods, just do not make any decisions based on the returned
        > data (requires discipline) and do not use the returned data to
        > modify the object you received the data from (this can mostly be
        > done by not providing the ability to do so).

        Not really want to dilute a message that "excellent post" and my name
        in the same sentence, I fell compelled to mention that I was talking
        about "tell, don't ask". Te Law of Demeter for objects is more
        specific:

        Any method of an object should only call methods belonging to:

        1.itself.

        2.any parameters that were passed in to the method.

        3.any objects it created.

        4.any composite objects.

        Specifically missing from this list is methods belonging to
        objects that were returned from some other call.


        The two concepts are strongly related, though.


        Dave
      • Dennis Decker Jensen
        ... One pattern comes to my mind. It s the MVP (Model-Value-Presenter) Pattern which is an improvement of the MVC Pattern. It uses the concept of ValueModel.
        Message 3 of 27 , Nov 1, 2000
        • 0 Attachment
          Kevin Smith wrote:
          > I could be wrong. In fact, I could be wrong in a couple ways: 1) MVC
          > might not be as much of a given as I think, and 2) there might be a
          > couple other patterns that are equally nearly-universally beneficial.

          One pattern comes to my mind. It's the MVP (Model-Value-Presenter) Pattern
          which is an improvement of the MVC Pattern. It uses the concept of
          ValueModel.

          It's perfect to handle complexity, but it's certainly not simple (not to
          me).

          Dennis Decker Jensen

          Some useful Links about MVP/ValueModel:

          Understanding and Using ValueModels: http://c2.com/ppr/vmodels.html
          by Bobby Woolf

          http://www.object-arts.com/EducationCentre/Patterns/MVP.htm
          http://www.object-arts.com/EducationCentre/Patterns/BasicMVPComponent.htm
          http://www.object-arts.com/EducationCentre/Patterns/CompositeMVPComponent.ht
          m
          http://www.object-arts.com/EducationCentre/Patterns/ValueModel.htm
        • David Rosenstrauch
          ... Very interesting point, Jim. I think that makes sense to me. DR
          Message 4 of 27 , Nov 1, 2000
          • 0 Attachment
            At 10:54 PM 10/31/00 -0700, you wrote:
            >DTSTTCPW seems to say to use accesors at the interface between logic and
            >presentation.
            >
            >Jim


            Very interesting point, Jim. I think that makes sense to me.


            DR
          • David Rosenstrauch
            ... BTW, I m assuming composite objects not to be in the Design Patterns Composite sense. By composite objects they mean ... class instance variables? DR
            Message 5 of 27 , Nov 1, 2000
            • 0 Attachment
              At 05:57 AM 11/1/00 -0600, you wrote:
              > Any method of an object should only call methods belonging to:
              >
              > 1.itself.
              >
              > 2.any parameters that were passed in to the method.
              >
              > 3.any objects it created.
              >
              > 4.any composite objects.


              BTW, I'm assuming "composite objects" not to be in the Design Patterns Composite sense. By composite objects they mean ... class instance variables?


              DR
            • Andrew Hunt
              ... Yes, or a local variable held on the stack, for instance. Our example in The Pragmatic Programmer shows: class Demeter { private: A *a; int func();
              Message 6 of 27 , Nov 1, 2000
              • 0 Attachment
                >> Any method of an object should only call methods belonging to:
                >>
                >> 1.itself.
                >>
                >> 2.any parameters that were passed in to the method.
                >>
                >> 3.any objects it created.
                >>
                >> 4.any composite objects.
                >
                >
                >BTW, I'm assuming "composite objects" not to be in the Design Patterns Composite sense. By composite objects they mean ... class instance variables?


                Yes, or a local variable held on the stack, for instance.
                Our example in "The Pragmatic Programmer" shows:

                class Demeter {
                private:
                A *a;
                int func();
                public:
                void example(B& b);
                }

                void Demeter::example(B& b) {
                C c;
                int f = func(); // okay, itself
                b.invert(); // okay, parameter
                a = new A();
                a->setActive(); // okay, created object
                c.print(); // okay, directly held
                }

                Your mileage may vary, of course, but the general principle
                is well stated by Robert Frost: "Good fences make good neighbors".
                :-)

                /\ndy
              • David Rosenstrauch
                ... Got it. Thanks! DR
                Message 7 of 27 , Nov 1, 2000
                • 0 Attachment
                  At 12:08 PM 11/1/00 -0500, you wrote:
                  > >BTW, I'm assuming "composite objects" not to be in the Design Patterns Composite sense. By composite objects they mean ... class instance variables?
                  >
                  >
                  >Yes, or a local variable held on the stack, for instance.


                  Got it. Thanks!


                  DR
                • Kevin Smith
                  ... So if I understand this correctly... Given classes Invoice, InvoiceItem, and InvoicePrinter, if you call InvoicePrinter.PrintInvoice(Invoice), then: 1.
                  Message 8 of 27 , Nov 1, 2000
                  • 0 Attachment
                    > T[h]e Law of Demeter for objects is more specific:
                    >
                    > Any method of an object should only call methods belonging to:
                    > 1.itself.
                    > 2.any parameters that were passed in to the method.
                    > 3.any objects it created.
                    > 4.any composite objects.
                    >
                    > Specifically missing from this list is methods belonging to
                    > objects that were returned from some other call.

                    So if I understand this correctly...

                    Given classes Invoice, InvoiceItem, and InvoicePrinter, if you call
                    InvoicePrinter.PrintInvoice(Invoice), then:
                    1. Calling Invoice.GetInvoiceNumber is perfectly ok.
                    2. Calling Invoice.GetInvoiceItem is ok.
                    3. Calling InvoiceItem.GetPartNumber would break the law, but
                    4. Calling InvoicePrinter.PrintItem(InvoiceItem) would be ok, and
                    5. PrintItem calling InvoiceItem.GetPartNumber would be ok.

                    So the law essentially forces you to delegate all the handling of the
                    item itself into a separate method. While that doesn't really seem
                    necessary, I can see that it would strongly encourage small methods,
                    which could help testability.

                    Did I get it right???

                    Kevin
                  • Kevin Smith
                    ... A two-minute scan of the links didn t reveal any comparison between MVC and MVP. Descriptions of MVP sounded close enough to my memory of MVC that I
                    Message 9 of 27 , Nov 1, 2000
                    • 0 Attachment
                      > One pattern comes to my mind. It's the MVP (Model-Value-Presenter) Pattern
                      > which is an improvement of the MVC Pattern. It uses the concept of
                      > ValueModel.

                      A two-minute scan of the links didn't reveal any comparison between
                      MVC and MVP. Descriptions of MVP sounded close enough to my memory of
                      MVC that I couldn't understand the difference. View==Presenter. The
                      controller disappears and a "value" pops up.

                      You mention that MVP is improved. What are the improvements? Why is
                      "value" not part of the model itself? With no controller, is this
                      closer to the Microsoft (MFC) Document/View pattern?

                      Kevin
                    • Andrew Hunt
                      ... Looks okay from this distance :-) Remember, the key isn t about just getting data, it s what you do with it -- it s about the locus of control. ... It
                      Message 10 of 27 , Nov 2, 2000
                      • 0 Attachment
                        >So if I understand this correctly...
                        >
                        >Given classes Invoice, InvoiceItem, and InvoicePrinter, if you call
                        >InvoicePrinter.PrintInvoice(Invoice), then:
                        >1. Calling Invoice.GetInvoiceNumber is perfectly ok.
                        >2. Calling Invoice.GetInvoiceItem is ok.
                        >3. Calling InvoiceItem.GetPartNumber would break the law, but
                        >4. Calling InvoicePrinter.PrintItem(InvoiceItem) would be ok, and
                        >5. PrintItem calling InvoiceItem.GetPartNumber would be ok.

                        Looks okay from this distance :-) Remember, the key isn't
                        about just getting data, it's what you do with it -- it's about
                        the locus of control.

                        >So the law essentially forces you to delegate all the handling of the
                        >item itself into a separate method. While that doesn't really seem
                        >necessary, I can see that it would strongly encourage small methods,
                        >which could help testability.

                        It encourages high cohesion and low coupling, two of my favorite
                        subjects. It also promotes many small "useless" methods that simply
                        delegate, and this can sometimes exact an unacceptable performance
                        penalty. So, like everything else, you've got you use your head
                        and not be the "Small boy with a Demeter" as seen in the other threads :-)

                        /\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)
                        --
                      • Dennis Decker Jensen
                        ... Sorry. I was a little to hasty with the links. To answer you very (very) shortly: Take MVC (diagram) and turn it 90 degrees, wrap the actual model with a
                        Message 11 of 27 , Nov 2, 2000
                        • 0 Attachment
                          Kevin Smith wrote:
                          > A two-minute scan of the links didn't reveal any comparison between
                          > MVC and MVP. Descriptions of MVP sounded close enough to my memory of
                          > MVC that I couldn't understand the difference. View==Presenter. The
                          > controller disappears and a "value" pops up.
                          >
                          > You mention that MVP is improved. What are the improvements? Why is
                          > "value" not part of the model itself? With no controller, is this
                          > closer to the Microsoft (MFC) Document/View pattern?

                          Sorry. I was a little to hasty with the links.

                          To answer you very (very) shortly: Take MVC (diagram) and turn it 90
                          degrees, wrap the actual model with a generic wrapper/adapter called
                          ValueModel, and you have MVP.

                          The real improvement comes with ValueModel, which make both View,
                          (Value-)Model and Presenter much more plugable, flexible and decoupled.
                          Observer now observes the ValueModel instead of the actual wrapped model.

                          Also (as I understand) if the actual model needs to signal it's own domain
                          events, ValueModel is capable of transforming the events in to more generic
                          events.

                          The links below are to more generel descriptions and overviews -- they
                          communicate better and give better answers.

                          A comparison between MVC and MVP, and why the latter is an improvement:
                          http://www.object-arts.com/EducationCentre/Overviews/MVC.htm

                          A short description and definition of the MVP Triad:
                          http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm

                          ValueModels as generic wrappers around the actual model(s):
                          http://www.object-arts.com/EducationCentre/Overviews/ValueModels.htm


                          Dennis Decker Jensen
                        • Erik Meade
                          Interesting, just yesterday I did some refactoring whose results match MVP. Thanks for the link. -- Erik Meade emeade@objectmentor.com Senior
                          Message 12 of 27 , Nov 2, 2000
                          • 0 Attachment
                            Interesting, just yesterday I did some refactoring whose
                            results match MVP. Thanks for the link.
                            --
                            Erik Meade emeade@...
                            Senior Consultant Object Mentor, Inc.

                            > -----Original Message-----
                            > From: Dennis Decker Jensen [mailto:dennisdecker@...]
                            >
                            > The links below are to more generel descriptions and overviews -- they
                            > communicate better and give better answers.
                            >
                            > A comparison between MVC and MVP, and why the latter is an improvement:
                            > http://www.object-arts.com/EducationCentre/Overviews/MVC.htm
                            >
                            > A short description and definition of the MVP Triad:
                            >
                            http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm

                            ValueModels as generic wrappers around the actual model(s):
                            http://www.object-arts.com/EducationCentre/Overviews/ValueModels.htm


                            Dennis Decker Jensen
                          Your message has been successfully submitted and would be delivered to recipients shortly.