Path: csiph.com!usenet.pasdenom.info!aioe.org!news.swapon.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:09:00 +0200 Lines: 65 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 V7B7Ok3qsUalXiPhfjOHzQZtibdLB7vRQDtkvp1cOtJITghjA= Cancel-Lock: sha1:Av89Jk72RqjAbpdRuAaqdtk0yU8= 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:24777 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. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/