lets say I have several objects Object A,Object B,Object C in different parts of my project. I have defined a Object X that is only used to store some specific values from the objects mentioned above plus some other context data, only getters and setters functions, and pass it on to another layer or service. What would be the best practice to create a method to fill my Object X.

Option 1

Define in a single package all the methods necessary to move the values.

Class FillObject{
   public static ObjectX fill(ObjectA a, contextVariableA ctx){
      ObjectX x = new ObjectX;
      return x;

   public static ObjectX fill(ObjectB b,contextVariableB ctx1, contextVariableB ctx2){
      ObjectX x = new ObjectX;
      return x;

That way when I need to fill ObjectX in the package where ObjectA exist I can just do:

// ObjectA myA was define prior to this line
ObjectX myX = FillObject.fill(myA,ctxVar);

I can use the same approach in another package where ObejectB exists.

Option 2

Define several constructors for ObjectX to handle the creation of the object based on the type of the arguments.

  • Is there no common interface for these objects that declares getName()?
    – cHao
    May 24 '18 at 19:35
  • What's your main premise? Decoupling? Simplicity? Reusability?
    – Laiv
    Nov 7 '18 at 7:53

Does X know about A, B, and C? You can always create static factory method inside X to create itself from the others. You often see this self-contained factory pattern in .NET classes. It removes the necessity for factory classes.

class ClassX
    public static ClassX FromA(A a, Settings settings)
        var x = new ClassX();
        // do setup with variables
        return x;

var a = new A();
a.Stuff = 'Things';
var settings = new Settings('something', 123);

var x = ClassX.FromA(a, settings);

Where you may need a factory class is where the output class does not know about its input classes, for example if you are bringing together two unrelated libraries.

SomeLibrary.A a = new SomeLibrary.A(); // some other library
OtherLibrary.X x = MyFactory.XFromA(a); // my code using A and X libraries.

Offhand, design-wise, I'm not too "cozy" with the notion of "an Object X that knows about Objects A, B, C," because ... well, "what about Object D, when we define it six months from now?" I'd prefer that Object X be fairly agnostic.

Instead, I'd prefer to put this functionality into the A,B,C objects – that is to say, into a superclass that is common to all three of them. This superclass-method might be, say, insertIntoObjectX(ObjectX foo). This class is a "friend" of Object X and thus able to access a method within Object X that is set aside for this purpose. And then, as a further check, this method (of Object X) will verify that the calling object "is a" member of the specified superclass (multiple inheritance).

Now, I have a flexibly extendable architecture: anything that is a member of the specified superclass is able to be inserted into Object X, and, if Object X needs special help from whatever-object is being inserted into it, it knows that it can avail itself of (protected ...) methods of that superclass. I know that I only have two pieces of source-code to consider – the definition of Object X, and the definition of the superclass.

That's an architecture that I could live with long-term.


Your example suggests no difference between how A and B are used. In fact it looks more like a single fill function, with A and B implementing a Named interface, and two more contexts variables (the last being optional).

In general though this sort of function is a transform. It should live as a helper function close to its usage. If it is more general, try and keep it separate from the A and B classes and from Class X. The only exception is when A or B are domain related to X.

Domain related is in the sense of a wheel to a car. Not in the sense of a person to a car. The first is integral, it is hard to seperate the two. The second comes and goes, it is even possible to have one entirely without the other.


You say you want to pass Object X to another layer. Then Object X should not know about object a, b or c. This is because if you ever change anything to object a, b or c, you could very well end up changing object X, which could then end up leaking into that other layer.

As a rule, if you pass an object around to different layers in your architecture, it should have as little dependencies as possible.

The FillObject class in your example is fine. I'd suggest renaming it to something containing Factory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.