commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <christiane...@yahoo.de>
Subject Re: [HiveMind] extend BuildFactory to use static fields/methods
Date Wed, 01 Oct 2003 13:37:08 GMT
Well if you mean the BuilderFactory than I think most people (like me) 
relay just on the properties. That means at least for me that I always end 
up implementing the initilizableObject method just to check if the 
properties where set in the right combiniation (alone the combination check 
in one method is no fun). Using a configuration-point makes it even worse. 
I have to implement an extra class allmost for nothing where I still have 
to check the same - all in one method - as with the properties. (The 
configuration-point also has the problem that not only the 'constructor' 
can specify the properties but anyone can contribute and also anyone can 
define a configuration-point).

If you mean the ConfigurationBilderFactory - proposed by me - I have to 
admit that when I read the static thing I realized how stupid I was. The 
main thing I wanted it for (the constructor thing) can be done with the 
static methods (maybe it's a bit less convinient).

On Wed, 01 Oct 2003 15:05:53 +0200, Johan Lindquist <johan@kawoo.co.uk> 
wrote:

> Wouldn't the configuration passed to the factory will make sure the 
> service is returned in a 'usable' state?  The user doesn't do any 
> configuration at that level?
> And the service interface shouldn't really allow configuration changes 
> or?
>
> And I am all for the pattern to ensure consistency in created objects ... 
> Not sure if it applies here though ...
>
> Johan
>
>
> On Wed, 01 Oct 2003 15:05:16 +0200, Christian Essl 
> <christianessl@yahoo.de> wrote:
>
>> You are right HiveMind always returns the same instance, but I mean 
>> there can be services which have no state or the state of which is just 
>> defined at construction time and for these it makes in my opinion sense 
>> to declare them as (default-variant) static fields. Further for those 
>> Services the static field gives a level of indirection.
>>
>> But certainly the more intresting idea was the one of static-factory- 
>> methods. I personally hate nothing more than making a default 
>> constructor for classes which need external data to be ready for usage. 
>> I don't want to construct my classes and than rely on the user that he 
>> might set the needed data sometime . When a class is constructed it 
>> should be in a valid state or otherwise throw an Exception. And as you 
>> know a pattern to ensure that is to use a static-factory-method and a 
>> private (maybe protected) constructor.
>>
>> On Wed, 01 Oct 2003 14:29:49 +0200, Johan Lindquist <johan@kawoo.co.uk> 
>> wrote:
>>
>>> I may have misunderstood this - but doesn't hivemind always return the 
>>> same instance when you ask for a service once it has created one 
>>> (unless it is a threaded service model, when you are worried about 
>>> state anyway and probably want different instances)?  If so, what is 
>>> the need to have a static instance?  I suppose I can see a use for it 
>>> to share data between threads, but the singleton service should 
>>> suffice?
>>>
>>> Johan
>>>
>>> On Wed, 01 Oct 2003 13:52:58 +0200, Christian Essl 
>>> <christianessl@yahoo.de> wrote:
>>>
>>>> That's very good (and fast implemented). But do you realy have to do 
>>>> the double-check on the class. I mean the user sees anyway what class 
>>>> it is from the JavaDoc and HiveMind will always check that it fits the 
>>>> Service interface.
>>>>
>>>> Sure if the static field changes this ensures consistency, but on the 
>>>> other hand it would be also very convient to change all services 
>>>> referenced but just changing the static field without the need to go 
>>>> into the module.
>>>>
>>>>
>>>> On Wed, 1 Oct 2003 12:40:12 +0200, Knut Wannheden 
>>>> <knut.wannheden@paranor.ch> wrote:
>>>>
>>>>> I have created a copy of the hivemind.BuilderFactory service which 
>>>>> allows me
>>>>> to write:
>>>>>
>>>>> <invoke-factory service-id="my.BuilderFactory">
>>>>> <construct class="foo.Bar" static-field="foo.Bar.INSTANCE"/>
>>>>> </invoke-factory>
>>>>>
>>>>> given that I have something like:
>>>>>
>>>>> package foo;
>>>>> public interface Bar {
>>>>> static final INSTANCE = new BarImpl();
>>>>> }
>>>>>
>>>>> The class attribute is used to check that the object specified by the
>>>>> static-field is of a given type, which is an interface in this 
>>>>> example.
>>>>>
>>>>> --knut
>>>>>
>>>>>> That's certainly a good idea.
>>>>>>
>>>>>> On Wed, 1 Oct 2003 07:50:42 +0200, Knut Wannheden
>>>>>> <knut.wannheden@paranor.ch> wrote:
>>>>>>
>>>>>> > Hi,
>>>>>> >
>>>>>> > I was wondering whether it would make sense to extend the 
>>>>>> BuildFactory
>>>>>> > service (or maybe add a new wervice) to also be able to construct
>>>>> objects
>>>>>> > by
>>>>>> > returning the value of a classes static field or by calling
a 
>>>>>> static
>>>>>> > method
>>>>>> > on a class. The former would obviously be simpler. E.g. (as
a new
>>>>>> > service):
>>>>>> >
>>>>>> > <invoke-factory service-id="hivemind.StaticBuilderFactory">
>>>>>> > <construct class="foo.Bar" static-field="BAZ">
>>>>>> > <set.../>
>>>>>> > </construct>
>>>>>> > </invoke-factory>
>>>>>> >
>>>>>> > --knut
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > -------------------------------------------------------------------

>>>>>>
>>>>>>
>>>>>> --
>>>>>> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>> > For additional commands, e-mail: commons-dev- 
>>>>>> help@jakarta.apache.org
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- Using M2, Opera's revolutionary e-mail client: 
>>>>>> http://www.opera.com/m2/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message