Let’s say I have to use an unstable assembly that I cannot refractor. My code is supposed to be the client of a CustomerCollection that is (surprise) a collection of Customer instances. Each customer instance has further properties like a collection of Order instances. I hope you get the idea.
假设我必须使用不能折射的不稳定组件。我的代码应该是CustomerCollection的客户端,它是(惊讶)Customer实例的集合。每个客户实例都有其他属性,例如Order实例的集合。我希望你明白这个主意。
Since the assembly behaves not that well my approach is to wrap each class in a façade where I can deal with exceptions and workarounds an all that stuff. (To make things more complicated I like to design the wrapper to be usable with WPF regarding data binding.)
由于程序集行为不是很好,我的方法是将每个类包装在一个façade中,在那里我可以处理异常和变通方法。 (为了使事情变得更复杂,我喜欢设计包装器,以便与WPF一起使用数据绑定。)
So my question is about the design of the wrapper, e.g. CustomerCollectionFacade. How to expose the object tree (customers, orders, properties of orders)? Is the CustomerWrapper collection stored in a field or do I create CustomerWrapper instances on the fly (in the get accessor of a property maybe)?
所以我的问题是关于包装器的设计,例如CustomerCollectionFacade。如何公开对象树(客户,订单,订单属性)? CustomerWrapper集合是存储在字段中还是我即时创建CustomerWrapper实例(可能在属性的get访问器中)?
Any ideas welcome. Thanks!
欢迎任何想法。谢谢!
Edit:
Unfortunately the way proposed by krosenvold is not an option in my case. Since the object tree’s behavior is very interactive (editing from multiple views, events fired if properties change) I will not opt to abandon the ‘source object’. These changes are supposed to propagate to the source. Thanks anyway.
编辑:不幸的是,krosenvold提出的方式在我的情况下不是一个选项。由于对象树的行为非常具有交互性(从多个视图进行编辑,如果属性发生变化则触发事件)我不会选择放弃“源对象”。这些更改应该传播到源。不管怎么说,还是要谢谢你。
1 个解决方案
#1
I generally try to isolate such transformations into one or more adapter classes and let them do the whole story at once. This is a god idea because it is easily testable, all the conversion logic ends up in one place, and you avoid littering the conversion logic "all over the place".
我通常会尝试将这种转换隔离到一个或多个适配器类中,让它们一次完成整个故事。这是一个神的想法,因为它很容易测试,所有转换逻辑都在一个地方结束,你可以避免乱丢“转换逻辑”。
Sometimes there is state in the underlying (source) object that is going to be needed when/if you're updating the object. You might not be exposing this data in your cleaned-up api, so it's going to have to be hidden somewhere.
有时在/更新对象时,底层(源)对象中会出现状态。您可能没有在清理过的api中公开这些数据,所以它必须隐藏在某个地方。
If you choose to encapsulate the original object there's always the chance that someone'll break that encapsulation sometime in the future and start leaking the gory details of the underlying object. That reason alone is usually enough for me to not keep a reference to the original instance, since I actually understand what I'm doing six months later when I'm in a hurry. But if you keep it somewhere else you'll need lifecycle management for the originals, so I usually end up stashing it away in some secret interface on the "clean" object.
如果你选择封装原始对象,那么将来某个人总是有可能打破封装,并开始泄漏底层对象的血腥细节。仅仅这个原因通常足以让我不能保留对原始实例的引用,因为我实际上已经理解了六个月后当我匆忙时我正在做什么。但是如果你将它保存在其他地方你就需要对原件进行生命周期管理,所以我通常最终将它藏在“干净”对象的某个秘密界面上。
#1
I generally try to isolate such transformations into one or more adapter classes and let them do the whole story at once. This is a god idea because it is easily testable, all the conversion logic ends up in one place, and you avoid littering the conversion logic "all over the place".
我通常会尝试将这种转换隔离到一个或多个适配器类中,让它们一次完成整个故事。这是一个神的想法,因为它很容易测试,所有转换逻辑都在一个地方结束,你可以避免乱丢“转换逻辑”。
Sometimes there is state in the underlying (source) object that is going to be needed when/if you're updating the object. You might not be exposing this data in your cleaned-up api, so it's going to have to be hidden somewhere.
有时在/更新对象时,底层(源)对象中会出现状态。您可能没有在清理过的api中公开这些数据,所以它必须隐藏在某个地方。
If you choose to encapsulate the original object there's always the chance that someone'll break that encapsulation sometime in the future and start leaking the gory details of the underlying object. That reason alone is usually enough for me to not keep a reference to the original instance, since I actually understand what I'm doing six months later when I'm in a hurry. But if you keep it somewhere else you'll need lifecycle management for the originals, so I usually end up stashing it away in some secret interface on the "clean" object.
如果你选择封装原始对象,那么将来某个人总是有可能打破封装,并开始泄漏底层对象的血腥细节。仅仅这个原因通常足以让我不能保留对原始实例的引用,因为我实际上已经理解了六个月后当我匆忙时我正在做什么。但是如果你将它保存在其他地方你就需要对原件进行生命周期管理,所以我通常最终将它藏在“干净”对象的某个秘密界面上。