Как мне требовать разные поля для одного и того же объекта, когда возвращаются из разных методов?

Question

У меня будет несколько методов компонента WCF, возвращающих общий объект. В некоторых случаях поля A, B, C, D должны быть ненулевыми, но в других случаях поля B, F, G, Q могут быть ненулевыми.

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

Возможно, я не смогу изменить общий объект, т. Е. Он определен другой командой.

Есть шаблон или стратегия, которая может сделать это легко?

Спасибо!

Answer 1

Вам необходим объект адаптера, который знает, как обрабатывать оба (все) случая или (возможно) лучше, несколько адаптеров, каждый из которых знает, как обрабатывать свои собственные случаи.

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

Например,

CommonObjectFromWCFGuys cofwg = wcf.SomeMethod( someParam );
AdapterForABCD abcd = new AdapterForABCD( cofwg );
abcd.ValidateRequiredFields( );
SomeInternalBusinessMethod( abcd );

Ваш 'SomeInternalBusinessMethod' может требовать определенных полей, но вы не можете заставить другую команду вернуть эти поля, вы можете просто проверить их в своем коде перед их использованием.

Answer 2

Из того, что сказал yetapb, вы можете иметь два или более объекта-адаптера, которые реализуют один и тот же интерфейс.Таким образом, когда вы вызываете SomeMethod, который возвращает объект, требующий полей (A, B, C, D), вы передаете его одному объекту адаптера.Когда вы вызываете SomeOtherMethod, для которого требуются поля (B, F, G, Q), вы создаете экземпляр другого класса адаптера.

Если оба они реализуют общий interce, вы можете поместить что-то вроде метода IsValid в интерфейси ссылаться на интерфейс локально в вашем коде только после того, как вы проверили IsValid.Каждый класс адаптера затем реализует свою собственную логику для обязательных полей.

Локально, вы никогда не будете обращаться непосредственно к любому из предложений адаптера в вашем коде, а скорее к своему интерфейсу.

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