How should I require different fields on the same object when returned from different methods?

Question

I will have multiple WCF component methods returning a common object. In some cases, fields A,B,C,D will be required to be non-null, but in other cases fields B,F,G,Q may be required to be non-null.

I want to indicate to whoever may be creating these methods which fields are required for any particular method. I'd also like to enforce these requirements as well.

I may not be able to change the common object - i.e. it's defined by a different team.

Is there a pattern or strategy that can make this easy?

Thanks!

Answer 1

You need an adapter object that knows how to handle both (all) cases or (probably) better, multiple adapters that each know how to handle their own case.

If you don't have control of the object, then you can't enforce anything on its internals, all you can do is adapt to it in your own code. So the other team will still return the common object. What you do is in your code, create adapter objects that validate your required fields etc.

For example,

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

Your 'SomeInternalBusinessMethod' can then require specific fields, but you can't really force the other team to return those fields, you can just check them in you code before using them.

Answer 2

From what yetapb said, you could have two or more adapter objects that all implement the same interface. That way, when you call SomeMethod that returns an object that requires fields (A,B,C,D), you pass it to one adapter object. When you call SomeOtherMethod that requires fields (B,F, G, Q) you would instantiate the other adaptor class.

If both of these implement a common interce, you could put something like an IsValid method on the interface, and only refer to the interface locally in your code after you've checked IsValid. Each adapter class would then implement it's own logic for the required fields.

Locally, you would then never refer directly to either of the adapter clases in your code, but rather your interface.

Other then that, you are the consumer of the service - you can't guarantee the return object is logically doing what you think it is (and on some levels, you should program defensively around this fact), beyond the operation contract. The underlying idea here is that this approach adds a thin layer of validation to the object.