cha*_*log 11 c# c++ attributes design-patterns decorator
我正在考虑将C++用于个人项目.我想让它独立于平台(没有单声道,因为有些平台还不支持它),这就是我考虑C++的原因.
但是我有一个疑问.我已经非常喜欢C#的属性了,我想知道我是否可以在C++中使用类似的东西.
此外,是否可以使用装饰器模式？
编辑:我现在考虑其他可能性或近似值,即.某种方式在运行时将其他行为附加到类.
编辑2:Java不是一个选项,因为有些设备我想将它移植到不支持java.
要在大多数OO语言中"在运行时向类附加其他行为",我建议使用策略设计模式 - 保持类(和/或其实例)(通过C++中的指针,其他语言中的[可重新配置]引用) )一个合适的接口/抽象类的实例,称为"策略接口"(有一种方法[在C++中虚拟,当然,非最终语言有final,等等 - IOW,一种可覆盖的方法! - )]每点可扩展性),通常提供getter和setter方法(或属性或适合特定语言的任何东西)来访问和更改该实例.
最后,类或实例必须通过它所持有的策略接口实例的方法委派所有适当的功能.
我经常推荐这种"高礼式"方法(出于这个特定目的),即使在Python或Ruby这样的动态语言中也可以通过鸭子类型和类对象直接进入内部的能力来实现更多的非正式方法.另一种 - 这种动态能力通常说起来非常有用,但是出于这个特定的目的(我想到"在运行时改变一种类行为"),根据我的经验,一种更高度的架构和控制方法会带来更好的可维护性和更清晰的代码(这一点是有争议的:动态语言社区中的许多开发人员甚至在这种情况下都采用"猴子修补"方法,但是在动态语言(主要是Python)中进行了十几年的成功开发实践,这些都让我倾向于这样做.
在适当的情况下,您可以通过各种方式修改基本的战略DP方法; 例如,当可修改的功能整齐地落入几个有凝聚力的组中时,最好将Strategy对象"分段"为几个简单而有凝聚力的(DrawingStrategy,PersistenceStrategy,BusinessRulesStrategy等).
这整个方法并不取代进行适当的分析,从而不能进行适当的设计,因为它不允许沿着最初未考虑的轴延伸类功能; 相反,该方法旨在作为构建经过深思熟虑的设计的正确方法,以良好控制的方式为可扩展性提供"钩子".如果新的考虑因素发挥作用,可能仍然需要迭代和完善课程的设计以涵盖这些新的想法.但是,在任何丰富,复杂的现实项目中,迭代开发(包括对原始设计的调整和扩展)都是不可避免的 - 策略DP只是你箭袋中的一个箭头,可以帮助使流程更加有序和有效.
对于类属性,是的.只需定义一个名为Attributes的基类来存储属性信息,并在任何需要属性的类中继承它.您可以使用RTTI强制转换查询它.
但是对于方法或参数属性,这基本上不是一个选项.