Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #24778

Re: Interface with implied Constructor

From Robert Klemme <shortcutter@googlemail.com>
Newsgroups comp.lang.java.programmer
Subject Re: Interface with implied Constructor
Date 2013-07-20 20:21 +0200
Message-ID <b502peFh8n0U1@mid.individual.net> (permalink)
References (1 earlier) <925adeb1-65b5-4a50-86a8-4f04784f8da0@googlegroups.com> <kri3sj$lnl$1@speranza.aioe.org> <b4g0e8F35pjU1@mid.individual.net> <Qo1Gt.8876$2C2.1824@fx04.iad> <b50229Fh2tcU1@mid.individual.net>

Show all headers | View raw


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/

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-09 18:41 +0800
  Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-09 04:08 -0700
    Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-10 06:46 +0800
      Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-09 21:08 -0400
      Re: Interface with implied Constructor Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-11 19:11 -0700
        Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-14 17:53 +0200
          Re: Interface with implied Constructor Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-15 08:58 -0700
            Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-15 10:57 -0700
              [OT] Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-15 14:13 -0400
                Re: [OT] Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-15 12:58 -0700
            Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-15 20:45 +0200
      Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-14 18:03 +0200
        Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-18 23:21 -0300
          Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-19 12:38 -0700
            Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-19 17:56 -0300
              Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-22 12:39 -0700
                Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-22 16:02 -0400
                Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-22 18:08 -0300
                Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-23 14:32 -0700
                Re: Interface with implied Constructor Jim Gibson <jimsgibson@gmail.com> - 2013-07-23 14:43 -0700
                Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-24 13:27 -0700
                Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-24 18:20 -0300
                Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-26 00:03 +0200
                Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-24 21:18 +0000
                Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-24 17:42 -0400
                Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-23 18:19 -0400
                Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-24 13:31 -0700
                Re: Interface with implied Constructor Steven Simpson <ss@domain.invalid> - 2013-07-27 04:06 +0100
            Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-19 21:21 +0000
              Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-19 18:56 -0300
                Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-19 18:10 -0400
                Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-19 20:46 -0300
                Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-20 12:42 +0800
                Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-20 09:08 -0300
                Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-20 09:08 -0400
              Re: Interface with implied Constructor Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-19 19:20 -0700
                Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-19 20:11 -0700
                Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-20 12:26 +0800
                Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-20 09:38 -0300
              Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-20 19:46 +0200
                Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-20 19:12 +0000
                Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-20 17:12 -0400
                Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-20 21:18 +0000
                Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-21 12:13 +0200
                Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-21 16:18 -0300
                Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-21 13:45 -0700
                Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-21 16:58 -0400
                Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-21 21:19 -0300
          Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-20 20:09 +0200
            Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-20 20:21 +0200
            Re: Interface with implied Constructor Joerg Meier <joergmmeier@arcor.de> - 2013-07-20 23:17 +0200
              Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-20 17:32 -0400
                Re: Interface with implied Constructor Joerg Meier <joergmmeier@arcor.de> - 2013-07-21 00:10 +0200
            Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-21 17:53 -0300
  Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-09 18:13 -0700
    Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-10 18:03 +0800
      Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-10 08:41 -0700
        Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-11 06:53 +0800
  Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-09 21:41 -0700
    Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-10 17:55 +0800
    Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-10 14:52 -0700
  Re: Interface with implied Constructor Roedy Green <see_website@mindprod.com.invalid> - 2013-07-10 16:02 -0700

csiph-web