[configuration] Interface vs class

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[configuration] Interface vs class

Oliver Heger-3
A while ago we discussed whether in Configuration 2.0 the fundamental
Configuration object should be an interface or an (abstract) class, and
- as usual ;-) - we could not agree on a way to go.

Therefore I suggest the following compromise:
We keep an interface - let's call it ConfigurationSource - that is a
stripped down version of the Configuration interface we have now. This
interface contains only basic operations needed for accessing properties
in their "raw" form.

What is now AbstractConfiguration can become a concrete class
"Configuration". This class will be associated with a
ConfigurationSource object and implement more sophisticated operations
on top of it. Here stuff like data conversion, interpolation, or
enhanced query facilities is implemented.

An advantage of this approach is that we have a cleaner separation
between the basic management of configuration properties and high-level
processing of their values. We still have an interface, which has
benefits, e.g. for providing mock implementations or proxies, but
extensions can be implemented in a binary compatible way by modifying
the new Configuration class (and maybe defining sub interfaces of
ConfigurationSource). Because the ConfigurationSource interface has only
a handful of methods, it is easier to implement than the overloaded
Configuration interface of today.

I checked in a first draft version of a ConfigurationSource interface
[1]. Of course we can discuss the methods this interface should have.
For instance, methods like flush() and sync() dealing with persistence
could be added.

WDYT?
Oliver

[1]
http://svn.apache.org/viewvc/commons/proper/configuration/branches/configuration2_experimental/src/main/java/org/apache/commons/configuration2/base/ConfigurationSource.java?view=log

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Michiel Kalkman
I don't know the discussion, so the only thing I can say right now, is
that I don't like the names ... Or I just don't understand why it is
called XXXSource, which in my thoughts refers to the resource the
configuration is read from.

How about Configuration for the interface and something like
BaseConfiguration for the class ?

Regards,
Michiel


On 10/30/08, Oliver Heger <[hidden email]> wrote:

> A while ago we discussed whether in Configuration 2.0 the fundamental
> Configuration object should be an interface or an (abstract) class, and
> - as usual ;-) - we could not agree on a way to go.
>
> Therefore I suggest the following compromise:
> We keep an interface - let's call it ConfigurationSource - that is a
> stripped down version of the Configuration interface we have now. This
> interface contains only basic operations needed for accessing properties in
> their "raw" form.
>
> What is now AbstractConfiguration can become a concrete class
> "Configuration". This class will be associated with a ConfigurationSource
> object and implement more sophisticated operations on top of it. Here stuff
> like data conversion, interpolation, or enhanced query facilities is
> implemented.
>
> An advantage of this approach is that we have a cleaner separation between
> the basic management of configuration properties and high-level processing
> of their values. We still have an interface, which has benefits, e.g. for
> providing mock implementations or proxies, but extensions can be implemented
> in a binary compatible way by modifying the new Configuration class (and
> maybe defining sub interfaces of ConfigurationSource). Because the
> ConfigurationSource interface has only a handful of methods, it is easier to
> implement than the overloaded Configuration interface of today.
>
> I checked in a first draft version of a ConfigurationSource interface [1].
> Of course we can discuss the methods this interface should have. For
> instance, methods like flush() and sync() dealing with persistence could be
> added.
>
> WDYT?
> Oliver
>
> [1]
> http://svn.apache.org/viewvc/commons/proper/configuration/branches/configuration2_experimental/src/main/java/org/apache/commons/configuration2/base/ConfigurationSource.java?view=log
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Ralph Goers
FWIW, I agree. I must have missed the earlier discussion as well.  I
definitely prefer having an interface that can be used whenever a
specific implementation is not required.

Michiel Kalkman wrote:

> I don't know the discussion, so the only thing I can say right now, is
> that I don't like the names ... Or I just don't understand why it is
> called XXXSource, which in my thoughts refers to the resource the
> configuration is read from.
>
> How about Configuration for the interface and something like
> BaseConfiguration for the class ?
>
> Regards,
> Michiel
>
>
> On 10/30/08, Oliver Heger <[hidden email]> wrote:
>  
>> A while ago we discussed whether in Configuration 2.0 the fundamental
>> Configuration object should be an interface or an (abstract) class, and
>> - as usual ;-) - we could not agree on a way to go.
>>
>> Therefore I suggest the following compromise:
>> We keep an interface - let's call it ConfigurationSource - that is a
>> stripped down version of the Configuration interface we have now. This
>> interface contains only basic operations needed for accessing properties in
>> their "raw" form.
>>
>> What is now AbstractConfiguration can become a concrete class
>> "Configuration". This class will be associated with a ConfigurationSource
>> object and implement more sophisticated operations on top of it. Here stuff
>> like data conversion, interpolation, or enhanced query facilities is
>> implemented.
>>
>> An advantage of this approach is that we have a cleaner separation between
>> the basic management of configuration properties and high-level processing
>> of their values. We still have an interface, which has benefits, e.g. for
>> providing mock implementations or proxies, but extensions can be implemented
>> in a binary compatible way by modifying the new Configuration class (and
>> maybe defining sub interfaces of ConfigurationSource). Because the
>> ConfigurationSource interface has only a handful of methods, it is easier to
>> implement than the overloaded Configuration interface of today.
>>
>> I checked in a first draft version of a ConfigurationSource interface [1].
>> Of course we can discuss the methods this interface should have. For
>> instance, methods like flush() and sync() dealing with persistence could be
>> added.
>>
>> WDYT?
>> Oliver
>>
>> [1]
>> http://svn.apache.org/viewvc/commons/proper/configuration/branches/configuration2_experimental/src/main/java/org/apache/commons/configuration2/base/ConfigurationSource.java?view=log
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Jörg Schaible
Hi Ralph,

Ralph Goers wrote:

> FWIW, I agree. I must have missed the earlier discussion as well.  I
> definitely prefer having an interface that can be used whenever a
> specific implementation is not required.

The original arguing was, that an interface will always prevent an
enhancement because of backward compatibility. This is especially true for
the current Configuration code base.

Whenever I get a Configuration object passed, I cast it quite immediately to
an AbstractConfiguration to set the delimiter and throw mode. If
Configuration itself were an abstract class, those methods could have been
added long ago without breaking backward compatibility.

Look through the archives, the discussion with pros and cons went on
promoting commons-proxy.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

James Carman
On Fri, Oct 31, 2008 at 4:01 PM, Jörg Schaible <[hidden email]> wrote:

> Hi Ralph,
>
> Ralph Goers wrote:
>
>> FWIW, I agree. I must have missed the earlier discussion as well.  I
>> definitely prefer having an interface that can be used whenever a
>> specific implementation is not required.
>
> The original arguing was, that an interface will always prevent an
> enhancement because of backward compatibility. This is especially true for
> the current Configuration code base.
>
> Whenever I get a Configuration object passed, I cast it quite immediately to
> an AbstractConfiguration to set the delimiter and throw mode. If
> Configuration itself were an abstract class, those methods could have been
> added long ago without breaking backward compatibility.
>
> Look through the archives, the discussion with pros and cons went on
> promoting commons-proxy.

Yes they did!  I remember it well and I hated using a class rather
than an interface.  However, I can see the merit in the decision when
it comes to maintenance and backward compatibility.  As a "purist", it
just hurt! ;)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Interface vs class

Mario Ivankovits
Hi!

> > Look through the archives, the discussion with pros and cons went on
> > promoting commons-proxy.
>
> Yes they did!  I remember it well and I hated using a class rather
> than an interface.  However, I can see the merit in the decision when
> it comes to maintenance and backward compatibility.  As a "purist", it
> just hurt! ;)

Yep, sooner or later it hurts.

Everytime I cross the bridge having the requirement to create a facade or proxy for a class based on just an abstract class it is a pain in the a*.

Sooner or later you'll find methods with an implementation in there and then you'll face any sort of problem.

JSF is a very good (or bad) example where over the time it gets harder and harder to extend from a grown abstract base class. Java itself has some interesting classes, e.g. Authenticator or SSLSocketFactory. Stuff I had to deal with today.

Having an interface (which is extensible too, just extend an interface from another one) makes this much more cleaner. Any problem after an upgrade (major release upgrade for sure) the compiler will complain. Having abstract basis classes you can avoid this, but your application might fail on runtime later ... or not ... depending what you use from the inherited class.
If you inherit from an interface you can be sure that you fulfill the contract of the library, an abstract class can change without any notice.

For me, the trend to abstract basis classes are a bad thing.

Ciao,
Mario
Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Samuel Le Berrigaud
Hi,

I have not been in the conversations before, but I am also a proponent
of using interfaces. One way to enable extensions for those interfaces
would be to use the capability pattern (similar to what is described
here: http://java.dzone.com/news/the-capability-pattern-future- ).

There could be a ListCapability for example that would have the
setListDelimiter method for which the implementation would set it
directly on the abstract implementation of the configuration object.
No need for an ugly cast, and fairly easy to change the
implementation.

What do you think?

SaM

On Sat, Nov 1, 2008 at 9:04 AM, Mario Ivankovits <[hidden email]> wrote:

> Hi!
>
>> > Look through the archives, the discussion with pros and cons went on
>> > promoting commons-proxy.
>>
>> Yes they did!  I remember it well and I hated using a class rather
>> than an interface.  However, I can see the merit in the decision when
>> it comes to maintenance and backward compatibility.  As a "purist", it
>> just hurt! ;)
>
> Yep, sooner or later it hurts.
>
> Everytime I cross the bridge having the requirement to create a facade or proxy for a class based on just an abstract class it is a pain in the a*.
>
> Sooner or later you'll find methods with an implementation in there and then you'll face any sort of problem.
>
> JSF is a very good (or bad) example where over the time it gets harder and harder to extend from a grown abstract base class. Java itself has some interesting classes, e.g. Authenticator or SSLSocketFactory. Stuff I had to deal with today.
>
> Having an interface (which is extensible too, just extend an interface from another one) makes this much more cleaner. Any problem after an upgrade (major release upgrade for sure) the compiler will complain. Having abstract basis classes you can avoid this, but your application might fail on runtime later ... or not ... depending what you use from the inherited class.
> If you inherit from an interface you can be sure that you fulfill the contract of the library, an abstract class can change without any notice.
>
> For me, the trend to abstract basis classes are a bad thing.
>
> Ciao,
> Mario
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Oliver Heger-3
In reply to this post by James Carman
James Carman schrieb:

> On Fri, Oct 31, 2008 at 4:01 PM, Jörg Schaible <[hidden email]> wrote:
>> Hi Ralph,
>>
>> Ralph Goers wrote:
>>
>>> FWIW, I agree. I must have missed the earlier discussion as well.  I
>>> definitely prefer having an interface that can be used whenever a
>>> specific implementation is not required.
>> The original arguing was, that an interface will always prevent an
>> enhancement because of backward compatibility. This is especially true for
>> the current Configuration code base.
>>
>> Whenever I get a Configuration object passed, I cast it quite immediately to
>> an AbstractConfiguration to set the delimiter and throw mode. If
>> Configuration itself were an abstract class, those methods could have been
>> added long ago without breaking backward compatibility.
>>
>> Look through the archives, the discussion with pros and cons went on
>> promoting commons-proxy.
>
> Yes they did!  I remember it well and I hated using a class rather
> than an interface.  However, I can see the merit in the decision when
> it comes to maintenance and backward compatibility.  As a "purist", it
> just hurt! ;)
>

I found a reference to the original discussion. It came up when we
talked about new features for Configuration 2.0:

http://www.nabble.com/-configuration--What-changes-in-Commons-Configuration-2.0---td15530059.html

As you can see I was also pro interfaces. However the issue of backwards
compatibility is really important for projects like Commons providing
basic libraries.

I was always on the opinion that our Configuration interface is too fat.
About 80% percent of its methods actually deal with data conversion. So
my intention is to separate basic operations for accessing properties
from high-level convenience methods.

Interfaces are especially useful where you expect multiple
implementations. This is the case for the part I called
ConfigurationSource, i.e. the actual management of configuration
properties. It is not the case for stuff like data conversions. We will
implement this once and use it throughout the library. Thus it is fine
with me having a class that provides a richer API built on top of the
fundamental ConfigurationSource interface. The class merely serves as a
kind of decorator; you can still pass the ConfigurationSource objects
around, which contain the actual content.

The names I used - ConfigurationSource for the interface and
Configuration for the decorator class - may not be the best choice though.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Ralph Goers
I believe this is the only discussion on 2.0 I've seen on the dev list.
I went and scanned the archives a while ago. Rereading this thread I
don't really see a decision to use an Abstract class.  I'm not sure I
understand the discussion about which is more extendable. Yes, an
abstract class means you can provide a dummy implementation, but this is
only of value if there are implementations of that extend it outside the
project. I also tend to believe that thinking that you are somehow
better off with the abstract class is a fallacy. In many cases the
method you will be provide will either do nothing useful or will be
inappropriate for the "real" implementation. In both cases the
implementation class will still have to be modified to provide an
appropriate implementation of the new method. But worse, you won't get
an indication that things are "broken" because the method will be there.
If you were using an interface the problem would be apparent at load
time and the implementation would have to change to be compatible with
the new release.

BTW - there is no reason you can't have an interface and an abstract
base class.

Ralph

Oliver Heger wrote:

>
> I found a reference to the original discussion. It came up when we
> talked about new features for Configuration 2.0:
>
> http://www.nabble.com/-configuration--What-changes-in-Commons-Configuration-2.0---td15530059.html 
>
>
> As you can see I was also pro interfaces. However the issue of
> backwards compatibility is really important for projects like Commons
> providing basic libraries.
>
> I was always on the opinion that our Configuration interface is too
> fat. About 80% percent of its methods actually deal with data
> conversion. So my intention is to separate basic operations for
> accessing properties from high-level convenience methods.
>
> Interfaces are especially useful where you expect multiple
> implementations. This is the case for the part I called
> ConfigurationSource, i.e. the actual management of configuration
> properties. It is not the case for stuff like data conversions. We
> will implement this once and use it throughout the library. Thus it is
> fine with me having a class that provides a richer API built on top of
> the fundamental ConfigurationSource interface. The class merely serves
> as a kind of decorator; you can still pass the ConfigurationSource
> objects around, which contain the actual content.
>
> The names I used - ConfigurationSource for the interface and
> Configuration for the decorator class - may not be the best choice
> though.
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Interface vs class

Jörg Schaible-3
Hi,

Ralph Goers wrote:

> I believe this is the only discussion on 2.0 I've seen on the
> dev list.
> I went and scanned the archives a while ago. Rereading this thread I
> don't really see a decision to use an Abstract class.  I'm not sure I
> understand the discussion about which is more extendable. Yes, an
> abstract class means you can provide a dummy implementation,
> but this is
> only of value if there are implementations of that extend it
> outside the
> project. I also tend to believe that thinking that you are somehow
> better off with the abstract class is a fallacy. In many cases the
> method you will be provide will either do nothing useful or will be
> inappropriate for the "real" implementation. In both cases the
> implementation class will still have to be modified to provide an
> appropriate implementation of the new method. But worse, you
> won't get
> an indication that things are "broken" because the method
> will be there.
> If you were using an interface the problem would be apparent at load
> time and the implementation would have to change to be
> compatible with
> the new release.
>
> BTW - there is no reason you can't have an interface and an abstract
> base class.

IMHO we should define what we want to reach. Adding a method to an interface does not break *binary* compatibility of existing code. The method is simply not called. However, a client will have to implement the new method, if CConf is a compile time dependency *and* he uses an implementation not delivered by CConf. Maybe it is the best approach to have an abstract base class and the interface. We have to tell our users, that they should extend from the abstract class if they want to ensure backward compatibility for own implementations of the Configuration interface. Point is, that it *is* only an advice/recommendation and something like clirr will always report a violation in compatibility. Hoiwever, it is our desicion how we should proceed.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Oliver Heger-3
Jörg Schaible schrieb:

> Hi,
>
> Ralph Goers wrote:
>> I believe this is the only discussion on 2.0 I've seen on the
>> dev list.
>> I went and scanned the archives a while ago. Rereading this thread I
>> don't really see a decision to use an Abstract class.  I'm not sure I
>> understand the discussion about which is more extendable. Yes, an
>> abstract class means you can provide a dummy implementation,
>> but this is
>> only of value if there are implementations of that extend it
>> outside the
>> project. I also tend to believe that thinking that you are somehow
>> better off with the abstract class is a fallacy. In many cases the
>> method you will be provide will either do nothing useful or will be
>> inappropriate for the "real" implementation. In both cases the
>> implementation class will still have to be modified to provide an
>> appropriate implementation of the new method. But worse, you
>> won't get
>> an indication that things are "broken" because the method
>> will be there.
>> If you were using an interface the problem would be apparent at load
>> time and the implementation would have to change to be
>> compatible with
>> the new release.
>>
>> BTW - there is no reason you can't have an interface and an abstract
>> base class.
>
> IMHO we should define what we want to reach. Adding a method to an interface does not break *binary* compatibility of existing code. The method is simply not called. However, a client will have to implement the new method, if CConf is a compile time dependency *and* he uses an implementation not delivered by CConf. Maybe it is the best approach to have an abstract base class and the interface. We have to tell our users, that they should extend from the abstract class if they want to ensure backward compatibility for own implementations of the Configuration interface. Point is, that it *is* only an advice/recommendation and something like clirr will always report a violation in compatibility. Hoiwever, it is our desicion how we should proceed.
>
> - Jörg
>
I 'd be happy to do it this way, but I am skeptical whether such a
policy can actually be established. You know how hard it is to convince
people to vote +1 for a release. If clirr claims that there is a binary
incompatible change, chances a pretty good that you get a veto.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Interface vs class

Jörg Schaible-3
Hi Oliver,

Oliver Heger wrote:
> Jörg Schaible schrieb:
>> Hi,

[snip]

>> IMHO we should define what we want to reach. Adding a
>> method to an interface does not break *binary* compatibility
>> of existing code. The method is simply not called. However, a
>> client will have to implement the new method, if CConf is a
>> compile time dependency *and* he uses an implementation not
>> delivered by CConf. Maybe it is the best approach to have an
>> abstract base class and the interface. We have to tell our
>> users, that they should extend from the abstract class if
>> they want to ensure backward compatibility for own
>> implementations of the Configuration interface. Point is,
>> that it *is* only an advice/recommendation and something like
>> clirr will always report a violation in compatibility.
>> Hoiwever, it is our desicion how we should proceed.
>>
>> - Jörg
>>
> I 'd be happy to do it this way, but I am skeptical whether such a
> policy can actually be established. You know how hard it is
> to convince
> people to vote +1 for a release. If clirr claims that there
> is a binary
> incompatible change, chances a pretty good that you get a veto.

Clirr is used to detect unintentional binary incompatibility. If we document the facts (in site documentation and javadoc) everybody is informed and should not be surprised if we actually follow this agenda. If a new version is enhancing the Configuration interface then, the release manager should state this fact in release notes and vote call by documenting the *expected* clirr result with a pointer to the agreement that is used as basis for the incompatibility. IMHO this should be enough. Following either the interface or the abstract class approach has its downside. Maybe such a combination will give you the pros of both worlds.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Simon Kitching
Jörg Schaible schrieb:

>>> IMHO we should define what we want to reach. Adding a
>>> method to an interface does not break *binary* compatibility
>>> of existing code. The method is simply not called. However, a
>>> client will have to implement the new method, if CConf is a
>>> compile time dependency *and* he uses an implementation not
>>> delivered by CConf. Maybe it is the best approach to have an
>>> abstract base class and the interface. We have to tell our
>>> users, that they should extend from the abstract class if
>>> they want to ensure backward compatibility for own
>>> implementations of the Configuration interface. Point is,
>>> that it *is* only an advice/recommendation and something like
>>> clirr will always report a violation in compatibility.
>>> Hoiwever, it is our desicion how we should proceed.
>>>
>>> - Jörg
>>>
>>>      
>> I 'd be happy to do it this way, but I am skeptical whether such a
>> policy can actually be established. You know how hard it is
>> to convince
>> people to vote +1 for a release. If clirr claims that there
>> is a binary
>> incompatible change, chances a pretty good that you get a veto.
>>    
>
> Clirr is used to detect unintentional binary incompatibility. If we document the facts (in site documentation and javadoc) everybody is informed and should not be surprised if we actually follow this agenda. If a new version is enhancing the Configuration interface then, the release manager should state this fact in release notes and vote call by documenting the *expected* clirr result with a pointer to the agreement that is used as basis for the incompatibility. IMHO this should be enough. Following either the interface or the abstract class approach has its downside. Maybe such a combination will give you the pros of both worlds.
>  
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.

That sounds like a pretty good approach to me; seems to ensure maximum
backward compatibility while keeping a clean interface-based API (which
allows interface-based proxies to be generated at runtime).

I would agree with Jörg here, that as long as release-notes document
expected clirr incompatibilities there is no problem. Clirr can of
course be configured to ignore specific classes when processing...

Regards, Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

James Carman
On Wed, Nov 5, 2008 at 4:04 AM, Simon Kitching <[hidden email]> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Simon Kitching
James Carman schrieb:

> On Wed, Nov 5, 2008 at 4:04 AM, Simon Kitching <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

James Carman
On Wed, Nov 5, 2008 at 4:42 AM, Simon Kitching <[hidden email]> wrote:
> The standard JDK interface-based proxying would certainly become more
> useful.
>

I meant changing Proxy's ProxyFactory from a class to an interface (or
perhaps introducing the IProxyFactory interface and leaving
ProxyFactory as the default implementation, based on JDK proxies).

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

This pattern (replacing the implementation of specific methods) is not
supported "out of the box" by Proxy, but perhaps it should be?  I
wonder how common it is that you'd want to replace the implementation
of certain methods and you wouldn't just go ahead and extend the class
and override the methods yourself?  Now, if the class is final, you
can't extend it, but then again you wouldn't be able to proxy it
anyway unless of course you're trying to replace the implementation of
an implemented interface's method.

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Simon Kitching
James Carman schrieb:

>
> This pattern (replacing the implementation of specific methods) is not
> supported "out of the box" by Proxy, but perhaps it should be?  I
> wonder how common it is that you'd want to replace the implementation
> of certain methods and you wouldn't just go ahead and extend the class
> and override the methods yourself?  Now, if the class is final, you
> can't extend it, but then again you wouldn't be able to proxy it
> anyway unless of course you're trying to replace the implementation of
> an implemented interface's method.
>  
This is getting a little off-topic, but...

The decorator pattern is hugely useful. In particular, you can apply a
decorator to an existing object (eg something returned by a library),
which you cannot achieve by subclassing something. Even when it is your
own code that is creating the actual object instance, a decorator is
sometimes a more elegant approach than subclassing anyway.

Having commons-proxy provide a way to proxy just specific methods would
be nice, although not critical IMO. Proxying a specific method or
methods can of course be built on top of a generic proxy API simply by:
  if (method.name == "foo") {
    // do something
  } else {
    method.invoke(proxy, args); // just forward the call on to the
original object
  }
but this is a little ugly.

Having commons-proxy support running AOP Advices for specific methods
while passing the others through automatically would be nice. However
the standard "pointcut" language for specifying which methods to match
is rather ugly and complex. And turning commons-proxy into a full AOP
library supporting the org.aopalliance.aop.* APIs
(http://aopalliance.sourceforge.net/) would be a big job. I presume
you're aware that springframework.org includes extensive AOP support
based on the aopalliance APIs?

Regards, Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

James Carman
On Wed, Nov 5, 2008 at 5:36 AM, Simon Kitching <[hidden email]> wrote:

> James Carman schrieb:
>>
>> This pattern (replacing the implementation of specific methods) is not
>> supported "out of the box" by Proxy, but perhaps it should be?  I
>> wonder how common it is that you'd want to replace the implementation
>> of certain methods and you wouldn't just go ahead and extend the class
>> and override the methods yourself?  Now, if the class is final, you
>> can't extend it, but then again you wouldn't be able to proxy it
>> anyway unless of course you're trying to replace the implementation of
>> an implemented interface's method.
>>
> This is getting a little off-topic, but...

You're right.  Perhaps we should start another [proxy] thread.  Sorry
to hijack, but someone else brought up proxy in the context of this
interface vs. class discussion (since we had this discussion before
w.r.t. proxy). :)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

rgoers
In reply to this post by Jörg Schaible-3
On Wed, Nov 5, 2008 at 12:25 AM, Jörg Schaible
<[hidden email]>wrote:

> Hi Oliver,
>
>
> Clirr is used to detect unintentional binary incompatibility. If we
> document the facts (in site documentation and javadoc) everybody is informed
> and should not be surprised if we actually follow this agenda. If a new
> version is enhancing the Configuration interface then, the release manager
> should state this fact in release notes and vote call by documenting the
> *expected* clirr result with a pointer to the agreement that is used as
> basis for the incompatibility. IMHO this should be enough. Following either
> the interface or the abstract class approach has its downside. Maybe such a
> combination will give you the pros of both worlds.
>
> - Jörg


+1
Ralph
Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Interface vs class

Jörg Schaible
In reply to this post by Simon Kitching
Simon Kitching wrote:

[snip]

> 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.
>
> That sounds like a pretty good approach to me; seems to ensure maximum
> backward compatibility while keeping a clean interface-based API (which
> allows interface-based proxies to be generated at runtime).
>
> I would agree with Jörg here, that as long as release-notes document
> expected clirr incompatibilities there is no problem. Clirr can of
> course be configured to ignore specific classes when processing...

Exactly ... it's always nice to get a clean summary by a native speaker :)

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12