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

Groups > comp.lang.java.programmer > #24716 > unrolled thread

Interface with implied Constructor

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 1 of 4  [1] 2 3 4  Next page →

#24716 — Interface with implied Constructor

Hi,

I have an interface that requires an implementer to cut code that 99% 
sure is going to need some variables that are built at run-time. The 
class to be developed will also be loaded at run-time via Reflection.

Most people I have consulted recommend going the null Constructor in 
combination with Setters, or an INIT() method, to communicate the 
ambient variables to the loaded class. I, on the other hand, would like 
to go the Constructor-Injection-esque root of attempting to invoke a 
version of the Contstructor with the arguments I specify. (Maybe 
failover to null constructor on InvocationException) Is there something 
intrinsically wrong with doing this in Java? (I know there are Abstract 
Classes but I have only Abstract Methods.)

If you like to know the real example then what I'd like to pass to the 
Constructor is the ParentFrame and an Application name. 
London-to-a-brick the callee will create a Dialog Box.

Cheers Richard Maher

[toc] | [next] | [standalone]

#24717

On Tuesday, July 9, 2013 12:41:28 PM UTC+2, Richard Maher wrote:

> I have an interface that requires an implementer to cut code that 99% 
> sure is going to need some variables that are built at run-time. The 
> class to be developed will also be loaded at run-time via Reflection.
> 
> Most people I have consulted recommend going the null Constructor in 
> combination with Setters, or an INIT() method, to communicate the 
> ambient variables to the loaded class.

That's what I'd do as well: make that method part of your interface and be done.

> I, on the other hand, would like 
> to go the Constructor-Injection-esque root of attempting to invoke a 
> version of the Contstructor with the arguments I specify.

Why do you want to do that?

> (Maybe 
> failover to null constructor on InvocationException) Is there something 
> intrinsically wrong with doing this in Java? (I know there are Abstract 
> Classes but I have only Abstract Methods.)

I think it could be that you are making things overly complicated.

> If you like to know the real example then what I'd like to pass to the 
> Constructor is the ParentFrame and an Application name. 
> London-to-a-brick the callee will create a Dialog Box.

An alternative approach would be to not configure the class and instantiate that via reflection but to use factory pattern: define another interface with a create method which receives all the necessary arguments and returns the interface you have already, load that class via reflection with default constructor and let it create instances as needed.

Cheers

robert

[toc] | [prev] | [next] | [standalone]

#24718

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?

So let me ask you "Why do you want to use setters or an init() method?"

Cheers Richard Maher

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#24731

In article <kri3sj$lnl$1@speranza.aioe.org>,
 Richard Maher <maher_rjSPAMLESS@hotmail.com> 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?
> 
> So let me ask you "Why do you want to use setters or an init() method?"
> 
> Cheers Richard Maher

There's a builder pattern than works.  It's a little ugly but it's what 
you have when you can't use abstract classes for some reason.  Move 
around the interfaces as you see fit.


MyThingBuilder.java:

public interface MyThingBuilder
{
   interface MyThing
   {
      String doThing ();
   }
   MyThing build(int arg1, String arg2);   
}



MyThingBuilderImpl.java

public class MyThingBuilderImpl implements MyThingBuilder
{
   @Override
   public MyThing build(int arg1, String arg2)
   {
      return new MyThingImpl(arg1, arg2);
   }

   private static class MyThingImpl implements MyThingBuilder.MyThing
   {
      private final int arg1;
      private final String arg2;
      
      MyThingImpl (int arg1, String arg2)
      {
         this.arg1= arg1;
         this.arg2= arg2;
      }

      @Override
      public String doThing()
      {
         return "MyThingImpl(" + arg1 + ", " + arg2 +')';
      }
   }
}


Main code:
   
   public static void main (String args[]) throws Exception
   {
      //From factory Class
      final Class<? extends MyThingBuilder> c= MyThingBuilderImpl.class;
      System.out.println(c.newInstance().build(1, "two").doThing());
      
      //From Factory instance
      final MyThingBuilder thing= new MyThingBuilderImpl();
      System.out.println(thing.build(2, "three").doThing());
   }
-- 
I will not see posts from Google because I must filter them as spam

[toc] | [prev] | [next] | [standalone]

#24734

On 12.07.2013 04:11, Kevin McMurtrie wrote:

> There's a builder pattern than works.  It's a little ugly but it's what
> you have when you can't use abstract classes for some reason.  Move
> around the interfaces as you see fit.

<snip/>

I'd call that "factory pattern".  Why did you pick "builder"?

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24739

In article <b4fvsjF33d6U1@mid.individual.net>,
 Robert Klemme <shortcutter@googlemail.com> wrote:

> On 12.07.2013 04:11, Kevin McMurtrie wrote:
> 
> > There's a builder pattern than works.  It's a little ugly but it's what
> > you have when you can't use abstract classes for some reason.  Move
> > around the interfaces as you see fit.
> 
> <snip/>
> 
> I'd call that "factory pattern".  Why did you pick "builder"?
> 
> Kind regards
> 
> 	robert

They're similar.  I've seen the term "builder" used more often when the 
construction is done by the implementor and "factory" more often when 
the construction is performed by a single system.  Builder also has a 
pattern of SomeThing a= new 
Builder().with(Options.B).add(x).add(y).addAll(Z).makeImmutable();  It's 
a way to specify arguments after construction without allowing access to 
a partially built object.
-- 
I will not see posts from Google because I must filter them as spam

[toc] | [prev] | [next] | [standalone]

#24740

On 7/15/13 8:58 AM, Kevin McMurtrie wrote:
> In article <b4fvsjF33d6U1@mid.individual.net>,
>   Robert Klemme <shortcutter@googlemail.com> wrote:
>
>> On 12.07.2013 04:11, Kevin McMurtrie wrote:
>>
>>> There's a builder pattern than works.  It's a little ugly but it's what
>>> you have when you can't use abstract classes for some reason.  Move
>>> around the interfaces as you see fit.
>>
>> <snip/>
>>
>> I'd call that "factory pattern".  Why did you pick "builder"?
>>
>> Kind regards
>>
>> 	robert
>
> They're similar.  I've seen the term "builder" used more often when the
> construction is done by the implementor and "factory" more often when
> the construction is performed by a single system.  Builder also has a
> pattern of SomeThing a= new
> Builder().with(Options.B).add(x).add(y).addAll(Z).makeImmutable();  It's
> a way to specify arguments after construction without allowing access to
> a partially built object.
>
I would say the difference is that a builder is a type of factory which 
can be configured before the factory method is invoked.

[toc] | [prev] | [next] | [standalone]

#24741 — [OT] Re: Interface with implied Constructor

On 7/15/2013 1:57 PM, Daniel Pitts wrote:
> On 7/15/13 8:58 AM, Kevin McMurtrie wrote:
>> In article <b4fvsjF33d6U1@mid.individual.net>,
>>   Robert Klemme <shortcutter@googlemail.com> wrote:
>>  [...]
>>> I'd call that "factory pattern".  Why did you pick "builder"?
>>
>> They're similar.  I've seen the term "builder" used more often when the
>> construction is done by the implementor and "factory" more often when
>> the construction is performed by a single system.  Builder also has a
>> pattern of SomeThing a= new
>> Builder().with(Options.B).add(x).add(y).addAll(Z).makeImmutable();  It's
>> a way to specify arguments after construction without allowing access to
>> a partially built object.
>>
> I would say the difference is that a builder is a type of factory which
> can be configured before the factory method is invoked.

     Ah, the old FactoryFactory pattern.  That's the second time
it's been pulled on me this week!

     (Sorry about that, Chief.)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24743 — Re: [OT] Re: Interface with implied Constructor

On 7/15/13 11:13 AM, Eric Sosman wrote:
> On 7/15/2013 1:57 PM, Daniel Pitts wrote:
>> On 7/15/13 8:58 AM, Kevin McMurtrie wrote:
>>> In article <b4fvsjF33d6U1@mid.individual.net>,
>>>   Robert Klemme <shortcutter@googlemail.com> wrote:
>>>  [...]
>>>> I'd call that "factory pattern".  Why did you pick "builder"?
>>>
>>> They're similar.  I've seen the term "builder" used more often when the
>>> construction is done by the implementor and "factory" more often when
>>> the construction is performed by a single system.  Builder also has a
>>> pattern of SomeThing a= new
>>> Builder().with(Options.B).add(x).add(y).addAll(Z).makeImmutable();  It's
>>> a way to specify arguments after construction without allowing access to
>>> a partially built object.
>>>
>> I would say the difference is that a builder is a type of factory which
>> can be configured before the factory method is invoked.
>
>      Ah, the old FactoryFactory pattern.  That's the second time
> it's been pulled on me this week!
>
>      (Sorry about that, Chief.)
>
No, it isn't a Factory Factory.

A builder is a single factory. That factory can be configured before it 
is invoked to produce its output.

A factory builder or a factory factory is a different concept. It is 
possibly, but not necessarily, an antipattern indicating that you've 
abstracted too far.

[toc] | [prev] | [next] | [standalone]

#24742

On 15.07.2013 17:58, Kevin McMurtrie wrote:
> In article <b4fvsjF33d6U1@mid.individual.net>,
>   Robert Klemme <shortcutter@googlemail.com> wrote:
>
>> On 12.07.2013 04:11, Kevin McMurtrie wrote:
>>
>>> There's a builder pattern than works.  It's a little ugly but it's what
>>> you have when you can't use abstract classes for some reason.  Move
>>> around the interfaces as you see fit.
>>
>> <snip/>
>>
>> I'd call that "factory pattern".  Why did you pick "builder"?

> They're similar.  I've seen the term "builder" used more often when the
> construction is done by the implementor and "factory" more often when
> the construction is performed by a single system.  Builder also has a
> pattern of SomeThing a= new
> Builder().with(Options.B).add(x).add(y).addAll(Z).makeImmutable();  It's
> a way to specify arguments after construction without allowing access to
> a partially built object.

But you do not use that feature of chaining in your sample code.  To me 
that's a plain factory.  If you had taken advantage of Builder you would 
have had an interface like this, I believe:

interface MyThing {
   ...
}

public interface MyThingBuilder {
   MyThingBuilder addArg1(int arg1);
   MyThingBuilder addArg2(int arg1);
   MyThing finish();
}

The consistency checking ("Do we have all the arguments?") is put into 
the MyThingBuilder implementation and the client can rely on the 
returned MyThing to be complete so not all methods of MyThing have to 
check state (a concern that has been voiced).

It's a bit like Command pattern applied to object construction: the 
command object's configuration methods (addArg1 and addArg2 above) 
replace constructor arguments and the construction is eventually done by 
a no argument method.

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24735

On 10.07.2013 00:46, 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?"

Using a constructor to initialize an object does not make it necessary 
to do that via reflection.  You can have the same functionality simpler 
with a factory.

> 3) If using setters, how do you enforce that they are called in the
> correct order?

Either throw IllegalStateException or use a single method for 
initialization right away.

> 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?

Hammers are useful tools - but I usually don't use them to fix a screw.

> 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.

Cheers

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24756

On 07/14/2013 01:03 PM, Robert Klemme wrote:
> On 10.07.2013 00:46, 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?"
>
> Using a constructor to initialize an object does not make it necessary
> to do that via reflection.  You can have the same functionality simpler
> with a factory.
>
>> 3) If using setters, how do you enforce that they are called in the
>> correct order?
>
> Either throw IllegalStateException or use a single method for
> initialization right away.
>
>> 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?
>
> Hammers are useful tools - but I usually don't use them to fix a screw.
>
>> 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.
>
> Cheers
>
>      robert
>
>
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.

I seriously dislike init() methods, not just in Java. Particularly if 
there is no sensible un-init()'ed object for the class. I just don't see 
any credible argument for them. Like Richard said, actually: "half-baked".

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?

No problem with factory methods, except they are for specific 
situations. And I think they also lean more towards implementation.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24761

On Thu, 18 Jul 2013 23:21:35 -0300, Arved Sandstrom
<asandstrom2@eastlink.ca> wrote:

[snip]

>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.

     But there is more to it than that.  There is also getting it
initialised.  That should also be part of the API.  I would not
enforce that it has to, but I sure would like the option to specify
constructor signatures in an interface.

>I seriously dislike init() methods, not just in Java. Particularly if 
>there is no sensible un-init()'ed object for the class. I just don't see 
>any credible argument for them. Like Richard said, actually: "half-baked".
>
>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 

     A method is an implementation thing, too, but we have interface
specifications for them.

>business of an interface to dictate how an implementation will 
>initialize objects that can support the interface contract. After all, 

      That is exactly what it is for.  How the implementation works is
not the business of the interface, but how to call it is.

>how can an interface even possibly imagine what the internal state of an 
>initialized object, hence what ctor args are required, is?

     Internal state is implementation and so is not in an interface's
scope.  How to call it is.

>No problem with factory methods, except they are for specific 
>situations. And I think they also lean more towards implementation.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#24762

On 07/19/2013 04:38 PM, Gene Wirchenko wrote:
> On Thu, 18 Jul 2013 23:21:35 -0300, Arved Sandstrom
> <asandstrom2@eastlink.ca> wrote:
>
> [snip]
>
>> 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.
>
>       But there is more to it than that.  There is also getting it
> initialised.  That should also be part of the API.  I would not
> enforce that it has to, but I sure would like the option to specify
> constructor signatures in an interface.

Apart from other problems with constructors in interfaces (e.g. a class 
implements 2 interfaces, both of which have constructors: which ctor do 
you ignore and hence violate a contract?), what do you intend to mandate 
by requiring a constructor with a given signature? That all implementing 
classes create matching private fields that are exposed by accessors? 
Why would you want to do that?

Although it's usually an anti-pattern, I believe a better idea would be 
to specify some important getters in an interface, if you need something 
like this. Rather than wanting to control how an object initializes 
itself and is implemented, typically what you're really after is to 
require that an object can provide some synthetic state information.

>> I seriously dislike init() methods, not just in Java. Particularly if
>> there is no sensible un-init()'ed object for the class. I just don't see
>> any credible argument for them. Like Richard said, actually: "half-baked".
>>
>> 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
>
>       A method is an implementation thing, too, but we have interface
> specifications for them.

The *body* of a method is implementation. Interface or no interface, the 
method as called, the way it represents to callers, is behaviour.

I've seen people in threads make your argument. To call everything 
behaviour is not helpful. A constructor builds an object. I don't 
consider that behaviour.

>> business of an interface to dictate how an implementation will
>> initialize objects that can support the interface contract. After all,
>
>        That is exactly what it is for.  How the implementation works is
> not the business of the interface, but how to call it is.

I don't consider a constructor a "call". Invoking a method on a properly 
initialized method, yes; *building* the object, no.

>> how can an interface even possibly imagine what the internal state of an
>> initialized object, hence what ctor args are required, is?
>
>       Internal state is implementation and so is not in an interface's
> scope.  How to call it is.
>
>> No problem with factory methods, except they are for specific
>> situations. And I think they also lean more towards implementation.
>
> Sincerely,
>
> Gene Wirchenko
>
AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24802

On Fri, 19 Jul 2013 17:56:19 -0300, Arved Sandstrom
<asandstrom2@eastlink.ca> wrote:

>On 07/19/2013 04:38 PM, Gene Wirchenko wrote:
>> On Thu, 18 Jul 2013 23:21:35 -0300, Arved Sandstrom
>> <asandstrom2@eastlink.ca> wrote:
>>
>> [snip]
>>
>>> 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.
>>
>>       But there is more to it than that.  There is also getting it
>> initialised.  That should also be part of the API.  I would not
>> enforce that it has to, but I sure would like the option to specify
>> constructor signatures in an interface.
>
>Apart from other problems with constructors in interfaces (e.g. a class 
>implements 2 interfaces, both of which have constructors: which ctor do 
>you ignore and hence violate a contract?), what do you intend to mandate 
>by requiring a constructor with a given signature? That all implementing 
>classes create matching private fields that are exposed by accessors? 
>Why would you want to do that?

     In that case, I would not have the constructor signature in the
interface.

     What if I am not subclassing?  Having the interface is then
documentation of the full API for the class.

>Although it's usually an anti-pattern, I believe a better idea would be 
>to specify some important getters in an interface, if you need something 
>like this. Rather than wanting to control how an object initializes 
>itself and is implemented, typically what you're really after is to 
>require that an object can provide some synthetic state information.

     Why?  I do not need any getters.  I just want a  prototype of the
constructor with the rest of the prototypes.

>>> I seriously dislike init() methods, not just in Java. Particularly if
>>> there is no sensible un-init()'ed object for the class. I just don't see
>>> any credible argument for them. Like Richard said, actually: "half-baked".
>>>
>>> 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
>>
>>       A method is an implementation thing, too, but we have interface
>> specifications for them.
>
>The *body* of a method is implementation. Interface or no interface, the 
>method as called, the way it represents to callers, is behaviour.
>
>I've seen people in threads make your argument. To call everything 
>behaviour is not helpful. A constructor builds an object. I don't 
>consider that behaviour.

     What else could it be but behaviour?  This definition for
behaviour is from dictionary.reference.com: "the action, reaction, or
functioning of a system, under normal or specified circumstances".
What is the behaviour of a constructor?  It builds an object of type
_____.  Redefining the word to suit your biases simply creates
confusion.

>>> business of an interface to dictate how an implementation will
>>> initialize objects that can support the interface contract. After all,
>>
>>        That is exactly what it is for.  How the implementation works is
>> not the business of the interface, but how to call it is.
>
>I don't consider a constructor a "call". Invoking a method on a properly 
>initialized method, yes; *building* the object, no.

     It is called, implicitly, but called nonetheless.  Once again,
you are trying to redefine a commonly-used term to your biases.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#24803

On 7/22/2013 3:39 PM, Gene Wirchenko wrote:
>[...] I just want a  prototype of the
> constructor with the rest of the prototypes.

     I don't think anyone's in doubt about what you and Richard
want.  The question that still burns is:

                               "Why?"

     Perhaps if you'd offer a concrete example...?  To avoid charges
of made-up-ness, take an existing interface that you think would be
more useful if it could specify constructors, and exhibit the
constructors you'd like it to specify.  Please use an interface
that's not some creature of your own; if the idea is useful, there
surely must be some java or javax interfaces that could use it.
(If there aren't, that casts some doubt on the utility of the
construct ...)

     Then, maybe, we can get away from this childish "It's behavior!"
"No, it's implementation!" back-and-forth.  A use case, please.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24804

On 07/22/2013 05:02 PM, Eric Sosman wrote:
> On 7/22/2013 3:39 PM, Gene Wirchenko wrote:
>> [...] I just want a  prototype of the
>> constructor with the rest of the prototypes.
>
>      I don't think anyone's in doubt about what you and Richard
> want.  The question that still burns is:
>
>                                "Why?"
>
>      Perhaps if you'd offer a concrete example...?  To avoid charges
> of made-up-ness, take an existing interface that you think would be
> more useful if it could specify constructors, and exhibit the
> constructors you'd like it to specify.  Please use an interface
> that's not some creature of your own; if the idea is useful, there
> surely must be some java or javax interfaces that could use it.
> (If there aren't, that casts some doubt on the utility of the
> construct ...)
>
>      Then, maybe, we can get away from this childish "It's behavior!"
> "No, it's implementation!" back-and-forth.  A use case, please.
>
I agree with you in wanting to see an example that we can discuss.

Not so sure the "back-and-forth" is totally childish, although it's 
close to being exhausted. I think it comes down to how one defines 
object behaviour.

One prevalent definition is that object behaviour is defined by all the 
methods that can be applied to it, so including accessors even. I would 
not myself include constructors under this definition, even though they 
resemble instance methods, because you only have a valid instance when 
you leave the constructor.

And yet there are different types of object behaviour. I generally 
distinguish between methods that could sensibly be in an interface, and 
those that smack a bit too much of implementation. First category might be

translate2D(Double direction, Double distance)

and second might be

set2DPositionXY(Double x, Double y)

Granted, this is fuzzy, but I think there's some validity to the "would 
this method ring true in an interface" test.

AHS
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24808

On Mon, 22 Jul 2013 16:02:05 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

>On 7/22/2013 3:39 PM, Gene Wirchenko wrote:
>>[...] I just want a  prototype of the
>> constructor with the rest of the prototypes.
>
>     I don't think anyone's in doubt about what you and Richard
>want.  The question that still burns is:
>
>                               "Why?"

     An interface documents.  I can put additional comments in there
and do because it helps the signatures make sense.  Since I have all
this, why not have the constructors there, too?  Then, I have the API
documented in one place.

>     Perhaps if you'd offer a concrete example...?  To avoid charges

     Read my pargraph above.

>of made-up-ness, take an existing interface that you think would be
>more useful if it could specify constructors, and exhibit the
>constructors you'd like it to specify.  Please use an interface
>that's not some creature of your own; if the idea is useful, there
>surely must be some java or javax interfaces that could use it.
>(If there aren't, that casts some doubt on the utility of the
>construct ...)

     It would document the class in one place.

     I have already done this.  I added comments to my interfaces
stating what the constructor signatures were.  I would like to have
Java enforce constructor signatures.  Note that I am fine with this
being optional so you need not worry about it.

>     Then, maybe, we can get away from this childish "It's behavior!"
>"No, it's implementation!" back-and-forth.  A use case, please.

     For me, it is such a general situation that a use case is gilding
the lily.  If you were to ask me for a use case for using a for
statement, it would be about the same level.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#24810

In article <l6ttu85sjbmh4tm5l9utc2k1uk82r9gqhb@4ax.com>, Gene Wirchenko
<genew@telus.net> wrote:

> On Mon, 22 Jul 2013 16:02:05 -0400, Eric Sosman
> <esosman@comcast-dot-net.invalid> wrote:
> 
> >On 7/22/2013 3:39 PM, Gene Wirchenko wrote:
> >>[...] I just want a  prototype of the
> >> constructor with the rest of the prototypes.
> >
> >     I don't think anyone's in doubt about what you and Richard
> >want.  The question that still burns is:
> >
> >                               "Why?"
> 
>      An interface documents.  I can put additional comments in there
> and do because it helps the signatures make sense.  Since I have all
> this, why not have the constructors there, too?  Then, I have the API
> documented in one place.

An interface only documents (requires or specifies, actually) /part/ of
class behavior. There are usually other aspects of the class that must
be addressed by its constructors. Those aspects are outside the scope
of the interface.

Classes can implement more than one interface. What should the compiler
demand in the case of multiple, mutually-exclusive constructor
requirements?

-- 
Jim Gibson

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web