Сообщение Re[4]: бессмысленные интерфейсы от 18.02.2022 12:02
Изменено 19.02.2022 2:18 AlexGin
Re[4]: бессмысленные интерфейсы
Здравствуйте, уважаемый B0FEE664, Вы писали:
AG>Для представления древовидных структур, с коллекциями элементов того же типа, что и корневой элемент?
AG>Когда в корневом элементе требуется иметь коллекцию child-элементов.
BFE>Не вижу препятствий.
BFE>
Элемент дерева, как логично я заметил выше, один и тот же.
Для каких-то других элементов — он является parent-ом.
Для других — чайлдом.
Ссылочку на этот чайлд хранит родитель (parent) в своей коллекции.
То, что Вы писали — это два разных класса.
Я бы предложил так:
Здесь и у Вас, и у меня — две сушности.
Но у меня — универсальный узел и интерфейс к нему.
Именно наличие программного интерфейса — позволяет уменьшить связанность (coupling) в проекте.
За счёт этого, получим упрощение архитектуры и уменьшение количества ошибок.
Конечно же, можно было обойтись и без интерфейса, однако так красивее и понятнее.
Кроме того, имеется заложенная база — как для развития (новые типы узлов),
так и для тестирования основы нашего проекта.
AG>Для представления древовидных структур, с коллекциями элементов того же типа, что и корневой элемент?
AG>Когда в корневом элементе требуется иметь коллекцию child-элементов.
BFE>Не вижу препятствий.
BFE>
BFE>class child;
BFE>class parent
BFE>{
BFE> std::vector<std::shared_ptr<child>> childs;
BFE>};
BFE>
Элемент дерева, как логично я заметил выше, один и тот же.
Для каких-то других элементов — он является parent-ом.
Для других — чайлдом.
Ссылочку на этот чайлд хранит родитель (parent) в своей коллекции.
То, что Вы писали — это два разных класса.
Я бы предложил так:
class INode // Интерфейс узла:
{
public:
virtual std::string GetNameOfNode() const = 0;
virtual std::vector<std::shared_ptr<INode>> GetVectOfChilds() const = 0;
virtual void AddNode(<std::shared_ptr<INode>> p) = 0;
};
class Node : public INode // Класс реализации узла (header):
{
public:
Node(const std::string& sNameOfNode); // C-tor
~Node(); // D-tor
std::string GetNameOfNode() const override;
std::vector<std::shared_ptr<INode>> GetVectOfChilds() const override;
void AddNode(<std::shared_ptr<INode>> p) override;
};
Здесь и у Вас, и у меня — две сушности.
Но у меня — универсальный узел и интерфейс к нему.
Именно наличие программного интерфейса — позволяет уменьшить связанность (coupling) в проекте.
За счёт этого, получим упрощение архитектуры и уменьшение количества ошибок.
Конечно же, можно было обойтись и без интерфейса, однако так красивее и понятнее.
Кроме того, имеется заложенная база — как для развития (новые типы узлов),
так и для тестирования основы нашего проекта.
Re[4]: бессмысленные интерфейсы
Здравствуйте, уважаемый B0FEE664, Вы писали:
AG>Для представления древовидных структур, с коллекциями элементов того же типа, что и корневой элемент?
AG>Когда в корневом элементе требуется иметь коллекцию child-элементов.
BFE>Не вижу препятствий.
BFE>
Элемент дерева, как логично я заметил выше, один и тот же.
Для каких-то других элементов — он является parent-ом.
Для других — чайлдом.
Ссылочку на этот чайлд хранит родитель (parent) в своей коллекции.
То, что Вы писали — это два разных класса.
Я бы предложил так:
Здесь и у Вас, и у меня — две сушности.
Но у меня — универсальный узел и интерфейс к нему.
Именно наличие программного интерфейса — позволяет уменьшить связанность (coupling) в проекте.
За счёт этого, получим упрощение архитектуры и уменьшение количества ошибок.
Конечно же, можно было обойтись и без интерфейса, однако так красивее и понятнее.
Кроме того, имеется заложенная база — как для развития (новые типы узлов),
так и для тестирования основы нашего проекта.
AG>Для представления древовидных структур, с коллекциями элементов того же типа, что и корневой элемент?
AG>Когда в корневом элементе требуется иметь коллекцию child-элементов.
BFE>Не вижу препятствий.
BFE>
BFE>class child;
BFE>class parent
BFE>{
BFE> std::vector<std::shared_ptr<child>> childs;
BFE>};
BFE>
Элемент дерева, как логично я заметил выше, один и тот же.
Для каких-то других элементов — он является parent-ом.
Для других — чайлдом.
Ссылочку на этот чайлд хранит родитель (parent) в своей коллекции.
То, что Вы писали — это два разных класса.
Я бы предложил так:
class INode // Интерфейс узла:
{
public:
virtual std::string GetNameOfNode() const = 0;
virtual std::vector<std::shared_ptr<INode>> GetVectOfChilds() const = 0;
virtual void AddNode(std::shared_ptr<INode> p) = 0;
};
class Node : public INode // Класс реализации узла (header):
{
public:
Node(const std::string& sNameOfNode); // C-tor
~Node(); // D-tor
std::string GetNameOfNode() const override;
std::vector<std::shared_ptr<INode>> GetVectOfChilds() const override;
void AddNode(std::shared_ptr<INode> p) override;
};
Здесь и у Вас, и у меня — две сушности.
Но у меня — универсальный узел и интерфейс к нему.
Именно наличие программного интерфейса — позволяет уменьшить связанность (coupling) в проекте.
За счёт этого, получим упрощение архитектуры и уменьшение количества ошибок.
Конечно же, можно было обойтись и без интерфейса, однако так красивее и понятнее.
Кроме того, имеется заложенная база — как для развития (новые типы узлов),
так и для тестирования основы нашего проекта.