Зависимость классов иерархии

Я хочу несколько советов о дизайне классов.
Допустим, у меня есть 3 класса, "class A", "class B" and "class C",
Каждый класс имеет разные пространства имен.
"A" has an instance of "B", and "B" has an instance of "C",
Каждый класс имеет «struct Setting», и каждый класс устанавливается с помощью SetSettings ().
На самом деле, "A" uses "B" to do its job, and "B" uses "C" to do its job,

У меня вопрос, есть ли лучший способ сделать эти настройки иерархии?

Например, to break the relation between "A" and "C", "B" может иметь те же параметры "C::Settings" вместо определения c_settings …

Заранее спасибо!

хиджры

#include "B.h"namespace A {
struct Settings {
int param_for_A_1;
B::Settings b_settings;
};
class A {
void SetSettings(const Settings& source) {
settings_ = source;
b_.SetSettings(source.b_settings);
}
Settings settings_;
B::B b_;
};
}

B.h

#include "C.h"namespace B {
struct Settings {
int param_for_B_1;
int param_for_A_2;
C::Settings c_settings;
};
class B {
void SetSettings(const Settings& source) {
settings_ = source;
c_.SetSettings(source.c_settings);
}
Settings settings_;
C::C c_;
};
}

C.h

namespace C {
struct Settings {
int param_for_C_1;
};
class C {
void SetSettings(const Settings& source) {
settings_ = source;
}
Settings settings_;
};
}

main.cpp

#include "A.h"int main() {
A::Settings settings;
// Hierarchy settings...
settings.param_for_A_1 = 1;
settings.b_settings.param_for_B_1= 2;
settings.b_settings.param_for_B_2 = 3;
settings.b_settings.c_settings.param_for_C_1= 4;
class A::A a;
a_.SetSettings(settings);
return;
}

0

Решение

На данный момент вы на самом деле не используете наследование, а скорее композицию. Композиция означает, что класс имеет атрибут типа другого класса, а не наследует функции и атрибуты родительского класса.

Если бы я хотел использовать наследование, я бы, вероятно, использовал бы класс C как основу, от которой B наследовал бы. А потом наследовал бы от Б. Каждое «поколение» имеет свое int атрибут, соответствующий их «настройкам».

В зависимости от ситуации это может быть более подходящим.

0

Другие решения

Других решений пока нет …