On Thu, Sep 3, 2009 at 4:48 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:
Hi,

I have checked the various interfaces we have. Here is some first result.

The OperationManager interface defines those methods :
*    void add( AddOperationContext opContext ) throws Exception;
*    void bind( BindOperationContext opContext ) throws Exception;
  boolean compare( CompareOperationContext opContext) throws Exception;
*    void delete( DeleteOperationContext opContext ) throws Exception;
  LdapDN getMatchedName( GetMatchedNameOperationContext opContext ) throws Exception;
  ClonedServerEntry getRootDSE( GetRootDSEOperationContext  opContext ) throws Exception;
  LdapDN getSuffix ( GetSuffixOperationContext opContext ) throws Exception;
*    boolean hasEntry( EntryOperationContext opContext ) throws Exception;
*    EntryFilteringCursor list( ListOperationContext opContext ) throws Exception;
  Set<String> listSuffixes( ListSuffixOperationContext opContext ) throws Exception;
*    ClonedServerEntry lookup( LookupOperationContext opContext ) throws Exception;
*    void modify( ModifyOperationContext opContext ) throws Exception;
*    void move( MoveOperationContext opContext ) throws Exception;
*    void moveAndRename( MoveAndRenameOperationContext opContext ) throws Exception;
*    void rename( RenameOperationContext opContext ) throws Exception;
*    EntryFilteringCursor search( SearchOperationContext opContext ) throws Exception;
*    void unbind( UnbindOperationContext opContext ) throws Exception;

The Partition interface defines those methods :
*    void add( AddOperationContext opContext ) throws Exception;
*    void bind( BindOperationContext opContext ) throws Exception;
*    void delete( DeleteOperationContext opContext ) throws Exception;
  void destroy() throws Exception;
  int getCacheSize();
  String getId();
  String getSuffix();
  LdapDN getSuffixDn() throws Exception;
  LdapDN getUpSuffixDn() throws Exception;
*    boolean hasEntry( EntryOperationContext opContext ) throws Exception;
  void init( DirectoryService core ) throws Exception;
  boolean isInitialized();
*    EntryFilteringCursor list( ListOperationContext opContext ) throws Exception;
  ClonedServerEntry lookup( Long id ) throws Exception;
*    ClonedServerEntry lookup( LookupOperationContext lookupContext ) throws Exception;
*    void modify( ModifyOperationContext opContext ) throws Exception;
*    void move( MoveOperationContext opContext ) throws Exception;
*    void moveAndRename( MoveAndRenameOperationContext opContext ) throws Exception;
*    void rename( RenameOperationContext opContext ) throws Exception;
*    EntryFilteringCursor search( SearchOperationContext opContext ) throws Exception;
  void setCacheSize( int cacheSize );
  void setId( String id );
  void setSuffix( String suffix );
  void sync() throws Exception;
  void unbind( UnbindOperationContext opContext ) throws Exception;


The '*' in front of each methods describe the common methods. Can't we define a common interface for those methods, and other interfaces for specific methods ?

Thoughts ?


I agree that there is a lot of overlap between interfaces.  I don't know if an interface hierarchy across all these concerns is going to give us some advantage.   It might help us collect our thoughts on some things to understand and see these relationships while visualizing the architecture.

In general though I don't like to push these relationship via an interface hierarchy without having a strong compelling reason for the association.  I agree that there is a basis to NexusPartition and Partition but I don't see this in CoreSession with Partition.

Also keep in mind if for some reason you need to change a signature because a new issue creeps up all of a sudden as we progress with features, say in the CoreSession, then there's a chance this new feature may force the signatures to diverge from say the Partition interface needs.  If a common ancestor interface is used we have interface coupling to deal with.

My MO is simplicity always is best.  Keep things as one structure for one task as much as possible unless there is a significant gain that you'll get from it.  When the gain outweighs the hassles of dealing with coupling then refactor in such a way that you decouple while still getting those gains. 

Alex

 
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org





--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org