试图掌握动态分层 class 关系的装饰器设计
trying to grasp Decorator design for dynamic hierarchical class relationship
我正在尝试学习装饰器设计，我想出了一些很棒的东西，但我不知道我的想法是否会被编译。所以我创建了一些 classes:
这是基础class
class parameter
{
public:
parameter(){}
parameter(double mini, double maxi, double def) :
mini(mini),
maxi(maxi),
def(def)
{}
double mini, maxi, def;
double val;
virtual double getValue() { return val; }
virtual void setValue(double v) { val = v; }
};
这个 class 存储 smoothedParameters。 smoothedParameter 将在需要平滑时将自己添加到 SmootherManager 并在完成后自行删除。
class SmootherManager
{
public:
SmootherManager() {}
juce::Array<smoothedParameter *> CurSmoothingList;
void add(smoothedParameter * sp)
{
CurSmoothingList.addIfNotAlreadyThere(sp);
}
void remove(smoothedParameter * sp)
{
CurSmoothingList.removeFirstMatchingValue(sp);
}
void doSmoothing()
{
for (auto & sp : CurSmoothingList)
sp->incValue();
}
};
这个 class 随着时间的推移获取值并输出平滑值。
class smoothedParameter : public parameter
{
public:
//smoothedParameter(){}
smoothedParameter(double smoothingSpeed, SmootherManager & manager, parameter * p) :
smoothingSpeed(smoothingSpeed),
manager(manager),
p(p)
{}
double smoothingSpeed;
SmootherManager & manager;
parameter * p;
rosic::ExponentialSmoother smoother;
double getValue()
{
return smoother.getCurrentValue();
}
void setValue(double v)
{
p->setValue(v);
smoother.setTargetValue(p->getValue());
if (!smoother.finishedSmoothing())
manager.add(this);
}
void incValue()
{
smoother.getSample();
if (smoother.finishedSmoothing())
manager.remove(this);
}
};
这个 class 获取一个值并通过修饰符列表随时间修改它。
class modulatedParameter : public parameter
{
public:
modulatedParameter(parameter * p) : p(p) {}
juce::Array<modifier *> modulationInputs;
parameter * p;
double getValue()
{
double totalMod = 0;
for (const auto & m : modulationInputs)
totalMod += m->val;
return totalMod * p->getValue();
}
void setValue(double v)
{
p->setValue(v);
}
void add(modifier * sp)
{
modulationInputs.addIfNotAlreadyThere(sp);
}
void remove(modifier * sp)
{
modulationInputs.removeFirstMatchingValue(sp);
}
};
这是它的工作原理。你有一个平滑器和一个调制器。如果你在调制器内部构造一个平滑器，你就会得到一个平滑的调制器。如果在平滑器内构造调制器，则会得到非平滑调制器。
这是我想使用 classes 的方式：
// create the smoother manager
SmootherManager smManager;
// create modulatable parameter
auto mp = new modulatedParameter(new parameter(0.0, 1.0, 0.0));
// create a smoothable parameter
auto sp = new smoothedParameter(0.01, smManager, new parameter(0.0, 1.0, 0.0));
// create a modulatable parameter where its modifiers are smoothed
auto mp_sp = new modulatedParameter(new smoothedParameter(0.01, smManager, new parameter(0.0, 1.0, 0.0)));
// create a parameter where values are smoothed, but the modulation is not
auto sp_mp = new smoothedParameter(0.01, smManager, modulatedParameter(new parameter(0.0, 1.0, 0.0)));
好的！问题来了。
modifier myMod;
// add a modifier to sp_mp, can't do it, sp_mp has no add function.
sp_mp->add(&myMod);
我正在尝试向 smoothedParameter 的 modulatedParameter 添加调制器。我想了一个办法，但是这个好像不对。
auto mp = new modulatedParameter(sp_mp->p);
mp->add(&myMod)
sp_mp = new smoothedParameter(0.01, smManager, mp));
任何时候我想要 add/remove 修饰符，我都必须经过几个步骤。我可以想出一种方法来解决这个问题，但我对什么是实用方法一无所知，因为我不知道 C++ 的所有可能性。装饰器设计的要点是对象可以具有一组不同的功能。 ...似乎我需要为每个 class 设置一个 "add/remove" 函数，违背了这个设计的目的。
The point of decorator design is that objects can have a different set of functions. ...It seems like I'd need to have an "add/remove" function for every class, defeating the purpose of this design.
没有。与几乎所有最著名的模式一样，装饰器模式都是关于接口的，因此（在 C++ 中）是虚拟成员函数。
你定义你的基础class（抽象的或者你想用作基础的具体的），其中可以装饰的方法是虚拟的。
装饰器 decores 存在的东西，它既不添加也不删除功能。
每当您定义装饰器时，您最终都会覆盖这些方法以丰富它们并迭代调用相同方法的基础 class 实现。然后你将 pointers/references 传递给基础 class 并且用户不知道它们是否经过装饰。只要调用它，正确的事情就会发生。
让我们考虑一下。如果您添加一个新方法，您如何从一个引用或指向基 class 的指针调用它？你不能，所以你需要实际类型，即派生类型。
这违背了设计的目的，而不是您必须向基础添加方法class才能在派生的基础中装饰它的事实。
如果您正在寻找一种模式，可以让您在 class 中添加或删除函数，请考虑混合或其他。这不是装饰者的目标。
The point of decorator design is that objects can have a different set
of functions.
不，装饰器的意义在于能够灵活扩展对象的基本功能，同时保留其核心。通常，"flexibly" 一词假定在 运行 时间 进行此扩展 （动态）。
同时，C++是静态类型语言。这意味着 object/variable 的类型定义了您 可以 对它做什么以及您 不能 做什么。 sp_mp->add(&myMod); 可能的 IIF 变量 sp_mp 的类型 (class) 具有 add(...) 函数。这个决定是在编译时做出的，没有设计模式可以改变这个事实，只是接受它。 C++ 编译器不会让您调用不属于其类型的变量的 functions/use 成员变量。
无论你做什么，现有类型的接口都是静态定义的。想改变它吗？在编译时执行。
现在，考虑到所说的一切，我们可以得出一个合乎逻辑的结论：
如果您想向现有类型添加一些新功能 - 创建一个新类型。
这里或多或少是 classic（我相信）装饰器实现。
*我没有使用共享指针只是因为...... OP 也没有使用它们:)
class ICore
{
public:
virtual std::string Description() = 0;
void Describe() {
std::cout << "I am " << Description() << std::endl;
}
};
class Core final : public ICore
{
public:
std::string Description() override {
return "Core";
}
};
class IDecorator : public ICore
{
protected:
ICore* core;
public:
IDecorator(ICore* _core)
: core{ _core }
{ }
virtual ~IDecorator() {
delete core;
}
};
class Beautiful final : public IDecorator
{
public:
Beautiful(ICore* _core)
: IDecorator{ _core }
{ }
public:
std::string Description() override {
return "Beautiful " + core->Description();
}
};
class Shiny final : public IDecorator
{
public:
Shiny(ICore* _core)
: IDecorator{ _core }
{ }
public:
std::string Description() override {
return "Shiny " + core->Description();
}
};
int main()
{
ICore* core = new Core;
ICore* decorated_core = new Beautiful{ new Shiny{ core } };
core->Describe();
decorated_core->Describe();
delete decorated_core;
return 0;
}
输出：
I am Core
I am beautiful shiny Core
如您所见，这里的 Decorator 没有更改接口（class 原型）——没有向核心添加新功能。此外，它没有更改任何现有功能。然而，它所做的是对已经存在的行为的扩展。它从字面上 装饰 core 的描述 2 个新词 。请注意 - 这个 装饰发生在 运行 时间 。如果我们决定将装饰顺序从 new Beautiful{new Shiny{core}} 更改为 new Shiny{new Beautiful{core}}，则词序也会更改（从 beautiful shiny Core 到 shiny beautiful Core）。
但是，如果您真的非常想实现您的主要目的 - 添加带有装饰器的全新功能...有一种方法可以让您模仿这种行为。它在 C++14 中看起来很难看，所以这里是 C++17 代码：
class Core
{
public:
void CoreFunctional() {
std::cout << "Core functional." << std::endl;
}
};
template<typename T>
class Extend : public virtual T
{
public:
Extend() = default;
Extend(const T&) { }
public:
void ExtendedFunctional() {
std::cout << "Extended functional." << std::endl;
}
};
template<typename T>
class Utility : public virtual T
{
public:
Utility() = default;
Utility(const T&) { }
public:
void UtilityFunctional() {
std::cout << "Utility functional." << std::endl;
}
};
int main()
{
Core core;
core.CoreFunctional();
auto decorated_core = Utility{Extend{core}};
decorated_core.CoreFunctional();
decorated_core.ExtendedFunctional();
decorated_core.UtilityFunctional();
}
输出正如您所期望的那样，但我不太确定，是否可以将其视为装饰器...
我正在尝试学习装饰器设计，我想出了一些很棒的东西，但我不知道我的想法是否会被编译。所以我创建了一些 classes:
这是基础class
class parameter
{
public:
parameter(){}
parameter(double mini, double maxi, double def) :
mini(mini),
maxi(maxi),
def(def)
{}
double mini, maxi, def;
double val;
virtual double getValue() { return val; }
virtual void setValue(double v) { val = v; }
};
这个 class 存储 smoothedParameters。 smoothedParameter 将在需要平滑时将自己添加到 SmootherManager 并在完成后自行删除。
class SmootherManager
{
public:
SmootherManager() {}
juce::Array<smoothedParameter *> CurSmoothingList;
void add(smoothedParameter * sp)
{
CurSmoothingList.addIfNotAlreadyThere(sp);
}
void remove(smoothedParameter * sp)
{
CurSmoothingList.removeFirstMatchingValue(sp);
}
void doSmoothing()
{
for (auto & sp : CurSmoothingList)
sp->incValue();
}
};
这个 class 随着时间的推移获取值并输出平滑值。
class smoothedParameter : public parameter
{
public:
//smoothedParameter(){}
smoothedParameter(double smoothingSpeed, SmootherManager & manager, parameter * p) :
smoothingSpeed(smoothingSpeed),
manager(manager),
p(p)
{}
double smoothingSpeed;
SmootherManager & manager;
parameter * p;
rosic::ExponentialSmoother smoother;
double getValue()
{
return smoother.getCurrentValue();
}
void setValue(double v)
{
p->setValue(v);
smoother.setTargetValue(p->getValue());
if (!smoother.finishedSmoothing())
manager.add(this);
}
void incValue()
{
smoother.getSample();
if (smoother.finishedSmoothing())
manager.remove(this);
}
};
这个 class 获取一个值并通过修饰符列表随时间修改它。
class modulatedParameter : public parameter
{
public:
modulatedParameter(parameter * p) : p(p) {}
juce::Array<modifier *> modulationInputs;
parameter * p;
double getValue()
{
double totalMod = 0;
for (const auto & m : modulationInputs)
totalMod += m->val;
return totalMod * p->getValue();
}
void setValue(double v)
{
p->setValue(v);
}
void add(modifier * sp)
{
modulationInputs.addIfNotAlreadyThere(sp);
}
void remove(modifier * sp)
{
modulationInputs.removeFirstMatchingValue(sp);
}
};
这是它的工作原理。你有一个平滑器和一个调制器。如果你在调制器内部构造一个平滑器，你就会得到一个平滑的调制器。如果在平滑器内构造调制器，则会得到非平滑调制器。
这是我想使用 classes 的方式：
// create the smoother manager
SmootherManager smManager;
// create modulatable parameter
auto mp = new modulatedParameter(new parameter(0.0, 1.0, 0.0));
// create a smoothable parameter
auto sp = new smoothedParameter(0.01, smManager, new parameter(0.0, 1.0, 0.0));
// create a modulatable parameter where its modifiers are smoothed
auto mp_sp = new modulatedParameter(new smoothedParameter(0.01, smManager, new parameter(0.0, 1.0, 0.0)));
// create a parameter where values are smoothed, but the modulation is not
auto sp_mp = new smoothedParameter(0.01, smManager, modulatedParameter(new parameter(0.0, 1.0, 0.0)));
好的！问题来了。
modifier myMod;
// add a modifier to sp_mp, can't do it, sp_mp has no add function.
sp_mp->add(&myMod);
我正在尝试向 smoothedParameter 的 modulatedParameter 添加调制器。我想了一个办法，但是这个好像不对。
auto mp = new modulatedParameter(sp_mp->p);
mp->add(&myMod)
sp_mp = new smoothedParameter(0.01, smManager, mp));
The point of decorator design is that objects can have a different set of functions. ...It seems like I'd need to have an "add/remove" function for every class, defeating the purpose of this design.
没有。与几乎所有最著名的模式一样，装饰器模式都是关于接口的，因此（在 C++ 中）是虚拟成员函数。
你定义你的基础class（抽象的或者你想用作基础的具体的），其中可以装饰的方法是虚拟的。
装饰器 decores 存在的东西，它既不添加也不删除功能。
每当您定义装饰器时，您最终都会覆盖这些方法以丰富它们并迭代调用相同方法的基础 class 实现。然后你将 pointers/references 传递给基础 class 并且用户不知道它们是否经过装饰。只要调用它，正确的事情就会发生。
让我们考虑一下。如果您添加一个新方法，您如何从一个引用或指向基 class 的指针调用它？你不能，所以你需要实际类型，即派生类型。
这违背了设计的目的，而不是您必须向基础添加方法class才能在派生的基础中装饰它的事实。
如果您正在寻找一种模式，可以让您在 class 中添加或删除函数，请考虑混合或其他。这不是装饰者的目标。
The point of decorator design is that objects can have a different set of functions.
不，装饰器的意义在于能够灵活扩展对象的基本功能，同时保留其核心。通常，"flexibly" 一词假定在 运行 时间 进行此扩展 （动态）。
同时，C++是静态类型语言。这意味着 object/variable 的类型定义了您 可以 对它做什么以及您 不能 做什么。 sp_mp->add(&myMod); 可能的 IIF 变量 sp_mp 的类型 (class) 具有 add(...) 函数。这个决定是在编译时做出的，没有设计模式可以改变这个事实，只是接受它。 C++ 编译器不会让您调用不属于其类型的变量的 functions/use 成员变量。
无论你做什么，现有类型的接口都是静态定义的。想改变它吗？在编译时执行。
现在，考虑到所说的一切，我们可以得出一个合乎逻辑的结论：
如果您想向现有类型添加一些新功能 - 创建一个新类型。
这里或多或少是 classic（我相信）装饰器实现。
*我没有使用共享指针只是因为...... OP 也没有使用它们:)
class ICore
{
public:
virtual std::string Description() = 0;
void Describe() {
std::cout << "I am " << Description() << std::endl;
}
};
class Core final : public ICore
{
public:
std::string Description() override {
return "Core";
}
};
class IDecorator : public ICore
{
protected:
ICore* core;
public:
IDecorator(ICore* _core)
: core{ _core }
{ }
virtual ~IDecorator() {
delete core;
}
};
class Beautiful final : public IDecorator
{
public:
Beautiful(ICore* _core)
: IDecorator{ _core }
{ }
public:
std::string Description() override {
return "Beautiful " + core->Description();
}
};
class Shiny final : public IDecorator
{
public:
Shiny(ICore* _core)
: IDecorator{ _core }
{ }
public:
std::string Description() override {
return "Shiny " + core->Description();
}
};
int main()
{
ICore* core = new Core;
ICore* decorated_core = new Beautiful{ new Shiny{ core } };
core->Describe();
decorated_core->Describe();
delete decorated_core;
return 0;
}
输出：
I am Core
I am beautiful shiny Core
如您所见，这里的 Decorator 没有更改接口（class 原型）——没有向核心添加新功能。此外，它没有更改任何现有功能。然而，它所做的是对已经存在的行为的扩展。它从字面上 装饰 core 的描述 2 个新词 。请注意 - 这个 装饰发生在 运行 时间 。如果我们决定将装饰顺序从 new Beautiful{new Shiny{core}} 更改为 new Shiny{new Beautiful{core}}，则词序也会更改（从 beautiful shiny Core 到 shiny beautiful Core）。
但是，如果您真的非常想实现您的主要目的 - 添加带有装饰器的全新功能...有一种方法可以让您模仿这种行为。它在 C++14 中看起来很难看，所以这里是 C++17 代码：
class Core
{
public:
void CoreFunctional() {
std::cout << "Core functional." << std::endl;
}
};
template<typename T>
class Extend : public virtual T
{
public:
Extend() = default;
Extend(const T&) { }
public:
void ExtendedFunctional() {
std::cout << "Extended functional." << std::endl;
}
};
template<typename T>
class Utility : public virtual T
{
public:
Utility() = default;
Utility(const T&) { }
public:
void UtilityFunctional() {
std::cout << "Utility functional." << std::endl;
}
};
int main()
{
Core core;
core.CoreFunctional();
auto decorated_core = Utility{Extend{core}};
decorated_core.CoreFunctional();
decorated_core.ExtendedFunctional();
decorated_core.UtilityFunctional();
}
输出正如您所期望的那样，但我不太确定，是否可以将其视为装饰器...