To hierarchy or not to hierarchy (LONG)

From: Steven Wurster (stevenwurster_at_lycos.com)
Date: 03/08/04

  • Next message: Robert C. Martin: "Re: First Avoid Coding" 
    Date: 8 Mar 2004 05:46:33 -0800

    All,

    I have a design issue that I'm dealing with, and I'm torn between a
    few different directions that I can go. I'm hoping that some of the
    comp.object crew can help me out with this one and help me weigh the
    pros and cons.

    Basically, I've got objects flying through space, which are being
    observed by other objects as time goes by. For each of these
    observations, I have standard things like the time observed and who
    did the observing. But due to the way the system works, there are
    different kinds of observers. Some provide positional data in only
    two dimensions, some provide three dimensional data, and other provide
    "six" dimensional data, which is position and velocity. There is also
    a variant of the six dimensional data. So, with the 2D having three
    variants (could be any pair of the three axes), there are in total 6
    possible types of observations. This is no big deal, really.

    Now, what we do with these observations are both store them and run
    some algorithms on them. In general, the algorithms are independent
    of the type of observation, but there are nuances that depend on
    whether we are using 2D, 3D, 6D, or the 6D variant. I'm actually
    redesigning an existing system (which is really, really, poorly
    coded), and it treats every type differently, even though they share
    information like time and source. The algorithms get run on both new
    data provided by observers, and on existing data that is in storage.
    How and when depends on various factors that are irrelevant to this
    discussion.

    My dilemma is whether to redesign the observation types into a
    hierarchy, or to combine them together into one type that has boolean
    queries that state what type we have. The issue really comes down to
    storage, and ease of coding. The current storage mechanism uses a
    class that knows about every observation type, but is really clunky.
    It requires jumping through hoops to get type information, and is
    fairly buggy in general (it was written by a person who should not be
    coding anything, IMO).

    I could keep the all-encompassing style, and just have to query type
    data, or I could go with the hierarchy, and let the storage just hold
    pointers to the base class, which will make the storage mechanism a
    bit simpler to redesign. The storage is customized, and its behavior
    does depend on the observation type in some cases. But if I go to the
    hierarchy, I will have to do a lot of downcasting whenever I need to
    know the true type. Observers know the type of data they provide, so
    the downcasting won't be necessary on new updates, but it will be
    needed when rooting through the storage. I'm leaning away from
    downcasting for both aesthetic and performance reasons (it's more or
    less a real-time system).

    Anybody got any ideas on this one? I'm actually leaning toward the
    combined style mixed with a mini-hierarchy, as the true types need to
    be sent across a network, and shrinking them down to their smallest
    possible is necessary. That is, I could use the combined class in the
    storage and algorithms, but have queries that return objects which are
    within a hierarchy, and both the observers and network pieces use
    those. Might be the best of both worlds. Another option is including
    a reference to the algorithm within the observation types, making much
    of the code independent of the type, but I don't know if that will be
    easy to do.

    Any help is appreciated, and I apologize for the long post.

    Steve

  • Next message: Robert C. Martin: "Re: First Avoid Coding"

    Relevant Pages

    • Re: bit fields pointers?
      ... little monsters in a distributed berkelydb ... At this point we start getting into algorithms questions rather than ... We would also need some idea about probability distributions ... storage can be achieved by using probablistic storage rather than ...
      (comp.lang.c)
    • Re: Length of Variable Names Affect Compiled Executable?
      ... John said: ... my final executable program? ... I know its setting aside storage for the variable itself; ... algorithms don't deliver sufficient performance to meet your users' needs. ...
      (comp.lang.c)
    • Seeking Video & Image Compression Researcher for Ocarina Networks in San Jose, CA
      ... Building robust and high-performance storage and network subsystems, ... Ocarina is looking for someone to research, create, and implement high- ... performance algorithms for Image and Video compression. ... Up-to-date knowledge of the latest image detection techniques, ...
      (sci.image.processing)
    • Re: To hierarchy or not to hierarchy (LONG)
      ... and on existing data that is in storage. ... > hierarchy, or to combine them together into one type that has boolean ... to the partition subject matter when different subject matters need to ... subclassed and one needs to read/write data unique to a subclass, ...
      (comp.object)
    • Re: [PATCH] usb/mcs7830: Dont use buffers from stack for USB transfers
      ... both for networking and storage. ...  Probably a mutex or other locking ... hierarchy issue. ...
      (Linux-Kernel)