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

RE: [XP] DTSTTCPW/YAGNI dilemma

Expand Messages
  • Charlie Poole
    Your original object C had n+1 jobs to do - handling n different protocols plus deciding which one of them to use. You split the object into separate parts
    Message 1 of 2 , Jan 31, 2002
    • 0 Attachment
      Your original object C had n+1 jobs to do - handling n different protocols plus
      deciding which one of them to use. You split the object into separate parts each
      of which does something different. You proved it by coming up with a meaningful
      name for each object. Your original object can't be named as easily. You can use
      some meaningless abstraction, or you can call it LCP+CHAP+.....+Handler.

      So I'd say it all comes under the heading of communicating intention.

      Charlie Poole
      cpoole@...


      > -----Original Message-----
      > From: Ron Crocker [mailto:crocker@...]
      > Sent: Wednesday, January 30, 2002 5:51 PM
      > To: extremeprogramming@yahoogroups.com
      > Subject: [XP] DTSTTCPW/YAGNI dilemma
      >
      >
      > Ok, I'm struggling with a problem here that I just can't convince my
      > little mind to glom onto. Here's the problem, in a nutshell:
      >
      > Two parts of the system communicate through a third part, like this.
      >
      > +---+ +---+ +---+
      > | A |<== protocol X ==>| C |<== protocol Y ==>| B |
      > +---+ +---+ +---+
      >
      >
      > This third part provides a set of services between these parts, so
      > simply eliminating it is not an option. There's three kinds of services,
      > two of which are truly between parts A and B, and another that's between
      > A and C. The protocol used between A and C (X) carries the information
      > that ultimately will be relayed to B (from C via protocol Y). A simple
      > concrete example similar to my problem (that may be out of your area of
      > expertise but is nonetheless accurate enough and simple) is that C is a
      > router, protocol X is PPP, and protocol Y is IP. The messages between A
      > and C include LCP (that terminates at the router) and those between A
      > and B would be standard IP packets, carried from A to C as PPP frames,
      > and then relayed by C to B as IP packets (in some other link layer
      > protocol).
      >
      > Continuing with the PPP example, PPP frames contain a "protocol
      > identifier" field that tell the router if the packet contained within is
      > a LCP packet or a UDP or TCP packet. LCP packets terminate at C, while
      > UDP and TCP packets are sent onward (ostensibly to B). I could envision
      > code to handle this as follows:
      >
      > ...
      >
      > if (PID_LCP == pkt->protocolID) {
      > // route packet to LCP handler
      > } else {
      > // route packet to IP forwarder
      > }
      >
      > ...
      >
      > Ok, so let me further complicate the matter. TCP packets in PPP can have
      > header compression applied to them (it's a fairly normal thing, really.
      > goes by the moniker Van Jacobson Header Compression, aka VJ compression,
      > as defined by, well, Van Jacobson, in RFC 1144). It turns out that C has
      > to process these packets before it can simply forward them, so the code
      > now becomes
      >
      > ...
      >
      > if (PID_LCP == pkt->protocolID) {
      > // route packet to LCP handler
      > } else {
      > // route packet to IP forwarder
      > if (PID_VJCOMP == pkt->protocolID) {
      > // handle compressed header stuff before forwarding
      > } else {
      > // just ship it baby!
      > }
      > }
      >
      > ...
      >
      > Ok, so now let's authenticate PPP initiations via CHAP, which is also
      > between A and C. More code changes, but its still pretty simple...
      >
      > ...
      >
      > if (PID_LCP == pkt->protocolID) {
      > // route packet to LCP handler
      > } else if (PID_CHAP == pkt->protocolID) {
      > // authenticate this alleged subscriber
      > } else {
      > // route packet to IP forwarder
      > if (PID_VJCOMP == pkt->protocolID) {
      > // handle compressed header stuff before forwarding
      > } else {
      > // just ship it baby!
      > }
      > }
      >
      > ...
      >
      > So far, I think I'm still in the "DTSTTCPW" arena, but the code is
      > starting to smell "icky." I can see where this is going, that I'm going
      > to have a whole bunch of if statements to deal with the A<->C cases and
      > then one last one to deal with all the A<->C<->B cases. I'd much rather
      > look at this as:
      >
      > (code in packet receiver/dispatcher loop)
      > ...
      >
      > // Let a handler deal with this packet
      > PacketHandler.factory(pkt->protocolID).handlePacket(pkt);
      >
      > ...
      >
      > (code near packet handlers)
      > ...
      >
      > public abstract class PacketHandler {
      > public abstract void handlePacket(Packet _pkt);
      >
      > public static PacketHandler factory(ProtocolID _pid) {
      > switch (_pid) {
      > case PID_CHAP:
      > return new CHAPhandler();
      > case PID_LCP:
      > return new LCPhandler();
      > case PID_VJCOMP:
      > return new VJhandler();
      > default:
      > return new DefaultHandler();
      > }
      > }
      > }
      >
      > ...
      >
      > So my dilemma is understanding a) should I make this "leap" to a
      > friendlier structure, b) how do I know when to make this leap -- more
      > specifically, what did I do when that caused me to want to go to this
      > other place, and c) how can I argue that the final answer isn't really
      > the "simplest thing that could possibly work" -- for me, I naturally
      > went there, well not first maybe, but surely second, and it is the
      > simplest thing for me. The other one isn't simple, its only ugly.
      > Encapsulation, compartmentalization, a single handling mechanism, ...
      > all of those things feel simple to me. What exactly makes the last one
      > simpler???
      >
      > Help me resolve my dilemma.
      >
      > Thanks!
      >
      > Ron C.
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.