Обработка переменных в композиционных отношениях

Question

Обработка переменных в композиционных отношениях

В настоящее время я занимаюсь редизайном проекта C ++ и хотел бы получить несколько мнений о том, как следует обрабатывать переменные, когда классам с отношением «имеет» (состав) необходимо обращаться к переменным, которые, возможно, принадлежат родителю, например:

Объект компьютера имеет объект сетевой карты. Объект компьютера имеет переменную владельца. Например

class Computer {
string get_owner(); // getter as an option?
private:
std::string owner = "baylesj";
NetworkCard nic;
}

class NetworkCard {
public:
NetworkCard(Computer *parent);
send_packet();
broadcast_owner(send_packet(m_parent->owner)); // this is kind of ugly
private:
Computer *m_parent;
}

Допустим, у меня есть функция в сетевой карте, которая нуждается в владельце. Лучше ли передать владельца в качестве переменной-члена сетевой карты, когда я инициализирую в Computer, или у меня должен быть родительский указатель в NetworkCard, который может получить доступ к переменной-члену Computer, Getter / Setter или другим отношениям? Я знаю, что довольно распространенная практика иметь указатель на родителя в дочернем элементе, но это хорошая идея / правильная ООП?

** Компьютерная вещь, например, IRL, это что-то еще, так что не зацикливайтесь на ней :).

3

c++composition oop

Решение

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

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

Источник

Accepted Answer

Я вижу, вы понимаете, что желательно минимизировать ненужную связь. Для этого вы можете спроектировать класс NetworkCard так, чтобы он не знал о деталях реализации родительского элемента. Вот один подход, который передает имя для трансляции при построении сети:

class Computer {
public:
Computer(std::string const &owner) : m_Owner(owner), nic(owner)
{
}

private:
std::string m_Owner;
NetworkCard nic;
};

class NetworkCard {
public:
NetworkCard(std::string const &owner)
{
broadcast_owner(owner);
}

send_packet();
broadcast_owner(std::string const &owner);

private:
};

Если вы обнаружите, что таких переменных слишком много для передачи в качестве параметров конструктора (мне нравится не более двух или трех), то вы можете обнаружить, что композиция является неподходящим инструментом для решения проблемы. Зачастую количество параметров невелико, если только это не отношение «есть», в этом случае наследование может быть лучшим инструментом.

3