Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!newsfeed.fsmpi.rwth-aachen.de!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Interface with implied Constructor Date: Sat, 20 Jul 2013 20:21:20 +0200 Lines: 75 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 X-Trace: individual.net DjEBEtwop6IaPEeUASs4qwQupQHbnt+UQnmypYNnbUGaT7iEg= Cancel-Lock: sha1:gp6CV+KSOrFwzpF7QEkTLZecEHM= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: X-Antivirus: avast! (VPS 130720-0, 20.07.2013), Outbound message X-Antivirus-Status: Clean Xref: csiph.com comp.lang.java.programmer:24778 On 20.07.2013 20:09, Robert Klemme wrote: > On 19.07.2013 04:21, Arved Sandstrom wrote: >> On 07/14/2013 01:03 PM, Robert Klemme wrote: >>> On 10.07.2013 00:46, Richard Maher wrote: > >>>> So let me ask you "Why do you want to use setters or an init() method?" >>> >>> I opted for the init() method OR factory method pattern. Both are type >>> safe because in both cases a method in an interface needs to be >>> implemented. Picking a constructor solely based on argument types has a >>> looser coupling between the contract and the implementation of it. An >>> interface makes that coupling explicit. > >> 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. > > Of course. A factory instance can also be an initialized object. > >> Often the best way to properly initialize an object is to call a >> constructor with arguments. That's what they are for. And to be honest >> once again, a ctor *is* an implementation thing, IMO: it's not the >> business of an interface to dictate how an implementation will >> initialize objects that can support the interface contract. After all, >> how can an interface even possibly imagine what the internal state of an >> initialized object, hence what ctor args are required, is? > > In situations like Richard's (at least as I understand it) the > environment knows what information it has available and the interface > for the factory can be defined in such a way to pass data potentially > needed or the data that the environment is willing to provide. The > factory implementation then can decide which part of that information is > needed to create the instance and ignore the rest. It's surely better > to let the implementor of the construction process decide which > information to use than the implementor of the environment (or call it > "framework"). > >> No problem with factory methods, except they are for specific >> situations. And I think they also lean more towards implementation. > > What "specific situations" do you have in mind? As far as I can see the > name of the class to create is configured and Richard said reflection > will be used in his initial posting. I think that is a typical > situation where a factory class can be configured which is created via a > no arg constructor and which has a method createFoo(...) with > appropriate arguments. Then there is no need to fiddle with reflection > to analyze constructors and argument lists. Also, this gives more > flexibility as the factory can decide which class to instantiate at > runtime if need be. > > My main point is that I dislike using reflection to _find_ an > appropriate method - be it a constructor or another method. I prefer > that method to be identified in an interface - whether that is an init() > method in the interface of the object I will eventually be using or a > create() method in another interface defining the factory API I care > less. I think Class.forName() and newInstance() is enough reflection to > get flexibility and decoupling but from there on I prefer to use methods > specified via an interface or abstract base class. Adding one bit of reasoning: the reason I dislike the approach to find a method via reflection is that the contract is documented in text only ("the class must have at least a constructor with these argument types...") whereas with an interface the contract is expressed in code as far as possible. (With that I mean there are other languages which allow to define much more aspects of a contract in code, like Eiffel.) That makes better use of language features IMO. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/