hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Wannheden <>
Subject Re: Design Question : Symbol Sources et Interception vs POA
Date Fri, 20 May 2005 13:13:33 GMT

On 5/20/05, belaran <> wrote:
> Hi everyone !
> First of all i want to apologize for the rather long post...
> I'm working on HiveMind and i try to figure out the possibilities of
> the framework. I've been playing with most of its features and i get
> the point for most of them. However, i've two question :
> 1) When HiveMind call your SymbolSource it's just call the method
> 'valueForSymbol(String symbol)' then the user has to code it's own
> implementation to return he actual Symbol value. It's quite simple but
> i find quite limited in someway:
>             a) If you have many symbols ( like dozen), your
> implementation will look like this :
> if ( )
> else if
> else if
> else...
> Of course you can do this differently but this "single point" of
> access, you'll always end up with something like this.

Some symbol sources are actually just "dynamic adapters". Take the
SystemPropertiesSymbolSource implementation for example:

    public String valueForSymbol(String name)
        return System.getProperty(name);

>              b) If i had to "implement" this system i would have done this :
> List valueForSymbol()
> However i'm no architect or a renown designer ! So I believe I miss
> something : May be you can give use case we're this implementation
> comes handy or simply use case that's prove my assumptions false ?

In some cases your list of symbols might not be finite. That would a)
be impractical for the symbol source implementation and b) make it
impossible for HiveMind to find a symbol definition.

Hope this answer makes sense.

> 2) Interception provides somes great functionnality and seems to offer
> a very good subsitiute to AOP. My question is simply what AOP, which I
> don't really know, offers that HiveMind's interception has not...

The HiveMind interceptors aren't really meant to substitute AOP. You
can in fact define HiveMind interceptors in terms of AOP style
interceptors (see hivemind.lib.MethodInterceptorFactory for this). AOP
offers a whole lot more which is not covered by HiveMind. I suggest
you read some AOP articles and see for your self if it would be useful
to you.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message