属性模式的优缺点是什么？ [英] What are the advantages and disadvantages of the Properties Pattern?

问题描述

Steve Yegge在属性模式 =noreferrer>博客。

Steve Yegge describes the Properties Pattern in a blog post of his.

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

For someone using a static language like C# or Java, what are the advantages and disadvantages of this approach? In what kind of projects would you want to use the Properties Pattern, and when would you want to avoid it?

推荐答案

我最近一直在挖掘这种模式，我可以告诉你，找到关于它的信息是非常困难的。 Yegge称之为原型或属性，但这两者都相当高度过度使用，而且被称为另外两种不同的模式。有人指的是像Yegge所提出的那样系统化的系统，这是另一种研究方向。

I've been digging into this pattern quite a bit myself lately, and I can tell you that finding information on it is pretty tough. Yegge calls it prototype or properties, but both of those are pretty heavily overused, and well known as two other, different patterns. Some people refer to systems like the one Yegge proposes as "stringly[sic] typed" so that's another avenue of research.

这是一个非常整洁的想法，在一些应用中有很多优点，而在其他应用中有很多缺点。您获得的本质上是在运行时构建类型的非常灵活的方法，但是您输入了很多语言强类型检查来执行此操作。实现它的最简单的方法是作为一个字典< string，string> 。那么你必须使用转换来将你的字符串值作为实际值返回。保持这种设计可管理的关键是如果您能避免这种设计，从不直接引用代码中的属性。东西像 theProtoObject [owner] =protoman会杀死你，如果该槽的规范名称更改。它也可能会导致诸如JavaScript之类的问题（使用下面的模式作为对象模型），如果您输入密钥名称，您将添加一个新插槽。

It's a really neat idea, and one that has a lot of merit in some applications, and a lot of faults in others. What you gain is essentially a very flexible means of building "types" at runtime, but you lose out on a lot of the languages strong-type checking to do it. The easiest way to implement it would be as a Dictionary<string,string>. Then you have to use casts to get your string values back out as actual values. The key to keeping such a design manageable is to never directly reference a property in code if you can avoid it. Stuff like theProtoObject["owner"] = "protoman" will kill you if the "canonical" name of that slot changes. It can also lead to issues like JavaScript (which uses this pattern underneath as it's object model) where if you misspell the key name, you'll add a new slot.

您在生产系统中可能升级的一个可能性就是使用某种特殊类型的价值观，以及某些重钥匙的关键，所以您可以在您的产品上获得一些额外的打字和安全信息模型。

One very likely upgrade you'd probably make in a production system is to use some kind of specialized types for values, and some kind of "heavy key" for the key, so you can get a bit of extra typing and safety info on your model.

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

I've seen a few applications that use it. One surprising example hit me recently while looking up open source code in my industry: insurance quoting. OpenQuote is a very flexible project for quoting insurance of any general type. It's written in Java, but if you know C# it should read quite well. At the very heart of it, lies the Type object, which contains this bit of code:

/** A dynamic collection of attributes describing type */
private List<Attribute> 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.

所以基本上属性是一种关键包含唯一字符串ID（字段名称）和字符串值的值对，以及与某些正则表达式组合的类型的枚举，以验证和处理值。这样，它可以存储许多类型的值，并将它们转换成java值，同时提供一些安全性。

So basically Attribute is a kind of key-value pair containing a unique string ID (the field name) and a string value, and an enumeration of types combined with some regex to verify and process the values. In this way, it can store values of many types, and convert them back out into java values, while providing a bit of safety.

然后继续构建许多该核心顶部的域特定模型类型。因此，保险单对象可被视为具有灵活，可扩展的利益清单，可在运行时添加或删除或修改。每个利益都可以扩展或减少他们的财产。

It then goes on to build many domain specific model types on top of that core. So an insurance policy object can be treated as having a flexible, extensible list of benefits on it, which can added or removed or modified at runtime. Each benefit can have properties extended or reduced on them as well.

所以这是使用模式的一个例子，它是一个体面的用例：保险单可以非常灵活，在承销商直到销售的时刻，所以一个高度灵活的模式对它很有效。

So that's an example of the pattern in use, and a decent use case for it: insurance policies can be very flexible, at the whim of the underwriters up to the moment of sale, so a highly flexible model works well for it.

缺点是Yegge概述了。性能可能不好，尤其是天真的实现。类型检查和安全性受到打击，您的对象更难理解，因为您不知道他们身上有什么属性。

The downsides are pretty much what Yegge outlines though. Performance can be bad, especially with a naive implementation. Type-checking and safety take a hit, and your objects are more difficult to reason about because you don't know for sure what properties are on them.

这篇关于属性模式的优缺点是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！