Calling setSettings() vs constructor argument

[simonebordet]

Hi,

I was thinking about having Settings as a constructor argument vs
having an explicit setter that is called immediately after the
constructor.

Having the Settings as constructor parameter:
Pro:
1. One-step configuration: all is needed is passed to the ctor (though
now there are ctors without Settings).
2. Cannot forget to pass it to superclass.
Cons:
1. Suffers of the "overridable method called from ctor" problem.

Having the Setting as parameter to a public setter method
Pro:
1. Removes the "overridable method called from ctor" problem.
Cons:
1. Must remeber to call super.setSettings() in subclasses.
2. Slightly longer configuration steps

I am bouncing back and forth between the two, though right now I am
slightly leaning to have the setter solution, just to remove the
"overridable method called from ctor" problem.

Thoughts ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Alan.Cabrera]

On Jul 28, 2008, at 8:57 AM, Simone Bordet wrote:

> Hi,
>
> I was thinking about having Settings as a constructor argument vs
> having an explicit setter that is called immediately after the
> constructor.
>
> Having the Settings as constructor parameter:
> Pro:
> 1. One-step configuration: all is needed is passed to the ctor (though
> now there are ctors without Settings).
> 2. Cannot forget to pass it to superclass.
> Cons:
> 1. Suffers of the "overridable method called from ctor" problem.

I might be missing something but I don't know how it can suffer form  
this problem.  Can you provide a teeny example?

Regards,
Alan


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[simonebordet]

Hi,

On Mon, Jul 28, 2008 at 8:17 PM, Alan Cabrera <adc@...> wrote:
> I might be missing something but I don't know how it can suffer form this
> problem.  Can you provide a teeny example?

Currently the constructor calls setSetting() which is private, which
calls e.g. setPort() which is public and overridable.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Alan.Cabrera]

On Jul 28, 2008, at 11:50 AM, Simone Bordet wrote:

> Hi,
>
> On Mon, Jul 28, 2008 at 8:17 PM, Alan Cabrera <adc@...>  
> wrote:
>> I might be missing something but I don't know how it can suffer  
>> form this
>> problem.  Can you provide a teeny example?
>
> Currently the constructor calls setSetting() which is private, which
> calls e.g. setPort() which is public and overridable.

Why not just set the port directly?


Regards,
Alan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[simonebordet]

Hi,

On Mon, Jul 28, 2008 at 8:54 PM, Alan Cabrera <adc@...> wrote:
> Why not just set the port directly?

We've been over this already, and you know it won't work.

I'll figure out something.

Thanks,

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Alan.Cabrera]

On Jul 28, 2008, at 11:56 AM, Simone Bordet wrote:

> Hi,
>
> On Mon, Jul 28, 2008 at 8:54 PM, Alan Cabrera <adc@...>  
> wrote:
>> Why not just set the port directly?
>
> We've been over this already, and you know it won't work.
>
> I'll figure out something.

I don't think so.

We talked about this?

     private void setSettings(Settings settings)
     {
         if (settings.containsKey(Keys.PORT_KEY)) this.port =  
settings.get(Keys.PORT_KEY);
     }


Regards,
Alan


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[simonebordet]

Hi,

On Mon, Jul 28, 2008 at 8:59 PM, Alan Cabrera <adc@...> wrote:
> We talked about this?
>
>    private void setSettings(Settings settings)
>    {
>        if (settings.containsKey(Keys.PORT_KEY)) this.port =
> settings.get(Keys.PORT_KEY);
>    }

Ok so what is your opinion ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Alan.Cabrera]

On Jul 28, 2008, at 12:18 PM, Simone Bordet wrote:

> Hi,
>
> On Mon, Jul 28, 2008 at 8:59 PM, Alan Cabrera <adc@...>  
> wrote:
>> We talked about this?
>>
>>   private void setSettings(Settings settings)
>>   {
>>       if (settings.containsKey(Keys.PORT_KEY)) this.port =
>> settings.get(Keys.PORT_KEY);
>>   }
>
> Ok so what is your opinion ?

If you assign your settings in this manner, then you have removed the  
"overridable method called from ctor" problem.  You can then keep the  
settings in the constructor paradigm.


Regards,
Alan


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[simonebordet]

Hi,

On Mon, Jul 28, 2008 at 9:37 PM, Alan Cabrera <adc@...> wrote:

>
> On Jul 28, 2008, at 12:18 PM, Simone Bordet wrote:
>
>> Hi,
>>
>> On Mon, Jul 28, 2008 at 8:59 PM, Alan Cabrera <adc@...> wrote:
>>>
>>> We talked about this?
>>>
>>>  private void setSettings(Settings settings)
>>>  {
>>>      if (settings.containsKey(Keys.PORT_KEY)) this.port =
>>> settings.get(Keys.PORT_KEY);
>>>  }
>>
>> Ok so what is your opinion ?
>
>
> If you assign your settings in this manner, then you have removed the
> "overridable method called from ctor" problem.  You can then keep the
> settings in the constructor paradigm.

Yes. Why do you like more using fields than setters, exactly ?

Would not using fields somehow limit who wants to subclass ?
Because there will be no opportunities to hook in when the port is
set, since that will be done directly on the field instead of using a
setter method.

I'd like to keep the setters to allow ultra-specialized configuration,
for example I need this for testing.

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Alan.Cabrera]

On Jul 28, 2008, at 12:52 PM, Simone Bordet wrote:

> Hi,
>
> On Mon, Jul 28, 2008 at 9:37 PM, Alan Cabrera <adc@...>  
> wrote:
>>
>> On Jul 28, 2008, at 12:18 PM, Simone Bordet wrote:
>>
>>> Hi,
>>>
>>> On Mon, Jul 28, 2008 at 8:59 PM, Alan Cabrera  
>>> <adc@...> wrote:
>>>>
>>>> We talked about this?
>>>>
>>>> private void setSettings(Settings settings)
>>>> {
>>>>     if (settings.containsKey(Keys.PORT_KEY)) this.port =
>>>> settings.get(Keys.PORT_KEY);
>>>> }
>>>
>>> Ok so what is your opinion ?
>>
>>
>> If you assign your settings in this manner, then you have removed the
>> "overridable method called from ctor" problem.  You can then keep the
>> settings in the constructor paradigm.
>
> Yes. Why do you like more using fields than setters, exactly ?

I like setters. This is just a way to fix the above problem.

> Would not using fields somehow limit who wants to subclass ?
> Because there will be no opportunities to hook in when the port is
> set, since that will be done directly on the field instead of using a
> setter method.

Keep the setters the way they are. Only directly set the fields during  
construction.  At that point, you can always check what happened  
latter in the child's constructior.


Regards,
Alan


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[simonebordet]

Hi,

On Mon, Jul 28, 2008 at 10:21 PM, Alan Cabrera <adc@...> wrote:
> Keep the setters the way they are. Only directly set the fields during
> construction.  At that point, you can always check what happened latter in
> the child's constructior.

How ? (I have an idea, but would like to hear yours)

Thanks,

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Alan.Cabrera]

On Jul 28, 2008, at 2:02 PM, Simone Bordet wrote:

> Hi,
>
> On Mon, Jul 28, 2008 at 10:21 PM, Alan Cabrera <adc@...>  
> wrote:
>> Keep the setters the way they are. Only directly set the fields  
>> during
>> construction.  At that point, you can always check what happened  
>> latter in
>> the child's constructior.
>
> How ? (I have an idea, but would like to hear yours)

     public StandardUserAgentClient(UDPConnector tcpConnector,  
TCPConnector udpConnector, Settings settings)
     {
         super(tcpConnector, udpConnector, settings);

         int port = getPort();
         // do some port checking
     }


Regards,
Alan



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email