Информация об изменениях

Сообщение Re[4]: бессмысленные интерфейсы от 18.02.2022 12:02

Изменено 19.02.2022 2:18 AlexGin

Re[4]: бессмысленные интерфейсы
Здравствуйте, уважаемый B0FEE664, Вы писали:

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>
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) в проекте.
За счёт этого, получим упрощение архитектуры и уменьшение количества ошибок.

Конечно же, можно было обойтись и без интерфейса, однако так красивее и понятнее.
Кроме того, имеется заложенная база — как для развития (новые типы узлов),
так и для тестирования основы нашего проекта.