从不相关的类中“借用”依赖属性是否可以接受？答案

【问题标题】：Is it acceptable to "borrow" dependency properties from unrelated classes?从不相关的类中“借用”依赖属性是否可以接受？
【发布时间】：2010-09-18 15:04:21
【问题描述】：

我正在编写一个在 WPF 中呈现某些内容的类，我想让用户控制内容的呈现方式。渲染主要是描边线，所以我决定查看 System.Windows.Forms.Shapes.Line 类来了解我可能想要实现的属性。这导致我实现了大部分 StrokeXXXX 属性，这是一项繁重的工作，因为每个属性都需要元数据来影响渲染。

一位同事建议我像这样从 Shape 中“借用”属性：

Shape.StrokeThicknessProperty.AddOwner(typeof(MyType));

这似乎是个好主意。我认为这样做我会失去设置强制和属性更改回调的能力，但看起来采用 PropertyMetadata 的重载允许这样做。我能看到的唯一缺点是如果 Shape 的实现发生变化，它会影响我们的类，但我不确定我期望 .NET 接口多久发生一次显着变化。

你怎么看？当知名类具有您想要的行为和稳定的接口时，这是定义属性的一个不错的捷径，还是在汽油浴中玩火的可靠方法？

【问题讨论】：

标签： wpf dependency-properties

【解决方案1】：

借用 DP 是非常安全和有用的...阅读 WPF 博士关于该主题的 following 帖子！

以下是他提供的一些“提示”：

您应该始终知道所有者类对您借用的任何财产做了什么。
您应该注意默认值和继承。有时您需要一个默认值为 true 的 bool 属性......其他时候您可能需要默认值为 false。有时您需要一个继承的属性……有时您明确不想要继承。（借用 TextElement.FontSize 之类的属性确实会搞砸树中较低的位置。）
所有者类有时可能会定义一个 PropertyChangedCallback，它会干扰您随意使用该属性的能力。始终知道所有者类对属性做了什么。
所有者类可能会为阻止您输入要指定的值的属性提供验证例程。同样，始终知道所有者类对属性做了什么。该属性可以以一种使其性能成本高昂的方式注册，例如 FixedPage.Bottom ，只要对象上的属性发生更改，它就会使父级的排列无效。有时你可能明确地想要这种行为......其他时候它只会不必要地导致布局通过。同样，始终知道所有者类对属性做了什么。
如果您在框架本身尝试使用该属性的场景中使用该属性（例如 ItemsControl 上的 TextSearch.TextPath），您很可能会发现自己与框架发生争用。

【讨论】：

【解决方案2】：

我会继续创建我自己的依赖属性，个人。这实际上并没有太多额外的工作，因此您不必担心任何可能的警告。

【讨论】：