Decoupling musing

[VisionSet]

Not seen this done but it stikes me as a approach that may have some merit.

Often a class needs to know nothing concrete about the object it is calling
methods on.
However sometimes such a class needs to instantiate this very object and yet
not care so long as it implements interface X.
So why not pass in a Class object that implements X, and do
class.newInstance()

public X createAndProvideAUsefulX(Class<? extends X> myClassOfX) {

X x = myClassOfX.newInstance();

x.doWork(blah);

return x;
}

 

[Daniel Dyer]

Not seen this done but it stikes me as a approach that may have some
merit.

Often a class needs to know nothing concrete about the object it is
calling
methods on.
However sometimes such a class needs to instantiate this very object and
yet
not care so long as it implements interface X.
So why not pass in a Class object that implements X, and do
class.newInstance()

public X createAndProvideAUsefulX(Class<? extends X> myClassOfX) {

X x = myClassOfX.newInstance();

x.doWork(blah);

return x;
}

It's probably a useful approach in some situations. The approach that
tends to be used for this kind of thing is to give the class a reference
to a factory object that can be used to create the instances. The
advantages of using a factory being that you can hide the details of
exactly which classes are used and how the objects are created. With a
factory you could have a create method that used a different class
dependent on the parameters passed in, or you could use cloning,
deserialisation or shared objects instead of invoking constructors, all
without the client class having to know anything about how things work.

Dan.

 

[VisionSet]

It's probably a useful approach in some situations. The approach that
tends to be used for this kind of thing is to give the class a reference
to a factory object...

Yes of course, not thinking straight.
Thanks for clarifying that.

 

[Roedy Green]

X x = myClassOfX.newInstance();

The catch with this approach is you must use a no-arg constructor.
That means you have to do everything you normally would do in the
constructor via setter methods. Your no-arg constructor hatches
malformed objects in many cases that really should not see the light
of day until they have had some setters run. You lose the nice
ability of the constructor to only allow fully formed
logically-consistent objects out into the world.

 

[VisionSet]

...You lose the nice
ability of the constructor to only allow fully formed
logically-consistent objects out into the world.

Oh yes, I realise that, I'm in JavaBean land at the moment (remember?)
And this is with plain JDBC DTO population.

 

[Andrew McDonagh]

The catch with this approach is you must use a no-arg constructor.
That means you have to do everything you normally would do in the
constructor via setter methods. Your no-arg constructor hatches
malformed objects in many cases that really should not see the light
of day until they have had some setters run. You lose the nice
ability of the constructor to only allow fully formed
logically-consistent objects out into the world.

or more rightly, we have to explicitly configure the object, rather than
let it configure itself within the ctor - which is fraught with
problems (think: calling non-final protected or public methods during
construction).

its normally trivial to have the class create fully formed, yet non
working objects - see the NullObject pattern for an example as to how we
can easily over come your concern.

Aside from this approach, its usual (and best practise) to define the
instantiated class to be of an Interface type, so that the instantiating
class does not know the concrete type its creating.

Once we have the Interface we can use Inversion of Control techniques to
get the newly created object, to configure itself by adding to the
interface:

public void configureFromHere(ConfigSource configSource);

....the get the concrete class to decide what data, if any, it needs.