Как бороться с нестабильным деревом сторонних объектов (извините, я не могу придумать лучшего заголовка)?

Question

Допустим, мне нужно использовать нестабильную сборку, которую я не могу преломить. Предполагается, что мой код является клиентом CustomerCollection, который (неожиданно) представляет собой коллекцию Customer экземпляров. Каждый экземпляр клиента имеет дополнительные свойства, такие как коллекция Order экземпляров. Я надеюсь, вы поняли идею.

Так как сборка ведет себя не очень хорошо, мой подход - обернуть каждый класс в фасад, где я могу иметь дело с исключениями и обходными путями и всем этим. (Чтобы усложнить задачу, мне нравится создавать оболочку, которая будет использоваться с WPF в отношении привязки данных.)

Так что мой вопрос касается дизайна обертки, например CustomerCollectionFacade. Как выставить дерево объектов (клиенты, заказы, свойства заказов)? Хранится ли коллекция CustomerWrapper в поле или я создаю экземпляры CustomerWrapper на лету (возможно, в аксессоре получения свойства)?

Любые идеи приветствуются. Спасибо!

Edit:
К сожалению, способ, предложенный krosenvold, не подходит в моем случае. Поскольку поведение дерева объектов очень интерактивное (редактирование из нескольких представлений, события запускаются при изменении свойств), я не буду отказываться от «исходного объекта». Эти изменения должны распространяться на источник. В любом случае, спасибо.

Answer 1

Обычно я пытаюсь выделить такие преобразования в один или несколько классов адаптеров и позволить им сделать всю историю за один раз. Это идея бога, потому что ее легко проверить, вся логика преобразования заканчивается в одном месте, и вы избегаете засорять логику преобразования «повсюду».

Иногда в базовом (исходном) объекте есть состояние, которое понадобится, когда / если вы обновляете объект. Возможно, вы не выставляете эти данные в своем очищенном API, поэтому их нужно где-то спрятать.

Если вы решите инкапсулировать исходный объект, всегда есть вероятность, что кто-то нарушит эту инкапсуляцию когда-нибудь в будущем и начнет вытекать мрачные детали базового объекта. Одной этой причины обычно достаточно, чтобы я не хранил ссылку на исходный экземпляр, поскольку я действительно понимаю, что делаю шесть месяцев спустя, когда спешу. Но если вы храните его где-то в другом месте, вам понадобится управление жизненным циклом оригиналов, поэтому я обычно заканчиваю хранить его в каком-то секретном интерфейсе для «чистого» объекта.