多封装,少开放。强烈建议C++标准添加class之间的注入机制「建议收藏」

多封装,少开放。强烈建议C++标准添加class之间的注入机制

大家好,又见面了,我是全栈君。

近日在改动了一下下引擎代码(为了自己的组件),发现有些接口是仅仅有特定类及其内部函数才去訪问,却不使用友元声明的形式进行数据訪问——当然使用了普通非virtual的形式也就是意味着不建议重载。

故此:

1、建议派生类(或同意)重载的声明为虚函数即virtual类型,

2、强制派生类实现的声明为纯虚函数

3、不希望派生类重载或覆盖的函数则为普通类,假设訪问群体有限定范围或者范围比較少。能够考虑添加友元+protected的方式进行訪问控制,从而实现有效设计信息传达。可是有的时候我们不能保证可能须要訪问的友元,或者说另外的类不是我们设计的。就会出现开篇提到的现象。鉴于这样的情况,我认为C++应该添加一个注入机制,在编译期间同意其它类去訪问另外的类的protected函数,而不是只通过继承。或许说友元已经足够了,可是友元的局限太明显了。

 

机制实现细节例如以下:

regAble class A

{

protected:

void visit;

//something else

};

class B:reg A

{

A * p;

void visit()

{

p->visit();

}

}

4、假设某个操作同意重写,最好使用virtual的形式,即便丧失了小部分性能,可是还是能够原先多样化的操作。这样子和3产生强烈的对照,降低代码设计相干,降低思维耦合

以下这段是一段很优秀的代码:

/**
     * Sets the arrival order when this node has a same ZOrder with other children.
     *
     * A node which called addChild subsequently will take a larger arrival order,
     * If two children have the same Z order, the child with larger arrival order will be drawn later.
     *
     * @warning This method is used internally for localZOrder sorting, don't change this manually
     *
     * @param orderOfArrival   The arrival order.
     */
    void setOrderOfArrival(int orderOfArrival);

当我看到这种凝视。我马上明确自己是否须要处理改接口。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/115746.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号