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

On 2007-12-20 19:42, sunderjs wrote: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

On Dec 20, 7:42 pm, sunderjs <sunde...@gmail.comwrote:
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.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Dec 21, 3:48*pm, James Kanze <james.ka...@gmail.comwrote: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()
{

}

On Dec 21, 3:48*pm, James Kanze <james.ka...@gmail.comwrote: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(t1); //only xy interface exposed
z.doSomething(t1); //only yz interface exposed
}