lenya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scher...@wyona.com>
Subject Re: [1.4] Separate API and Implementation?
Date Fri, 07 Apr 2006 11:41:42 GMT
El vie, 07-04-2006 a las 13:30 +0200, Andreas Hartmann escribió:
> Thorsten Scherler wrote:
> > El jue, 06-04-2006 a las 17:40 +0200, Andreas Hartmann escribió:
> >> Hi Lenya devs,
> >>
> >> currently, it's not clear which classes+interfaces form
> >> the Lenya API (i.e., have to stay backwards compatible
> >> and therefore may be used by client code).
> >>
> >> Examples are AbstractUsecase and DocumentUsecase:
> >> Can you extend these classes without the danger of
> >> incompatible changes in future 1.4.x versions?
> > 
> > I am unsure what to tell you. We have a couple of usecases that extend
> > this classes. IMO this default implementations should reflect the least
> > common denominator
> 
> +1
> 
> > and as soon as 1.4.x is in the release cycle they
> > *should* be backwards compatible.
> 
> IMO AbstractUsecase and DocumentUsecase are general enough
> to put them into the API.
> 

agreed, but we still would need an implementation right?

> 
> >> I like the approach taken by Avalon/Excalibur:
> >>
> >> - framework/api/src/java
> >> - framework/api/src/test
> >> - framework/impl/src/java
> >> - framework/impl/src/test
> >>
> >> For example: AbstractLogEnabled is part of the API,
> >> AbstractConfiguration is not. A disadvantage of this
> >> approach is that you can't tell whether a class is
> >> part of the API without knowing where it is located
> >> in the source tree. Maybe we can solve this using
> >> package names which contain "impl":
> >>
> >> o.a.lenya.cms.usecase.*
> >> o.a.lenya.cms.usecase.impl.*
> >>
> >>
> >> Modules are another story, but maybe the same concept
> >> can be applied there.
> >>
> >>
> >> WDYT?
> > 
> > Yeah, with this move we as well should harmonize the naming for the
> > implementation classes.
> > 
> > We have now:
> > - Default{api-class-name}.java
> > - {api-class-name}Impl.java
> 
> I'm using Default{*} if I want to point out explicitely
> that the class is just an example implementation, and
> {*}Impl if it is meant to be (more or less) the only
> implementation. But the differences are subtle, and
> it's fine with me to use only one naming convention.
> 

Thanks for the explaning this, I always wondered. ;)

> 
> > - {different-name-then-the-api-class-name}.java
> > 
> > IMO if we agree on 
> >> o.a.lenya.cms.usecase.*
> >> o.a.lenya.cms.usecase.impl.*
> > 
> > Then we should have
> > - o.a.lenya.cms.usecase.*
> >   * {api-class-name}.java
> > - o.a.lenya.cms.usecase.impl.*
> >   * {api-class-name}.java
> 
> IMO this is not very convenient, because you have to use
> explicit package declarations (which is quite verbose),
> and the class name references are ambiguous.
> 
> For example:
> 
>    package org.apache.lenya.cms.impl.Document;
> 
>    class Document implements org.apache.lenya.cms.Document {
> 
>        public org.apache.lenya.cms.Document getParent() {
>            ....
>            org.apache.lenya.cms.Document doc = ...
>            return doc;
>        }
> 
>    }
> 
> In other classes in the *.impl package you might want to
> access *.impl.Document instances directly (not via the
> interface), which is perfectly valid. IMO this makes the
> code hard to understand, because you always have to check
> the imports to know if it's an *.Document or *.impl.Document.
> 
> 
> I'd prefer
> 
>   - o.a.lenya.cms.usecase.*
>     * {api-class-name}.java
>   - o.a.lenya.cms.usecase.impl.*
>     * {api-class-name}Impl.java
> 

Makes perfect sense to me.

+1

> 
> Thanks for your comments!

Thanks for bringing this up.

salu2
-- 
Thorsten Scherler
COO Spain
Wyona Inc.  -  Open Source Content Management  -  Apache Lenya
http://www.wyona.com                   http://lenya.apache.org
thorsten.scherler@wyona.com                thorsten@apache.org


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


Mime
View raw message