Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Richard Maher Newsgroups: comp.lang.java.programmer Subject: Re: Interface with implied Constructor Date: Sat, 20 Jul 2013 12:42:46 +0800 Organization: Aioe.org NNTP Server Lines: 50 Message-ID: References: <925adeb1-65b5-4a50-86a8-4f04784f8da0@googlegroups.com> <5CiGt.85244$ny.24125@fx14.iad> NNTP-Posting-Host: jOhPn0KFjrxwuMc9OPMmCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:24771 On 7/20/2013 7:46 AM, Arved Sandstrom wrote: > On 07/19/2013 07:10 PM, Eric Sosman wrote: >> On 7/19/2013 5:56 PM, Arved Sandstrom wrote: >>> [...] >>> Which is one reason you use abstract classes. If you want to supply >>> constructors, implement them, and put them in an abstract class. It's >>> the right place: in my continuing opinion ctors are an implementation >>> detail. >> >> Uhm, sorry, I don't get it. Such a constructor would only >> be callable from the constructor of a subclass, and there's still >> nothing to require that the subclass provide any particular style >> of constructor. >> >> (As mentioned elsethread I don't think interface-mandated >> constructors would be useful. I'm just wondering how you'd use >> abstract classes to achieve the not-so-useful effect.) >> > Sure, it's imperfect. The best you can hope for is the the subclass uses > one of the provided constructors. It works reasonably well with Exception. > > But like I said I don't think much of any system that attempts to > mandate how a class builds itself. I always figured that was up to the > class itself. I didn't say "mandated" and I'm not sure anyone else did besides yourself. In the case of my Applet where I'm controlling the mainline (via and init() method ironically enough). The user-supplied class, for getting things like username/password etc and optionally displaying a console window, is going to be pretty specialized. However, if a generic(ish) class you have happens to provide an opportunity for code re-use then that's peachy. The closest I get to "mandatory" is to say "Regardless of any other constructors, I require you to provide either an empty constructor or one which takes a Tier3Ambience object as its only parameter". If you're all so in love with init() methods then after setting non-standard-constructor-init-reqd = true in the constructor, your getSalutation() method can call all the functionality it wants even passing "this" for callbacks if it so desires. For dynamically, run-time loaded, code I just like my method. If you'd prefer not to avail yourselves of all the lovely methods that Tier3Ambience makes visible to you then don't use it. > > AHS Cheers Richard Maher