用于更多类的模板化律师-客户惯用语 [英] templated Attorney-Client Idiom for more many classes

查看:91
本文介绍了用于更多类的模板化律师-客户惯用语的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图将律师-客户习语(称为PassKey习语)应用到两个课程中。

I was trying to apply the Attorney-Client Idiom (know as PassKey Idiom) and this for two classes.

我解释一下:

我有一个名为 Secret 其中包含 age 作为私人成员。我创建了一个类律师,它为类 Secret 中的每个成员定义了2个getter。

I have a class named Secret which contains name and age as private members. I have created a class Attorney which defines 2 getters for each memeber in class Secret.

我想创建2个类:


  1. showAge 只能访问1个吸气剂

  2. showAgeAndName 可以访问两个吸气剂。

  1. showAge which only have access to 1 getter
  2. showAgeAndName which has access to both getters.

到目前为止,一切正常,但是看代码,它的维护性不好:如果我在 Secret 并且想要特定地访问新的吸气剂,我必须添加另一个类并以大量复制粘贴结尾。

So far all works fine, but looking at the code, it not well maintainable : if I add new members to my Secret and want a specific access to new getters I have to add another class and end with lot of copy-paste.

那么还有更好的替代方法:使用Factory设计模式/增强模板化类...

So is there a better alternative like : using Factory design pattern / enhance the templated class ...

以下是我的代码:

#include <string>
#include <iostream>

using namespace std;

class Secret;
class showAge;
class showAgeAndName;

template<typename T>
class Attorney
{
private:
    friend T;
    Attorney(const Attorney&) {}
    Attorney() {}   
};

class Secret
{
public:
    std::string getAge(Attorney<showAge>) noexcept { return "Age is " + to_string((long long)age); }
    std::string getName(Attorney<showAgeAndName>) noexcept { return "Name is " + name; }
private:
    int age{36};
    std::string name{"Mike"};
};

class showAge
{
public:
    showAge() noexcept {};

    void showInfos(Secret& src)
    {
        std::cout << src.getAge(Attorney<showAge>()) << std::endl;
    }
};

class showAgeAndName
{
public:
    showAgeAndName() noexcept {};

    void showInfos(Secret& src)
    {
        std::cout << src.getName(Attorney<showAgeAndName>()) << std::endl;
    }
};

int main() {
    Secret s;
    showAge prA;    
    showAgeAndName prAn;
    prA.showInfos(s);
    prAn.showInfos(s);
}

谢谢

推荐答案

在我看来,这种模式比它值得的麻烦更多。

In my opinion this pattern is more trouble than it's worth.

相反,也许您会考虑为每次访问定义接口角色,然后通过引用将对象传递给适当的接口类型。尽管可能仍然需要您为每个角色定义和维护接口,但这可能更易于阅读和直观。

Instead, maybe you'd consider defining interfaces for each access role, then pass the object around by references to the appropriate interface type. This is likely to be far more readable and intuitive, although it still requires you to define and maintain interfaces for each role.

接口及其所公开的成员函数应为选择适合访问角色。您不必为每个功能单独使用一个接口。如果您认为这样做的话,我会将其视为代码气味,并将其作为提示重新评估设计。

The interfaces and which member functions they expose should be chosen to suit the access roles. You do not necessarily need a separate interface for each function. If you think you do, I'd view that as a code smell and take it as a cue to reevaluate the design. This is true when using the Attorney-Client / PassKey pattern as well.

Attorney-Client / PassKey模式唯一的优点是它不需要成员功能是虚拟。但是虚拟功能的性能成本很可能对您的应用程序并不重要

The only advantage the Attorney-Client / PassKey pattern has is that it doesn't require the member functions to be virtual. But it is very likely that the performance cost of virtual functions is not important to your application.

缺点是Attorney-Client / PassKey模式会鼓励您根据特定用户设计接口(例如在访问的特定类中)秘密)。这样会创建耦合。最好从可以适当分配的通用角色考虑。

A disadvantage is that the Attorney-Client / PassKey pattern encourages you to design the "interfaces" based on specific users (as in specific classes that access the Secret). This creates coupling. It is better to think in terms of generic roles, which can be assigned as appropriate.

这篇关于用于更多类的模板化律师-客户惯用语的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆