commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Lindquist <jo...@kawoo.co.uk>
Subject Re: [HiveMind] extend BuildFactory to use static fields/methods
Date Wed, 01 Oct 2003 14:02:31 GMT
Ok, I may have not tested this fully ... [Note to self: must make time to 
test more configuration options]  But if the service specified in the 
builder factory setting and a valid service doesn't exists for that 
particular setter, won't the builder factory complain?

Johan

On Wed, 01 Oct 2003 15:37:08 +0200, Christian Essl 
<christianessl@yahoo.de> wrote:

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



-- 
you too?

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