属性模式有哪些优缺点？

Steve Yegge 在他的博客文章中描述了属性模式.

对于使用C#或Java等静态语言的人来说,这种方法有哪些优点和缺点？在什么样的项目中你想要使用属性模式,什么时候你想避免它？

我最近一直在深入研究这种模式,我可以告诉你,找到它的信息非常困难.Yegge将其称为原型或属性,但这两者都被过度使用,并且众所周知为另外两种不同的模式.有些人将Yegge提出的系统称为"字符串[sic]类型",这是另一种研究途径.

这是一个非常巧妙的想法,在某些应用程序中有很多优点,在其他应用程序中有很多缺点.你获得的本质上是一种在运行时构建"类型"的非常灵活的方法,但你会失去许多强类型检查语言.实现它的最简单方法是Dictionary.然后你必须使用强制转换来将你的字符串值作为实际值返回.保持这种设计可管理性的关键是如果可以避免,就永远不要直接引用代码中的属性.喜欢的东西theProtoObject["owner"] = "protoman"会杀了你的那个槽的变化"规范"的名字.它也可能导致像JavaScript这样的问题(在它下面使用这个模式作为它的对象模型),如果你拼错了键名,你将添加一个新的插槽.

您可能在生产系统中进行的一次非常可能的升级是使用某种特殊类型的值,以及键的某种"重键",这样您就可以获得一些额外的输入和安全信息.模型.

我见过一些使用它的应用程序.一个令人惊讶的例子最近在我看到我的行业中的开源代码时遇到了我:保险报价. OpenQuote是一个非常灵活的项目,用于报价任何一般类型的保险.它是用Java编写的,但是如果你知道C#就应该读得很好.它的核心是Type对象,它包含以下代码:

/** A dynamic collection of attributes describing type */
private List attribute = new ArrayList();

什么是Attribute？这个:

* An attribute is defined as "One of numerous aspects, as of a subject". Generally, another
* type will own a (composite) collection of Attributes which help describe it.

因此,基本上Attribute是一种键值对,包含唯一的字符串ID(字段名称)和字符串值,以及与某些正则表达式相结合的类型枚举,以验证和处理这些值.通过这种方式,它可以存储多种类型的值,并将它们转换回java值,同时提供一些安全性.

然后,它继续在该核心之上构建许多特定于域的模型类型.因此,保险政策对象可以被视为具有灵活,可扩展的利益列表,可以在运行时添加或删除或修改.每个好处都可以扩展或减少它们的属性.

这就是使用模式的一个例子,也是一个不错的用例:保险政策可以非常灵活,在承销商的心血来潮之前,直到销售时刻,所以一个高度灵活的模型适用于它.

缺点是Yegge概述的内容.性能可能很糟糕,尤其是在实施过程中.类型检查和安全性受到打击,您的对象更难以推理,因为您不确定它们上面有哪些属性.