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

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

Expand Messages
  • Torben Wölm
    I think this is a very interesting point. But I don t know if this is the place to discuss it? Is there a OO Design list with as many knowledgefull (is that
    Message 1 of 27 , Oct 31, 2000
    • 0 Attachment
      I think this is a very interesting point. But I don't know if this is the
      place to discuss it? Is there a OO Design list with as many knowledgefull
      (is that really a word?) participants as this list?

      Anyway: If you have an invoice class with line items on it. Which object
      should know the layout of the printed invoice?

      Following the law of demeter, I should send a printstream to the line-item
      that knows how to print itself on the invoice. But this way the knowledge of
      the layout is suddenly spread to several objects (Customer for address and
      so on). The layout always changes so how do we solve this in a good way? And
      what do we do when the line item must also support printing on an inventory
      list?

      Should we define small "memento"-classes in the same package as the
      line-item class that have access to protected getters/setters, so they can
      initialize themselves in a proper way? These memento-classes are then
      specialised to output the information in certain ways... This way the
      knowledge of the line-items state is preserved in the package and not
      accessible to other classes.

      Is this stupid? Should we just make the getters public instead?

      Or should we create special Layout classes that know how to format the
      line-item on different outputs?

      I know Allen Holub has written a lot about making objects responsible for
      their own interface. But is that a good idea? How would you implement a
      Customer class that should be able to display itself on invoices, in text
      fields, in list boxes and so on? (And do you really want your Customer class
      to be knowledgeable of most of the GUI-classes?)

      I never really got good answers on these topics. Anyone who knows where to
      find such information or wants to share experiences?

      Regards,
      Torben

      > -----Original Message-----
      > From: David Rosenstrauch [SMTP:darose@...]
      > Sent: Monday, October 30, 2000 3:20 PM
      > To: extremeprogramming@egroups.com
      > Subject: Re: [XP] RE: Getters, setters & "Do The Simplest Thing That
      > Could Pos sibly Work"
      >
      > At 09:44 PM 10/22/00 +0100, you wrote:
      > >e.g. Do you really need to get the name from a person object, or do you
      > only
      > >need it for some report? If so then the following is better:
      > >
      > >aPerson.writeName(reportStream).
      >
      >
      > Just a thought/devil's advocate argument, though:
      >
      > If you do this sort of thing a lot, aren't you then cluttering up the
      > Person class with a lot of unrelated functionality? After all, the Person
      > may have no other use for the reportStream other than with this specific
      > calling object. And then if you want to write the name to a datbase, you
      > might have to add:
      > aPerson.writeName(aDatabaseConnection). etc. etc.
      >
      > Pretty soon you could be loading up the Person with a multitude of stray
      > methods - one for each way that the name attribute will be used.
      >
      > A getter, OTOH, would just provide one single access point for the name
      > attribute that multiple callers, each with a different usage, can all
      > share.
      >
      > TSTTCPW, no?
      >
      >
      > DR
      >
    • Ron Jeffries
      ... Well, it seems intuitively like SOMEONE is going to know something about someone else, at a detailed level. We have named items (instance variables or
      Message 2 of 27 , Oct 31, 2000
      • 0 Attachment
        At 10:57 AM 10/31/00 +0100, Torben Wölm wrote:
        >Anyway: If you have an invoice class with line items on it. Which object
        >should know the layout of the printed invoice?

        Well, it seems intuitively like SOMEONE is going to know something about
        someone else, at a detailed level.

        We have named items (instance variables or computed fields) in the Invoice:
        vendor, quantity, unit price, extended price, and so on.

        We want a line of output that shows vendor as 30A, quantity as 5I, unit
        price as 5.2D, extended price as 5.2D.

        We would like formatting of integers to be part of Integer (perhaps), or to
        have all formatting be part of some massive formatting object.

        If the various elementary objects know how to print themselves formatted,
        so that we could have said:

        void printInvoice( Stream stream) {
        vendor.print(stream, vendorFormat);
        quantity.print(stream, quantityFormat);
        ...
        }

        Then we need to get the detailed formatting info somewhere. We could have a
        Format object that accepts string field names as inputs and answers a
        format, and use it

        vendorFormat = format.for("name");
        vendor.print(stream, vendorFormat);

        But then we still have the linkage of the names, though we have at least
        not exported our name quantity and such to other objects.

        What might be a better way?

        Ronald E Jeffries
        http://www.XProgramming.com
        http://www.objectmentor.com
      • David Rosenstrauch
        ... Sigh. I give up - what? I m not being sarcastic. I actually find this thread interesting, and I don t know what answer you re trying to lead us to.
        Message 3 of 27 , Oct 31, 2000
        • 0 Attachment
          At 07:57 AM 10/31/00 -0500, you wrote:
          >What might be a better way?
          >
          >Ronald E Jeffries


          Sigh. I give up - what?

          I'm not being sarcastic. I actually find this thread interesting, and I don't know what answer you're trying to lead us to. These are problems I deal with every day, and I'm trying to improve my thinking in this area.

          Using the concrete example you've mentioned, what is the better design that you're alluding to?


          DR
        • Tom Ayerst
          I don t know either. After a little reflection this seems like a hard problem when dealt with in the abstract (several different reports from the same objects,
          Message 4 of 27 , Oct 31, 2000
          • 0 Attachment
            I don't know either.

            After a little reflection this seems like a hard problem when dealt
            with in the abstract (several different reports from the same
            objects, dependancies, demeter etc.). I suspect it might actually be
            easier to do it with several concrete refactorings directed towards
            some real objectives.

            Tom

            --- In extremeprogramming@egroups.com, David Rosenstrauch
            <darose@o...> wrote:
            > At 07:57 AM 10/31/00 -0500, you wrote:
            > >What might be a better way?
            > >
            > >Ronald E Jeffries
            >
            >
            > Sigh. I give up - what?
            >
            > I'm not being sarcastic. I actually find this thread interesting,
            and I don't know what answer you're trying to lead us to. These are
            problems I deal with every day, and I'm trying to improve my thinking
            in this area.
            >
            > Using the concrete example you've mentioned, what is the better
            design that you're alluding to?
            >
            >
            > DR
          • Kevin Smith
            ... I would think about a few questions to arrive at a decision (not in any particular order): 1. How likely is it that we will want to print the same data in
            Message 5 of 27 , Oct 31, 2000
            • 0 Attachment
              > Anyway: If you have an invoice class with line items on it. Which object
              > should know the layout of the printed invoice?

              I would think about a few questions to arrive at a decision (not in
              any particular order):
              1. How likely is it that we will want to print the same data in
              different formats, or to change the format frequently? (1)
              2. How can I leverage existing code?
              3. What design would be the easiest to test?
              4. What encourages OAOO (once and only once) code?

              Assuming the answer to #1 is "likely", then I would want to keep the
              layout knowlege isolated. I would not want each object to know how to
              print itself because a) it might need to know how to print itself in
              several different ways, and b) changing a layout would require
              touching a lot of objects. See note (1) below.

              #2: If we already have an invoice object (perhaps the first story was
              related to data input, or importing from a legacy system), then
              invoice model objects with accesors probably already exist. Adding a
              new report object seeems simplest.

              If this is our very first story, then I would think "how can I very
              simply print an invoice?" Well, the simplest thing that I can think
              of would be to create an invoice-printing object that takes care of
              everything. I would probably want to extract the "model" out of the
              printing object for testability.

              For #3, it seems like the easiest would be that the invoice "model"
              objects could be queried to obtain their values. That's really easy
              to test. Then some kind of report-writing object could be fed an
              invoice that contains hard-coded values and the output could be
              binary-compared with a known good result.

              Regarding #4, if you distribute the layout knowlege into multiple
              objects, then each object needs to know what font you want to use,
              what margins to use, whether it should put a blank line above itself
              or below itself, etc. Seems like that would be harder to code OAOO.
              Possible, perhaps, but it seems like you would have to invent some
              complex mechanisms, which I would prefer to avoid.

              So I would have simple Invoice and InvoiceItem classes that have some
              form of read- and write- accessors. Beyond that, I'd probably want to
              write some code to figure out exactly what accessors I would need and
              which would be public.

              Kevin

              (1) Now that I'm about to hit send, it seems that this line of
              thinking is dangerously close to violating YAGNI. I probably
              shouldn't be thinking about such things this early in the game.
              Perhaps in passing, but not deeply. Please use question #1 as a bad
              example, and focus on the others.
            • Ron Jeffries
              ... I wasn t being Socratic OR sarcastic. I threw out a design that might work, but that had drawbacks. I want to see what someone knows that s better. It
              Message 6 of 27 , Oct 31, 2000
              • 0 Attachment
                At 10:46 AM 10/31/00 -0500, David Rosenstrauch wrote:
                >Sigh. I give up - what?
                >
                >I'm not being sarcastic. I actually find this thread interesting, and I
                >don't know what answer you're trying to lead us to. These are problems I
                >deal with every day, and I'm trying to improve my thinking in this area.
                >
                >Using the concrete example you've mentioned, what is the better design
                >that you're alluding to?

                I wasn't being Socratic OR sarcastic. I threw out a design that might work,
                but that had drawbacks. I want to see what someone knows that's better.

                It would be unlike me to offer less than my best. I realize that's hard to
                realize, since my best is so often just nearly good. ;->

                R



                Ronald E Jeffries
                http://www.XProgramming.com
                http://www.objectmentor.com
              • Mark Wilden
                ... From: Torben Wölm ... of ... And ... inventory ... This sounds insane to me (and, I suspect, to you, too). A customer name
                Message 7 of 27 , Oct 31, 2000
                • 0 Attachment
                  ----- Original Message -----
                  From: "Torben Wölm" <torben.wolm@...>


                  > Following the law of demeter, I should send a printstream to the line-item
                  > that knows how to print itself on the invoice. But this way the knowledge
                  of
                  > the layout is suddenly spread to several objects (Customer for address and
                  > so on). The layout always changes so how do we solve this in a good way?
                  And
                  > what do we do when the line item must also support printing on an
                  inventory
                  > list?

                  This sounds insane to me (and, I suspect, to you, too).

                  A customer name is just a piece of data, like an integer. Would we have a
                  special Integer class, from which we'd subclass OrderQuantity, so that we
                  could send OrderQuantity an InvoicePrintStream?

                  > Is this stupid? Should we just make the getters public instead?

                  I think so. It's the simplest thing.
                • David Rosenstrauch
                  ... My apologies, then. I mistook the intent of your question What might be a better way? as implying that there was a better way that you were trying to
                  Message 8 of 27 , Oct 31, 2000
                  • 0 Attachment
                    At 12:22 PM 10/31/00 -0500, you wrote:
                    >I wasn't being Socratic OR sarcastic. I threw out a design that might work,
                    >but that had drawbacks. I want to see what someone knows that's better.
                    >
                    >It would be unlike me to offer less than my best. I realize that's hard to
                    >realize, since my best is so often just nearly good. ;->
                    >
                    >R


                    My apologies, then. I mistook the intent of your question "What might be a better way?" as implying that there was a better way that you were trying to point us towards.


                    DR
                  • Mark Wilden
                    ... From: Ron Jeffries ... I think this causes more coupling between objects, rather than less. In general, when there s a container
                    Message 9 of 27 , Oct 31, 2000
                    • 0 Attachment
                      ----- Original Message -----
                      From: "Ron Jeffries" <ronjeffries@...>

                      >If the various elementary objects know how to print themselves formatted,
                      >so that we could have said:

                      >void printInvoice( Stream stream) {
                      > vendor.print(stream, vendorFormat);
                      > quantity.print(stream, quantityFormat);
                      > ...
                      >}

                      I think this causes more coupling between objects, rather than less. In
                      general, when there's a container relationship, I like the container to make
                      the decisions. In your example, who's determining where on the invoice the
                      vendor is printed? From the code above, it's the vendor. Well, that's not
                      going to scale too well to N types of invoices.
                    • Ron Jeffries
                      ... I was kind of thinking it was part of the format. But I m not here to support the idea, just to get things started. Ronald E Jeffries
                      Message 10 of 27 , Oct 31, 2000
                      • 0 Attachment
                        At 09:35 AM 10/31/00 -0800, Mark Wilden wrote:
                        > >void printInvoice( Stream stream) {
                        > > vendor.print(stream, vendorFormat);
                        > > quantity.print(stream, quantityFormat);
                        > > ...
                        > >}
                        >
                        >I think this causes more coupling between objects, rather than less. In
                        >general, when there's a container relationship, I like the container to make
                        >the decisions. In your example, who's determining where on the invoice the
                        >vendor is printed? From the code above, it's the vendor. Well, that's not
                        >going to scale too well to N types of invoices.

                        I was kind of thinking it was part of the format. But I'm not here to
                        support the idea, just to get things started.



                        Ronald E Jeffries
                        http://www.XProgramming.com
                        http://www.objectmentor.com
                      • Malte Kroeger
                        ... 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
                        Message 11 of 27 , Oct 31, 2000
                        • 0 Attachment
                          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
                        • jas
                          ... Either the invoice or the printedInvoice or the layout of the printedInvoice. ... Various elementary objects cannot know how to print themselves formatted,
                          Message 12 of 27 , Oct 31, 2000
                          • 0 Attachment
                            Ron Jeffries wrote:
                            >
                            > At 10:57 AM 10/31/00 +0100, Torben Wölm wrote:
                            > >Anyway: If you have an invoice class with line items on it. Which object
                            > >should know the layout of the printed invoice?

                            Either the
                            invoice
                            or the
                            printedInvoice
                            or the
                            layout
                            of the
                            printedInvoice.

                            > Well, it seems intuitively like SOMEONE is going to know something about
                            > someone else, at a detailed level.
                            >
                            > We have named items (instance variables or computed fields) in the Invoice:
                            > vendor, quantity, unit price, extended price, and so on.
                            >
                            > We want a line of output that shows vendor as 30A, quantity as 5I, unit
                            > price as 5.2D, extended price as 5.2D.
                            >
                            > We would like formatting of integers to be part of Integer (perhaps), or to
                            > have all formatting be part of some massive formatting object.
                            >
                            > If the various elementary objects know how to print themselves formatted,

                            Various elementary objects cannot know how to print themselves formatted,
                            as "formatted" is not a property of "elementary objects", it is a property
                            of the thing they are being printed on.

                            An elementary object might know how to print itself
                            on a stream, in various particular formats, but this is not the same
                            as "formatted".

                            > so that we could have said:
                            >
                            > void printInvoice( Stream stream) {
                            > vendor.print(stream, vendorFormat);
                            > quantity.print(stream, quantityFormat);
                            > ...
                            > }
                            >
                            > Then we need to get the detailed formatting info somewhere. We could have a
                            > Format object that accepts string field names as inputs and answers a
                            > format, and use it
                            >
                            > vendorFormat = format.for("name");
                            > vendor.print(stream, vendorFormat);
                            >
                            > But then we still have the linkage of the names, though we have at least
                            > not exported our name quantity and such to other objects.
                            >
                            > What might be a better way?

                            It may help to split the concept of "invoice",
                            distinguishing between

                            a bunch of data, relationships, and behavior representing
                            the parties to, and items, quantities, prices, terms of an order

                            vs

                            a bunch of rules and instructions representing
                            the process of getting the aforementioned "bunch of data etc."
                            to show up on a piece of paper
                            in such a way that it matches
                            the "graphical layout / design "
                            of the "printed invoice form"
                            we presently choose to use in this situation

                            as one of these things deals with the business as business,
                            the other deals with an artifact sometimes (or currently) used by this business.

                            The basis of the linkage between them is more of a whim,
                            as they do not change together in any way that is logically related
                            to the abstract concept of the business.

                            Hence the two conceptual views should not be co-located.

                            Printing an invoice requires (at least) two distinct things:

                            1) a transaction ready to be "invoiced"
                            2) an idea of how we want this first thing printed

                            Realizing that (2) is a concept in it's own right
                            helps in the process of discovering

                            Which object should know the layout of the printed invoice?

                            -jim
                          • Jim Little
                            From: Torben Wölm [ Tell, don t ask discussion] ... I ve also been struggling with this issue. My app is mostly just a thin
                            Message 13 of 27 , Oct 31, 2000
                            • 0 Attachment
                              From: "Torben Wölm" <torben.wolm@...>
                              ["Tell, don't ask" discussion]
                              > Anyway: If you have an invoice class with line items on it. Which object
                              > should know the layout of the printed invoice?

                              I've also been struggling with this issue. My app is mostly just a thin
                              layer over a database, which means that, in a lot of cases, there is no
                              complex logic. But at the same time, I have multiple presentations of that
                              data. I want the presentations to be localized and separated. ("Localized"
                              as in "all the code in one spot," not as in internationalization.)

                              So far, the simplest thing that has worked has been accessors and mutators.
                              (I like to use those words instead of "getters" and "setters" because it
                              makes me look smart, and lord knows I could use the help.) But that leaves
                              me with knawing pangs of guilt and the feeling that my "objects" are
                              glorified structs.

                              SO... what I've considered doing is having a "render" method that passes in
                              XSL.

                              Overkill? Yup, certainly. That's why we haven't done it. :)

                              DTSTTCPW seems to say to use accesors at the interface between logic and
                              presentation.

                              Jim
                            • Kevin Smith
                              ... I was just thinking about this yesterday. MVC is the one pattern that I can think of that I would almost always end up using right from the start. Probably
                              Message 14 of 27 , Oct 31, 2000
                              • 0 Attachment
                                > For any reasonable software system I myself would always split the display
                                > from the model (MVC).

                                I was just thinking about this yesterday. MVC is the one pattern that
                                I can think of that I would almost always end up using right from the
                                start. Probably because it helps testability so much. Well, I
                                probably don't actually use the whole MVC pattern (GoF is at the
                                office so I can't see what they say). I do tend to split the "engine"
                                apart from any external interfaces (UI, import, printing, etc).

                                Most of the other patterns seem to add complexity (perhaps justified,
                                so solve particular problems). MVC seems to be a pure simplification,
                                with few if any drawbacks in most cases.

                                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.

                                Kevin
                              • Kevin Smith
                                ... Three cheers for all the glorified structs of the world! Hip hip Hooray! Seriously, if those classes are working, testable, and communicate what they are
                                Message 15 of 27 , Oct 31, 2000
                                • 0 Attachment
                                  > So far, the simplest thing that has worked has been accessors and mutators.
                                  > (I like to use those words instead of "getters" and "setters" because it
                                  > makes me look smart, and lord knows I could use the help.) But that leaves
                                  > me with knawing pangs of guilt and the feeling that my "objects" are
                                  > glorified structs.

                                  Three cheers for all the glorified structs of the world! Hip hip
                                  Hooray!

                                  Seriously, if those classes are working, testable, and communicate
                                  what they are doing, then they are perfect. Turn them from guilt into
                                  a guilty pleasure.

                                  Kevin
                                • 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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.