Thank you Lucas, You caught my point nicely and even got a clearer idea of what to do. Sorry Solr Dev Team, but I don't there is any reasonable excuse for making such an argument interface vs abstract class as they are complements and don't have the same role in OOP.
Anyways, Solr is a great app. I just don't think it has the better programming practices, but that is just me. Let's not turn that in a flame, or big discussion. 2008/6/9 Lucas F. A. Teixeira <[EMAIL PROTECTED]>: > Exactly, > > And adding the methods in the abstract class in the minor releases, and in > the interface in major releases. > > []s, > > Lucas > > Lucas Frare A. Teixeira > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > Tel: +55 11 3660.1622 - R3018 > > > > Alexander Ramos Jardim escreveu: > > 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
