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

Re: Suggestion/ideas for refactoring? (some design approach Qs too)

Expand Messages
  • Adam Judson
    ... I don t like Scout. This design seems to mimic the real world very closely, which is a good thing, but the consequence, as it often is when we model
    Message 1 of 4 , Oct 2 8:54 AM
      --- In extremeprogramming@y..., Paul Michali <pcm@c...> wrote:
      > I'm a little stuck right now, not sure which way to alter my class
      > structure. Currently I have these (major) classes:
      >
      > Scout

      I don't like Scout. This design seems to mimic the real world very
      closely, which is a good thing, but the consequence, as it often
      is when we model inanimate objects, is a god class.

      In the same way, if we were to model a fruit stand, we might be
      tempted to create an owner class, that knows how to weigh/price
      each type of fruit.

      I think you should throw away the scout. The only reason you need
      him in the real world is because the road segments can't talk.

      > PathSegment

      You obviously need this information, but maybe it should be kept
      closer to the information about primary/secondary paths, and the
      road conditions?

      > ScoutingReport

      I think you should keep the final information where you make the
      decision about what info to report.

      You also keep talking about multiple paths. You have primary, and
      several secondaries. This is true, but I think it is making it
      harder to see where to put the "find me the best path" logic.

      I think you only have one path. The path you should take home. This
      path CONTAINS several choices, but in the end there is only one path.
      Now it seems obvious that this object should know what the best
      route is right now.

      In terms of testing, I can see two places that will cause some
      problems. Getting the data from the HTML page, and sending the
      e-mail message. If I remember correctly, you already have the
      e-mail portion covered. That leaves the HTML.

      My advise here is: keep it seperate from the path objects. Have an
      agent, or path-segment objects that retrieve AND parse HTML. Have
      them provide output in a standard format that your path objects
      can understand (e.g. a hash table of strings - ROAD1, GOOD, ROAD2,
      FAIR etc). Now it should be easy to create a static hash table to
      pass to your path objects to test.

      I wouldn't keep the HTML, or pass it around to other objects in the
      system, I would translate it and throw it away.

      In terms of a metaphor, how about a radio station. There's you
      listening from your car. There's the announcer who checks with the
      guy in the traffic copter every now and then. That seems to correctly
      model the two places we do communication, and if we make the
      announcer a friend of yours, then he can know about where you
      drive, and tailor the information just for you.

      This also makes me wonder about the messages your sending. I thought
      you were sending road conditions. Is this what you want, or should
      you just send the optimal path?

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