Building a structure/object in a place other than the constructor

Question

I have different types of objects representing the same business entity. UIObject, PowershellObject, DevCodeModelObject, WMIObject all are different representation to the same entity.

So say if the entity is Animal then I have AnimalUIObject, AnimalPSObject, AnimalModelObject, AnimalWMIObject, etc.

Now the implementations of AnimalUIObject, AnimalPSObject, AnimalModelObject are all in separate assemblies.

Now my scenario is I want to verify the contents of business entity Animal irrespective of the assembly it came from. So I created a GenericAnimal class to represent the Animal entity.

Now in GenericAnimal I added the following constructors:

GenericAnimal(AnimalUIObject)
GenericAnimal(AnimalPSObject)
GenericAnimal(AnimalModelObject)

Basically I made GenericAnimal depend on all the underlying assemblies so that while verifying I deal with this abstraction.

Now the other approach to do this is have GenericAnimal with an empty constructor an allow these underlying assemblies to have a Transform() method which would build the GenericAnimal.

Both approaches have some pros and cons:

The 1st approach:
Pros: All construction logic is in one place in one class GenericAnimal
Cons: GenericAnimal class must be touched every-time there is a new representation form.

The 2nd approach:
Pros: construction responsibility is delegated to the underlying assembly.
Cons: As construction logic is spread accross assemblies, tomorrow if I need to add a property X in GenericAnimal then I have to touch all the assemblies to change the Transform method.

Which approach looks better ?
or Which would you consider a lesser evil ?
Is there any alternative way better than the above two ?

Just to elaborate further based on the comments i received. I dont have the luxury the modify the structure of underlying objects, ie i cant change AnimalUIObject AnimalPSObject etc. The GenericAnimal is a construct introduced just for validation purposes by me.

Answer 1

I think both approaches are pretty "evil".

I think what you really need is to start with the Animal class as your core class, and make the rest of the classes wrapper classes that use the Animal class to hold the representation. Validation is then performed against the Animal API.

Answer 2

May be an opportunity for an abstract factory pattern ?

Answer 3

I have different types of objects representing the same business entity. UIObject, PowershellObject, DevCodeModelObject, WMIObject all are different representation to the same entity.

Take a look to Design Patterns in general and in particular to Structural Pattern.

In my understanding the Decorator Pattern would be useful:

The decorator pattern can be used to extend (decorate) the functionality of a certain object at run-time, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class

So it should be the first approach but w/o the cons:

The GenericAnimal class will have a constructor:

GenericAnimal(AnimalObject)

With AnimalObject either an interface or abstract class.

Cons: GenericAnimal class must be touched every-time there is a new representation form.

If you add another representation form make it implements or extends AnimalObject.