Well, There is a simple case here. I tried to update SolrJ to use the last one and got the application selected for test broke. So, I developed an alternative interface for SolrServer and a wrapper to CommonsHttpSolrServer. Altered my aoolication to use it and everything is working nice.
When you use good pratices like IoC or AOP it is preferred to program interface oriented. Sorry, but I find it really bad to go from an interface to a an abstract class. In my modest opinion, SolrServer should have both. Like SolrServer being an interface and AbstractSolrServer implementing it. CommonsHttpSolrServer would extend AbstractSolrServer. If the dev team really thinks interfaces are an ass, I think we will have problems using Solr with other advanced OO features. 2008/6/7 Ryan McKinley <[EMAIL PROTECTED]>: > solrj was not released in 1.2, so the change is not incompatible... > > The rationalle for abstract class vs interface is more to do with usage and > future maintenance. If SolrServer is an interface and solr 1.4 adds > methods, there is no way to make it backwards compatible -- as an abstract > class, we can add a reasonable default behavior. > > Since SolrServer is a rather involved action, it seems like it will tend to > be a standalone class. Interfaces are great for OO clarity, but very > difficult to maintain. > > Is there a good usage case we are not thinking of before this gets baked > into 1.3? > > ryan > > > > On Jun 7, 2008, at 2:13 PM, Alexander Ramos Jardim wrote: > >> Hello, >> >> Shouldn't SolrServer be an interface that externalizes the signatures for >> classes like CommonsHttpSolrServer, like it was in solr-1.2? Why did it >> became an abstract class? >> I can't see any benefit from it, as now I need to type the object as >> CommonsHttpSolrServer directly. >> I think it is really bad. >> -- >> Alexander Ramos Jardim >> > > -- Alexander Ramos Jardim
