Плохая идея иметь один и тот же объект, иметь другой побочный эффект после вызова метода - PullRequest
Новая
       18

Плохая идея иметь один и тот же объект, иметь другой побочный эффект после вызова метода

1 голос
/ 15 июля 2009

У меня возникла небольшая проблема (снова). Скажем, у меня есть объект Buttonpad:

альтернативный текст http://img530.imageshack.us/img530/7513/buttonpad.jpg

теперь этот объект является объектом-оболочкой над объектом в объекте com. На данный момент у него есть метод с именем CreateInto (IComObject) . Теперь создайте новую кнопочную панель в объекте Com.

Вы делаете: 

 ButtonPad pad =  new ButtonPad();
 pad.Title =  "Hello";
 // Set some more properties.
 pad.CreateInto(Cominstance);

Метод createinfo выполнит правильные команды для создания кнопочной панели в объекте com. После того, как он был создан, любые вызовы против него направлены на изменение базового объекта так: 

pad.Title = "New title";

вызовет объект com для установки заголовка, а также установит внутреннюю переменную заголовка.

По сути, любые вызовы до метода CreateInfo влияют только на объект .NET, после чего возникает побочный эффект вызова объекта com. Я не очень хорош в диаграммах последовательности, но вот моя попытка объяснить, что происходит:

альтернативный текст http://img196.imageshack.us/img196/5885/seqa.jpg

Мне это не нравится, мне кажется, что я лгу пользователю о том, что делает кнопочная панель.

Я собирался иметь объект с именем WrappedButtonPad, который возвращается из CreateInto, и пользователь мог сделать вызовы для этого, чтобы внести изменения в объект Com, но я чувствую, что есть два объекта, которые почти делают одно и то же, но отличаются только на имена могут быть еще хуже.

Это действительные образцы или я прав, что беспокоюсь?

Как еще вы можете обработать объект, который можно создать, и запросить ком-объект?

Ответы [ 3 ]

0 голосов
/ 15 июля 2009

Я бы согласился с ответом Джона.

Другой альтернативой будет копирование внутреннего состояния ButtonPad в COM-объект при его создании.

т.е.: Вариант 1 (от Джона) - создать COM-объект из конструктора ButtonPad.

Вариант 2 - отразить состояние ButtonPad для COM-объекта внутри ButtonPad.CreatePad (...). Затем ButtonPad.CreatePad (...) вызовет CreateButtonPad для COM-объекта, а затем вызовет SetTitle () и т. Д. Для COM-объекта перед возвратом, так что ButtonPad гарантирует, что состояние COM-объекта согласованно.

Я бы предпочел вариант 2, если имеет смысл существование ButtonPad без COM-объекта или, возможно, если у вас не было доступа к IComObject, необходимому для создания экземпляра COM-объекта во время создания ButtonPad. В противном случае я бы выбрал вариант 1.

0 голосов
/ 15 июля 2009

Сначала я бы спросил: каков вариант использования для манипулирования ButtonPad свойствами независимо от базовых свойств, которые они скрывают? Скорее всего, есть два ответа на этот вопрос: 1) нет одного, 2) очень важно, чтобы мы могли это сделать.

Ответ в первом случае довольно прост: создайте базовый COM-объект в конструкторе вашего класса, отобразите ваши свойства на его свойства и назовите его day.

Во втором случае вы попадаете на территорию, которая пахнет очень похоже на привязку данных. У вас есть источник данных (ваш объект), то, с чем он связан (COM-объект), необходимость преобразования значений свойств между двумя вещами (например, разбор и форматирование, если связь двусторонняя), и, возможно, даже необходимость отображения изменений свойств с помощью уведомлений о событиях. (Например, если что-то еще манипулирует свойством COM-объекта, нужно ли уведомлять ваш .NET-объект?)

Я не говорю, что на самом деле вы бы хотели использовать привязку для этого, но я бы, конечно, посмотрел на то, как спроектирована привязка данных .NET, и увидел бы, сколько частей этого дизайна вам на самом деле понадобится.

По всей вероятности, вы посмотрите на это и скажете: "Вау, это действительно сложно". Это потому, что то, что вы пытаетесь сделать, очень сложно. Это намного сложнее, если в вашем проекте не реализовано разделение интересов.

0 голосов
/ 15 июля 2009

Я бы позволил кнопочной панели создать свой собственный экземпляр. На вашей диаграмме последовательности я отмечаю, что ButtonPad - это единственный объект, который касается ComInstance. Так что держи его внутри.

...