Decoupling musing

Thread view:

VisionSet - 20 Nov 2005 17:44 GMT

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;
}

--
Mike W

Reply to this Message

Daniel Dyer - 20 Nov 2005 20:46 GMT

> Not seen this done but it stikes me as a approach that may have some
> merit.
[quoted text clipped - 16 lines]
> 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.

Signature

Daniel Dyer
http://www.dandyer.co.uk

Reply to this Message

VisionSet - 20 Nov 2005 23:02 GMT

> 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.

--
Mike W

Reply to this Message

Roedy Green - 20 Nov 2005 23:14 GMT

> 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.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

VisionSet - 20 Nov 2005 23:15 GMT

> ...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.

--
Mike W

Reply to this Message

Andrew McDonagh - 20 Nov 2005 23:30 GMT

>> X x = myClassOfX.newInstance();
>
[quoted text clipped - 5 lines]
> 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.

Reply to this Message

Decoupling musing

Free Magazines