Между двумя определенными репозиториями я до сих пор использовал интерфейсный класс (с наследованием), и это я недавно заменил на функцию обратного вызова, используя std :: function () & станд :: Bind ().
Используя старый интерфейсный метод, я получил следующее:
//a.hpp
#include "b.hpp"
class A{
public:
A(InterfaceB* pb) : m_pb(pb) {};
void bar(){m_pb->foo();};
private:
InterfaceB* m_pb;
};
—
//b.hpp
#include <iostream>
class InterfaceB{
public:
virtual void foo() = 0;
};
class B : public InterfaceB {
public:
void foo(){ std::cout << "hi"<< std::endl; };
};
—
//main.cpp
#include "a.hpp"#include <memory>
int main(){
InterfaceB* pb = new B;
A a(pb);
a.bar();
delete pb;
}
—
В UML я бы нарисовал маленький пример выше, например:
Чтобы уменьшить зависимость между репозиториями (здесь классы A и B), я отбросил интерфейс и вместо этого использовал оболочку функции.
//a_callback.hpp
#include <functional>
class A{
public:
void setBcallback(std::function<void(void)> callback){m_callback = callback;};
void bar(){m_callback();};
private:
std::function<void(void)> m_callback;
}
—
//b_callback.hpp
#include <iostream>
class B {
public:
void foo(){ std::cout << "hi"<< std::endl; };
}
—
//main.cpp
#include "a_callback.hpp"#include <functional>
int main(){
A a;
B b;
a.setBcallback(std::bind(&B::foo, &b));
a.bar();
}
—
И это было немного сложнее для меня, мне не повезло, что Google нашел, как
C ++ std :: bind () / std :: function () и UML << связать >> перевести друг на друга. Поэтому мой вопрос будет таким: как показать использование функции-обертки на диаграмме классов?
Исходя из того, что я нашел, я, вероятно, пойду с этим:
Но это просто кажется слабым и недостаточным. Любая помощь приветствуется!
Этот вопрос был ранее помечен как дубликат с этим: Как представить Обратный вызов в диаграмме классов UML .
Но мой вопрос специфичен для C ++ и сказал, что «original» помечен как Java, к сожалению, я не получил никакой помощи от этого. Мой вопрос был не о том, «как показать обратный вызов в UML», который, я думаю, это объясняет, а о том, как «показать std :: bind () в UML», что я считаю более хитрым. Здесь происходит две вещи: одна установка функции-обёртки с помощью bind (), вторая — вызов через обертку. Я просто не мог видеть, как эта тема выше решает этот конкретный вопрос. Спасибо!
<<bind>>
зависимость относится к Шаблон UML связывание:
TemplateBinding — это связь между TemplateableElement и
шаблон, который определяет замены фактических
ParameterableElements для формальных TemplateParameters из
шаблон.
привязка шаблона это особая зависимость реализации, которая показывает, что класс является специализацией шаблона и устанавливает подстановку шаблона.
Типичным примером будет:
using void_function = std::function<void(void)> ;
В C ++ std::bind()
привязывает параметры к вызываемому динамически. Это совершенно другая семантика.
Если вы хотите показать это в UML, это не будет так полезно. Вы могли бы :
Покажите, что анонимный тип, возвращаемый связыванием, является экземпляром шаблона вызываемого объекта с одним аргументом, замененным на B (очень похожая диаграмма на приведенную выше).
если полезно, покажите, что этот анонимный класс зависит от B.
если это полезно, покажите необязательное отношение (0..1) от A к этому анонимному классу, понимая, что альтернативные отношения будут возможны с другими анонимными классами (вы можете использовать ограничение OCL, если хотите проиллюстрировать несколько на своей диаграмме и сделать Понятно, что они взаимоисключающие).
К сожалению, что бы вы ни рисовали, оно не будет таким общим и мощным, как ваш C ++ дизайн, и это не очень поможет для понимания.
Цель диаграммы UML — не программировать графически, а дать представление о внутреннем устройстве. Поэтому я настоятельно рекомендую сделать это простым:
единственное реальное соотношение между A и абстрактным вызываемым классом для обратного вызова. Это должно идти на диаграмме.
Вы также можете показать, что этот абстрактный обратный вызов может зависеть от других соответствующих классов в вашей диаграмме. Комментарий к этим отношениям зависимостей может объяснить простыми словами, что зависимости выражают привязку к функции-члену.
Других решений пока нет …