views:

105

answers:

2

Hello there,

I am having trouble coming up with a good design for a group of classes and was hoping that someone could give me some guidance on best practices. I have kept the classes and member functions generic to make the problem simpler.

Essentially, I have three classes (lets call them A, B, and C) as follows:

class A
{
public:
  ...
  int GetX( void ) const { return x; };
  int GetY( void ) const { return y; };

private:
  B b;    // NOTE: A "has-a" B
  int x;
  int y;
};

class B
{
public:
   ...
   void SetZ( int value ) { z = value };
private:
   int z;
   C c;  // NOTE: B "has-a" C 
};

class C
{
public:
  ...
  void DoSomething(int x, int y){ ... };
  void DoSomethingElse( int z ){ ... };
};

My problem is as follows:

  • Class A uses its member variables "x" and "y" a lot internally.
  • Class B uses its member variable "z" a lot internally.
  • Class B needs to call C::DoSomething(), but C::DoSomething() needs the values of X and Y in class A passed in as arguments.
  • C::DoSomethingElse() is called from say another class (e.g. D), but it needs to invoke SetZ() in class B!.

As you can see, it is a bit of a mess as all the classes need information from one another!. Are there any design patterns I can use?. Any ideas would be much appreciated ....

+1  A: 

Unfortunately, as you present this, it's a complete mess.

Your methods in class C are defined as private, hence, can be called only within other methods of that class (unless you want to add friend declarations and make your dependencies even worse).

I also think that you'd better paste your code without these generic names, because it could help us to understand the problem's domain and come up with some good architecture advices.

Remember that a lot of good application architecture approaches are already invented and you actually don't have to re-invent them, you should only learn them and get used to them.

Kotti
I am sorry, I missed out the "public" and there was also a typo .. will update the example.
Mewzer
+1  A: 

You've left out a lot of detail that could alter the validity of this suggestion, but based on the subset of the interfaces you show it looks like B should have an A or possibly be derived from A, not vice versa.

Amardeep