Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!cs.uu.nl!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Interface with implied Constructor Date: Tue, 09 Jul 2013 21:08:56 -0400 Organization: A noiseless patient Spider Lines: 68 Message-ID: References: <925adeb1-65b5-4a50-86a8-4f04784f8da0@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 10 Jul 2013 01:03:19 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="0d73d8cc209bff1c6395088b400d0605"; logging-data="15738"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18FvGIUJMQ7Ku9gY4FX/s5s" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: Cancel-Lock: sha1:TQpdL99TEiBqEnkaquOgg4eCWTs= Xref: csiph.com comp.lang.java.programmer:24719 On 7/9/2013 6:46 PM, Richard Maher wrote: > On 7/9/2013 7:08 PM, Robert Klemme wrote: >> Why do you want to do that? >> > > For me it's personal preference, but for some technical rationale: - > > If you don't provide sufficient information to the constructor: > 1) You get half-baked objects > 2) Every real (non-init()) method now has to check "Has init() run? Am I > complete?" > 3) If using setters, how do you enforce that they are called in the > correct order? > > Most importantly, Why the hell do you think Java (and all other OO > languages) support arguments to constructors and overloading in the > first place??? Do you think the authors have been wasting their time or > providing redundant technology all these years? Somebody's losing his cool ... > So let me ask you "Why do you want to use setters or an init() method?" Because it's more flexible, perhaps. Do you feel that HashSet should have an (int,boolean,boolean,int,int,Throwable) constructor, just because DataTruncation also has one and both classes implement Iterable? Interfaces are about "contracts," about the "promises" an implementing class makes. Constructors are about initialization of particular class implementations. If interfaces were able to legislate the existence of specified constructors, and if the related "promise" was that an instance so initialized would be complete and functional, then how could you ever implement a class that needed just one little smidgen of additional state? For example: In a recent thread somebody was talking about a ColoredPoint class that carried the notion of a location and an associated color. Let us suppose that this ColoredPoint class implemented a Point interface, and that the interface demanded the existence of an (int x, int y) constructor. Well then, how can a ColoredPoint be sure of getting a color? You could write the required constructor and default the color to mauve, but would that be satisfactory? I don't think so: The eventual user of the class would have to use a constructor not mentioned by the interface, or would have to use a setter also not mentioned by the interface. What benefit would the constructor-mandated-by-interface confer? Granted, the line between "contract" and "promise" can be a bit blurry sometimes. An interface can require the existence of a method with a certain name and parameter list and can influence the return type and visibility, but it cannot really say much about what the function does: An Iterable must have a public hasNext() method of no arguments returning a boolean, but as far as Java is concerned `public boolean hasNext() { return false; }' is entirely satisfactory. On the other side, conventions like JavaBeans require the existence of no-argument constructors and of methods whose names and signatures aren't specified in any interface. I think it's best to think of these as awkwardnesses in the language, shortcomings that should not be imitated except when the need is pressing -- and definitely not as practice to be formalized and sanctified. Finally: If you want abstract classes, ... -- Eric Sosman esosman@comcast-dot-net.invalid