Re: Interface with implied Constructor
In article <kscaks$4qd$4@dont-email.me>,
Martin Gregorie <martin@address-in-sig.invalid> wrote:
On Fri, 19 Jul 2013 12:38:19 -0700, Gene Wirchenko wrote:
On Thu, 18 Jul 2013 23:21:35 -0300, Arved Sandstrom
<asandstrom2@eastlink.ca> wrote:
[snip]
I'll be honest, Robert, personally I consider the behaviour of an object
- the kinds of things you could specify in an interface - to be what the
*initialized* object can (should) do.
But there is more to it than that. There is also getting it
initialised. That should also be part of the API. I would not enforce
that it has to, but I sure would like the option to specify constructor
signatures in an interface.
Yes, agreed. I tend to extend superclasses instead of using an interface
for exactly that reason.
I seriously dislike init() methods, not just in Java. Particularly if
there is no sensible un-init()'ed object for the class. I just don't see
any credible argument for them. Like Richard said, actually:
"half-baked".
I take the opposite approach to Robert over that for one reason: that the
only way to report init errors in a constructor is to throw an Exception,
which means the instance declaration often needs to go inside a try/catch
block which can screw up scoping. If init errors are possible and must be
caught, I prefer to use a constructor that can't do anything that needs
an Exception to be thrown and finish the job with an init() method that
can go in the following try/catch block along with (some of) the other
method calls.
You never want public constructors that produce incomplete objects.
They pollute your application and cause recurring failures long after
the original fault. It's too difficult to debug all the places where
the object is constructed and possibly leaks out of scope without full
initialization. It's best if the minimum requirements for an object's
functionality are assigned in the constructor and 'final'.
I only use initialization methods for private implementations where it's
easy to control the scope of an uninitialized object. A typical case is
where a new cached object takes a very long time to initialize.
Simplified example:
private final HashMap<String, CachableThing> cache=
new HashMap<String, CachableThing>();
private static class CachableThing implements Thing
{ ... }
public Thing getThing(String key) throws SomeException
{
CachableThing t;
synchronized (cache)
{
t= cache.get(key);
if (t == null)
cache.put(key, t= new CachableThing());
}
synchronized (t)
{
if (!t.initialized())
t.init(key); //Very slow and may intermittently throw
}
return t;
}
--
I will not see posts from Google because I must filter them as spam