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

Re: [XP] XP Scenario: Chat client

Expand Messages
  • Sean Gilbertson
    I agree with your suggestions, and that s a big part of why I like XP: It doesn t try to be everything to everyone right from the get-go. And yet, at the same
    Message 1 of 4 , Aug 17, 2004
    • 0 Attachment
      I agree with your suggestions, and that's a big part of why I like XP: It doesn't try to be everything to everyone right from the get-go. And yet, at the same time, the code should remain open to change (by following coding principles like SRP, etc.). Those ideals seem to fit me very well, with the latter appealing to my desires and the former appealing to my experience :-)

      My big "idee fixe" is representing the protocol. I coded a design over the past couple days, and I ended up with:
      - A "Service" interface which defines basic methods that all services should provide: sending messages, logging in, etc.
      - An implementation of Service (representing a specific chat service), which used:
      - An implementation of the "ServiceBroker" interface, which is a "lower layer," and handles protocol details. I'm a little concerned that it basically mirrors the Service interface, though it is intended for communication rather than providing a service to a Model (or therefore an end user).

      I'd be very interested in some principles or patterns (or other suggestions) for representing low-level ("bit-pushing") network protocols. I've seen a book called "Enterprise Integration Principles" or something similar, but I haven't had a chance to actually get it in my hands and read it.

      Yes, the customer is basically me in this exercise. I am concerned, though, about the lack of pair-programming. I will be performing this on my own. It won't stop me from applying practices and adhering to principles (e.g. OCP), but people do seem to be stressing, more and more, the importance of pair programming.

      On Tue, Aug 17, 2004 at 08:05:21AM -0700, Steven Gordon wrote:
      > I suggest picking one specific protocol to start with, and then add others later (as new stories) to force the refactoring to the proper design pattern to support protocol-independence. To try to be protocol-independent from the start is not in the spirit of XP. If you never have to support more than one protocol, you will never need this refactoring.
      >
      > No doubt you will discover missing stories along the way, such as:
      > - User registration.
      > - Change password.
      > - "Recover" password.
      > - Mute user.
      > This is to be expected, just add the stories you discover and let the customer (I assume that is you wearing a different hat) prioritize them into the mix.
      >
      > Steven Gordon
      > http://sf.asu.edu/
      >
      >
      > -----Original Message-----
      > From: Sean Gilbertson [mailto:sean_gilbertson@...]
      > Sent: Tue 8/17/2004 7:37 AM
      > To: extremeprogramming@yahoogroups.com
      > Cc:
      > Subject: [XP] XP Scenario: Chat client
      >
      >
      >
      > Hello all,
      >
      > If you have some free time, I would appreciate some comments on the "XP approach" to the following problem:
      >
      > Project: IM/chat client
      >
      > Stories:
      > - User can sign in with a user name and password.
      > - User can add other users to their "contact list."
      > - Contact list will remain persistent.
      > `--> Contact list may be persistent on server, or may not be (see additional requirement 1. a).
      > - User can delete users from their contact list.
      > - Users receive notices when their contacts are "online."
      > - Users receive messages as they are sent in real time.
      >
      > Additional requirements:
      > 1. Solution must conform to low-level, pre-established, layered protocols.
      > 1. a) Solution may conform to other protocols in the future.
      > 1. b) Protocols for a given "Service" may change in the future.
      >
      > I like this problem for a few reasons:
      > 1. I want to build a client like this because I like network protocols a lot.
      > 2. This seems like a substantial yet conceptually simple challenge.
      > 3. I have to deal with real-world restrictions and standards (i.e. protocols).
      >
      > I'm especially interested to see how XP can deliver the "Service" of high-level interfaces to low-level protocols, especially when the set of protocols may (or may NOT) increase in quantity in the future.
      >
      > --
      > Sean Gilbertson
      > IT Systems/Software Developer
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >

      --
      Sean Gilbertson
      IT Systems/Software Developer
      Financial Recovery Services, Inc.
      952-831-4800 x1211

      This document may contain sensitive information which is intended for the recipient only. Any unauthorized use of the material included in this message could result in criminal investigation. If you have received this message in error please notify the sender.
    Your message has been successfully submitted and would be delivered to recipients shortly.