Не уверен, как придумать хороший дизайн - PullRequest
Новая
       30

Не уверен, как придумать хороший дизайн

0 голосов
/ 05 июня 2010

Мне трудно придумать хороший дизайн для группы классов, и я надеялся, что кто-нибудь может дать мне несколько советов по передовому опыту.Я сохранил общие классы и функции-члены, чтобы упростить задачу.

По сути, у меня есть три класса (давайте назовем их A, B и C) следующим образом: 

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 ){ ... };
};

Моя проблема заключается в следующем:

  • Класс A много использует внутренние переменные-члены "x" и "y".
  • Класс B много использует внутреннюю переменную-член "z".
  • Класс B должен вызывать C :: DoSomething (), а C :: DoSomething () - значения X и Y в классе A, передаваемые в качестве аргументов.
  • C ::DoSomethingElse () вызывается, скажем, из другого класса (например, D), но он должен вызывать SetZ () в классе B!.

Как видите, это немного беспорядок, так как всеклассы нуждаются в информации друг от друга!Есть ли какие-то шаблоны дизайна, которые я могу использовать?Любые идеи будут высоко оценены ....

Ответы [ 2 ]

1 голос
/ 05 июня 2010

Вы пропустили много деталей, которые могут изменить обоснованность этого предложения, но на основании поднабора интерфейсов, которые вы показываете, похоже, что B должен иметь A или, возможно, быть полученным из A, а не наоборот.

1 голос
/ 05 июня 2010

К сожалению, когда вы это представляете, это полный беспорядок.

Ваши методы в class C определены как private, поэтому их можно вызывать только внутри других методов этого класса (если только вы не хотите добавить объявления friend и сделать ваши зависимости еще хуже).

Я также думаю, что вам лучше вставить свой код без этих обобщенных имен, , потому что это может помочь нам понять суть проблемы и найти несколько полезных советов по архитектуре.

Помните, что множество хороших подходов к архитектуре приложений уже изобретены , и вам на самом деле не нужно заново изобретать их, вы должны только изучить их и привыкнуть к ним .

...