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:05:16 GMT
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