Class Design Alternatives

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • sunderjs

    #1

    Class Design Alternatives

    Hi,

    This is from a typical telecom software implementation. I have three
    subsystems (x, y, z) which exchange data amongst them. The arrangement
    is such that x talks to y over interface xy. y subsystem them talks to
    z over yz interface. In a typical scenario, y would receive a set of
    parameters from x (over xy). Some of these are meant for z subsys as
    well. So y needs to send these plus some more parameters to z.

    The implementation options for this kind of arrangement can be :
    1. Define separate classes (with access methods for each of the
    individual parameters) at each xy and yz interface. Let the common
    subsys layer (here y subsys) copy the relevant parameters from x to
    that on the interface with z. The problem here is overhead of copy
    operation that can be expensive spl. for telecom s/w case.

    2. Other option is to define a class that has get/set methods for all
    parameters (xy + yz) and let each individual subsystem class (x/y/z)
    call the relevant methods. The problem here is z has access to member
    functions which are not even relevant to it.

    Are there any better arrangements possible ? Can i have something like
    restricted access to member functions by different user classes (like
    z have only the relevant methods visible from option 2 above).

    thanks
    -Sj
  • =?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=

    #2
    Re: Class Design Alternatives

    On 2007-12-20 19:42, sunderjs wrote:
    Hi,
    >
    This is from a typical telecom software implementation. I have three
    subsystems (x, y, z) which exchange data amongst them. The arrangement
    is such that x talks to y over interface xy. y subsystem them talks to
    z over yz interface. In a typical scenario, y would receive a set of
    parameters from x (over xy). Some of these are meant for z subsys as
    well. So y needs to send these plus some more parameters to z.
    >
    The implementation options for this kind of arrangement can be :
    1. Define separate classes (with access methods for each of the
    individual parameters) at each xy and yz interface. Let the common
    subsys layer (here y subsys) copy the relevant parameters from x to
    that on the interface with z. The problem here is overhead of copy
    operation that can be expensive spl. for telecom s/w case.
    >
    2. Other option is to define a class that has get/set methods for all
    parameters (xy + yz) and let each individual subsystem class (x/y/z)
    call the relevant methods. The problem here is z has access to member
    functions which are not even relevant to it.
    >
    Are there any better arrangements possible ? Can i have something like
    restricted access to member functions by different user classes (like
    z have only the relevant methods visible from option 2 above).
    You could make y a friend of the class containing the data, y would then
    be able to access private methods of the data class but z will not. Be
    aware though that y will have access to all private members of the data
    class, which might not be desirable. Example:

    class data
    {
    void foo() const { }
    public:
    void bar() const { }
    friend struct A;
    };

    struct A
    {
    void doit(const data& d)
    {
    d.foo();
    d.bar();
    }
    };

    struct B
    {
    void doit(const data& d)
    {
    //d.foo();
    d.bar();
    }
    };


    int main()
    {
    data d;
    A a;
    B b;
    a.doit(d);
    b.doit(d);
    }

    In the above example B can not use the foo() function because it is
    private, but A is a friend of data and can thus access it.

    Another possibility is to use sub-classing, let z work with a data-class
    that have the functions that z needs, and then create a subclass that
    adds those functions that y needs, then let z work on the base-class and
    y on the derived class. If you need to copy the data-class beware of
    slicing. Example:

    struct data
    {
    void bar() const { }
    };

    struct data2 : public data
    {
    void foo() const { }
    };

    struct A
    {
    void doit(const data2& d) // OBS, data2
    {
    d.foo();
    d.bar();
    }
    };

    struct B
    {
    void doit(const data& d) // OBS, data
    {
    //d.foo();
    d.bar();
    }
    };


    int main()
    {
    data2 d; // OBS, data2
    A a;
    B b;
    a.doit(d);
    b.doit(d);
    }

    Since B works on data which does not have the foo() function it can not
    call it, while A works on the derived data2 which does have foo(). If
    all the data-members are declared in the base-class you should be able
    to cast between the two as needed.

    --
    Erik Wikström

    Comment

    • James Kanze

      #3
      Re: Class Design Alternatives

      On Dec 20, 7:42 pm, sunderjs <sunde...@gmail .comwrote:
      This is from a typical telecom software implementation. I have three
      subsystems (x, y, z) which exchange data amongst them. The arrangement
      is such that x talks to y over interface xy. y subsystem them talks to
      z over yz interface. In a typical scenario, y would receive a set of
      parameters from x (over xy). Some of these are meant for z subsys as
      well. So y needs to send these plus some more parameters to z.
      The implementation options for this kind of arrangement can be :
      1. Define separate classes (with access methods for each of the
      individual parameters) at each xy and yz interface. Let the common
      subsys layer (here y subsys) copy the relevant parameters from x to
      that on the interface with z. The problem here is overhead of copy
      operation that can be expensive spl. for telecom s/w case.
      2. Other option is to define a class that has get/set methods for all
      parameters (xy + yz) and let each individual subsystem class (x/y/z)
      call the relevant methods. The problem here is z has access to member
      functions which are not even relevant to it.
      The xy and yz are separate interfaces. That should answer the
      question at the design level. And I don't see where that would
      necessitate a copy: the xy interface object could easily contain
      a yz interface object, or a pointer to one, and that object can
      be passed on to z without copy (providing lifetimes are
      sufficient).

      --
      James Kanze (GABI Software) email:james.kan ze@gmail.com
      Conseils en informatique orientée objet/
      Beratung in objektorientier ter Datenverarbeitu ng
      9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

      Comment

      • sunderjs

        #4
        Re: Class Design Alternatives

        On Dec 21, 3:48 pm, James Kanze <james.ka...@gm ail.comwrote:
        On Dec 20, 7:42 pm, sunderjs <sunde...@gmail .comwrote:
        >
        >
        >
        >
        >
        This is from a typical telecom software implementation. I have three
        subsystems (x, y, z) which exchange data amongst them. The arrangement
        is such that x talks to y over interface xy. y subsystem them talks to
        z over yz interface. In a typical scenario, y would receive a set of
        parameters from x (over xy). Some of these are meant for z subsys as
        well. So y needs to send these plus some more parameters to z.
        The implementation options for this kind of arrangement can be :
        1. Define separate classes (with access methods for each of the
        individual parameters) at each xy and yz interface. Let the common
        subsys layer (here y subsys) copy the relevant parameters from x to
        that on the interface with z. The problem here is overhead of copy
        operation that can be expensive spl. for telecom s/w case.
        2. Other option is to define a class that has get/set methods for all
        parameters (xy + yz) and let each individual subsystem class (x/y/z)
        call the relevant methods. The problem here is z has access to member
        functions which are not even relevant to it.
        >
        The xy and yz are separate interfaces.  That should answer the
        question at the design level.  And I don't see where that would
        necessitate a copy: the xy interface object could easily contain
        a yz interface object, or a pointer to one, and that object can
        be passed on to z without copy (providing lifetimes are
        sufficient).
        >
        --
        James Kanze (GABI Software)             email:james.ka. ..@gmail.com
        Conseils en informatique orientée objet/
                           Beratung in objektorientier ter Datenverarbeitu ng
        9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34- Hide quoted text -
        >
        - Show quoted text -
        As mentioned in the problem text, some of the parameters from xy
        interface object needs to be passed to yz interface object. One
        obvious way is to copy these from xy to yz object. To avoid it one can
        form a superset object containing xy + yz parameters. But then as per
        the design, access to this superset object should be restricted to
        each of the interfaces. Defining a base class interfaces for xy and yz
        and then deriving a class from these seems a better option.

        Something like:

        class common
        {
        public:
        virtual void getA() = 0;
        virtual void setA() = 0;
        };

        class xy:public common
        {
        public:
        virtual void getB() = 0;
        virtual void setB() = 0;
        };

        class yz:public common
        {
        public:
        virtual void getC() = 0;
        virtual void setC() = 0;
        };

        //define a superset class derived from xy & yz
        //shall contain all data elements
        class totalSet:public xy, public yz
        {
        ..
        };

        //subsystem class
        class X
        {

        };
        int main()
        {

        }

        Comment

        • sunderjs

          #5
          Re: Class Design Alternatives

          On Dec 21, 3:48 pm, James Kanze <james.ka...@gm ail.comwrote:
          On Dec 20, 7:42 pm, sunderjs <sunde...@gmail .comwrote:
          >
          >
          >
          >
          >
          This is from a typical telecom software implementation. I have three
          subsystems (x, y, z) which exchange data amongst them. The arrangement
          is such that x talks to y over interface xy. y subsystem them talks to
          z over yz interface. In a typical scenario, y would receive a set of
          parameters from x (over xy). Some of these are meant for z subsys as
          well. So y needs to send these plus some more parameters to z.
          The implementation options for this kind of arrangement can be :
          1. Define separate classes (with access methods for each of the
          individual parameters) at each xy and yz interface. Let the common
          subsys layer (here y subsys) copy the relevant parameters from x to
          that on the interface with z. The problem here is overhead of copy
          operation that can be expensive spl. for telecom s/w case.
          2. Other option is to define aclassthat has get/set methods for all
          parameters (xy + yz) and let each individual subsystemclass( x/y/z)
          call the relevant methods. The problem here is z has access to member
          functions which are not even relevant to it.
          >
          The xy and yz are separate interfaces.  That should answer the
          question at thedesignlevel.  And I don't see where that would
          necessitate a copy: the xy interface object could easily contain
          a yz interface object, or a pointer to one, and that object can
          be passed on to z without copy (providing lifetimes are
          sufficient).
          >
          --
          James Kanze (GABI Software)             email:james.ka. ..@gmail.com
          Conseils en informatique orientée objet/
                             Beratung in objektorientier ter Datenverarbeitu ng
          9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34- Hide quoted text -
          >
          - Show quoted text -
          As mentioned in the problem text, some of the parameters from xy
          interface object needs to be passed to yz interface object. One
          obvious way is to copy these from xy to yz object. To avoid it one
          can
          form a superset object containing xy + yz parameters. But then as per
          the design, access to this superset object should be restricted to
          each of the interfaces. Defining a base class interfaces for xy and
          yz
          and then deriving a class from these seems a better option.

          Something like:


          class common
          {
          public:
          virtual void getA() = 0;
          virtual void setA() = 0;



          };


          class xy:public common
          {
          public:
          virtual void getB() = 0;
          virtual void setB() = 0;


          };


          class yz:public common
          {
          public:
          virtual void getC() = 0;
          virtual void setC() = 0;


          };


          //define a superset class derived from xy & yz
          //shall contain all data elements
          class totalSet:public xy, public yz
          {
          //contain implementation of the interfaces
          };


          //subsystem class
          class X
          {
          void doSomething(xy& obj1)
          {
          obj1.setA();
          obj1.setC(); //Error: can't access
          }

          };

          class Z
          {
          void doSomething(yz& obj2)
          {
          obj2.getA(); //permissible
          obj2.setB(); //Error:can't access
          }
          };

          int main()
          {
          totalset t1;
          Z z;
          X x;

          x.doSomething(t 1); //only xy interface exposed
          z.doSomething(t 1); //only yz interface exposed
          }

          Comment

          Working...