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 13:05:53 GMT
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