Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49116AA2.50707@apache.org>
Date: Wed, 05 Nov 2008 10:42:58 +0100
From: Simon Kitching <skitching@apache.org>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [configuration] Interface vs class
References: <49095D30.60005@oliver-heger.de>
 <4909C006.7000306@dslextreme.com>	 <gefo6s$cbp$1@ger.gmane.org>
	 <f2e8eedf0810311323r7571c738t3d95ae7fbb362004@mail.gmail.com>
	 <490C862C.2080000@oliver-heger.de>
 <490CA1AC.1070307@dslextreme.com>	 <F0D7281DAB048B438E8F5EC4ECEFBDDC031F2856@esmail.elsag.de>
	 <4910BDBF.8020302@oliver-heger.de>
	 <F0D7281DAB048B438E8F5EC4ECEFBDDC0337D389@esmail.elsag.de>
	 <49116181.9070409@apache.org>
 <f2e8eedf0811050130n77a61469ib9ca4cb4537c832e@mail.gmail.com>
In-Reply-To: <f2e8eedf0811050130n77a61469ib9ca4cb4537c832e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

James Carman schrieb:
> On Wed, Nov 5, 2008 at 4:04 AM, Simon Kitching <skitching@apache.org> wrote:
>   
>> So the rule would be:
>> * the project provides both an interface and an abstract class that
>> implements that interface.
>> * code that *uses* the API should always use just the interface, ie
>> *call* methods via the interface and pass instances around as the
>> interface type
>> * code that *implements* the API should always subclass the base class.
>>
>> The project reserves the right to add methods to the interface, but will
>> always provide a concrete default implementation on the abstract
>> subclass. Methods will *not* be added to the interface if a sensible
>> default implementation cannot be provided.
>>
>>     
>
> So, perhaps I can change Proxy to use an interface rather than a
> class?  We already have a default implementation based on JDK proxies.
>   
The standard JDK interface-based proxying would certainly become more
useful.

One issue that the above doesn't deal with is applying the decorator
pattern to such interfaces.

If someone wants to decorate an existing implementation by intercepting
one or more methods, then they certainly can do so by using dynamic
proxying (via commons-proxy or similar), as the type is now an interface.

If someone wants to hand-write a decorator class, though, then they are
in trouble as the abstract base class won't help there and the project
reserves the right to extend the interface. I suppose the project could
*also* provide an abstract "delegator" class for each interface that
simply delegates all methods. That's then *two* abstract classes for
each interface though, which is getting a little clumsy. Or we could
simply say "get with the modern world and use a dynamic proxy"...

Regards,
Simon

-- 
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)


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