Re: Defining a constructor in an Interface

Chris Smith wrote:
That said, I don't think there's ever a good excuse for requiring a constructor that takes parameters.

Well, such a requirement, or lets better say nice-to-have feature, can come up when you want to have a 1:1 translation of your design model to an implementation. I perfectly understand (at least I think so) why things are as they are, but it would be nice to have it otherwise.

Assume you have modeled some resource reservation system with a ResourceRequest class and a User class. A ResourceRequest is always associated with a User requesting a resource in your model. There should never be a ResourceRequest without one.

To ensure this it would be easy to have a constructor

	public ResourceRequest(User user) { }

You would just have to guard for a null argument in the constructor. If you write a Bean or have other reasons to only have a no-argument public constructor you make it easier to misuse the ResourceRequest class, because people can suddenly construct ResourceRequests without an associated User.

So you have a case where it is required to follow some additional convention in order to use a class correctly. One more source for potential bugs. You can of course work around this by providing a factory for constructing ResourceRequests which enforces the requirement. But you have to write more code. More code - more potential bugs.

/Thomas


--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
.

Quantcast