我的项目中有一个要求是在某个类中添加另一个属性 . 现在我想避免更改类,因为我认为它不应该知道他有这个属性(这个属性只在这个项目的上下文中有意义) .
我想要实现这个目标的方式是(请批评这个,因为我想知道是否有更简单的方法可以做到这一点)
添加一个新的单例类,它在我的类的对象和我想要添加的属性的类型之间有一个映射
在此类中添加一个扩展方法(扩展属性?)来访问映射并获取属性 .
有更简单的替代方案吗?这只是不必要的复杂性吗?也许我应该在我班上添加一个新属性?
谢谢!
您所描述的设计实际上是Microsoft用于实现DependencyProperty系统的设计,特别是Attached Properties,尽管在绑定框架的更大上下文中 . 也就是说,使用带有'attached'数据的字典是一种非常典型的解决方案,当您需要为特定用途标记具有附加上下文的类时,但不希望修改该类 .
为什么你说“不继承”?当然,如果你不想改变原始类,那么这样做的方法是继承原始类,然后将你的属性添加到派生类中?
顺便说一句,只有扩展方法,而不是属性,所以你不能通过属性来做 .
我会建议DECORATOR模式 . 我知道你说你不想使用遗产,但有时它更干净 . 该模式仅使用继承来定义接口 .
扩展方法有意义,而且也相对简单 .
[visibility] [type] [methodName](this [class to extend] c, ... more args if necessary) { .... }
添加属性不会破坏类与现有客户端的交互,因此这似乎是“最简单”的方法 .
但更重要的是新 properties 的功能 . 它在逻辑上是现有类的一部分吗?改变 class . 如果没有,那么扩展方法可能更可取,但问题就变成了扩展方法的可见性和客户端的范围 .
一如既往,复杂性是敌人 . 在这种情况下,听起来好像单例是一个非常复杂的解决方案,并且扩展方法是根据范围和visilbity问题进行的 . 改变 class 是最简单的,可能会使长期维护变得更加容易 .
更新:请注意,扩展方法是静态的,这使得扩展方法很难保存任何时间的数据,因为属性将被删除 .
第二个更新:如果您可以访问类的源,请考虑将其设置为部分类,并将新属性放在单独的文件中,但应该是同一个部分类的一部分 . 这样可以将它与类的主体分开以进行维护,并且可以与大多数ORM一起使用 . 但是,存在一个限制,即部分类成员必须位于单个程序集中 .
使用其属性定义Nullable值(而Property仅对此项目有意义)
您的主要问题是您不想更改类本身,因为此要求仅适用于1个项目(构建),我认为您正在考虑SOLID原则,其中一个原则是OCP(开放原则),即,
您的实体必须开放以进行扩展,但已关闭以进行修改
6 回答
您所描述的设计实际上是Microsoft用于实现DependencyProperty系统的设计,特别是Attached Properties,尽管在绑定框架的更大上下文中 . 也就是说,使用带有'attached'数据的字典是一种非常典型的解决方案,当您需要为特定用途标记具有附加上下文的类时,但不希望修改该类 .
为什么你说“不继承”?当然,如果你不想改变原始类,那么这样做的方法是继承原始类,然后将你的属性添加到派生类中?
顺便说一句,只有扩展方法,而不是属性,所以你不能通过属性来做 .
我会建议DECORATOR模式 . 我知道你说你不想使用遗产,但有时它更干净 . 该模式仅使用继承来定义接口 .
扩展方法有意义,而且也相对简单 .
添加属性不会破坏类与现有客户端的交互,因此这似乎是“最简单”的方法 .
但更重要的是新 properties 的功能 . 它在逻辑上是现有类的一部分吗?改变 class . 如果没有,那么扩展方法可能更可取,但问题就变成了扩展方法的可见性和客户端的范围 .
一如既往,复杂性是敌人 . 在这种情况下,听起来好像单例是一个非常复杂的解决方案,并且扩展方法是根据范围和visilbity问题进行的 . 改变 class 是最简单的,可能会使长期维护变得更加容易 .
更新:请注意,扩展方法是静态的,这使得扩展方法很难保存任何时间的数据,因为属性将被删除 .
第二个更新:如果您可以访问类的源,请考虑将其设置为部分类,并将新属性放在单独的文件中,但应该是同一个部分类的一部分 . 这样可以将它与类的主体分开以进行维护,并且可以与大多数ORM一起使用 . 但是,存在一个限制,即部分类成员必须位于单个程序集中 .
您的主要问题是您不想更改类本身,因为此要求仅适用于1个项目(构建),我认为您正在考虑SOLID原则,其中一个原则是OCP(开放原则),即,