That's probably my fault: I added a lot of interfaces to DbLinq, with the idea to add modularity. Anyway, even if you remove interfaces, it's still easy to reintroduce them later (with tools like ReSharper, for example).Since you're much more active on the product than I am, if you feel the interfaces cause too many problems, then remove some of them. But I'm not fan of removing interfaces between the core and the vendors, since that's exactly the interface purpose: keeping loose coupling between the modules.
On Fri, May 8, 2009 at 05:05, Jonathan Pryor <[email protected]> wrote: > So interfaces should be used each time that we could imagine a different > implementation with the same shape: adding a method could add a behaviour > not change an existing one. > > Then what's the difference between an interface and an abstract class (or a > class with all virtual members)? Both allow you to implement the methods to > support new functionality. > > The difference is that interfaces don't "burn your base class", which > doesn't appear to be an issue here. On the plus side, you can use > interfaces with structs -- but we're not using structs, so I'm not sure > that's relevant. I also don't currently see in which circumstances loses > the base class would actually be detrimental. Again, with classes you can > make the members virtual, thus allowing base classes to override them and > provide new functionality. > > You're right that adding a new method can only add behavior, not change > existing one -- so behavioral changes would require changing all existing > implementations *anyway*, for both interfaces and classes -- but classes > make adding additional considerably easier. > > So why do we *need* interfaces for many of our current uses? What makes > interfaces superior to abstract classes, for our current uses? I'm not > seeing any use of multiple-inheritance, nor value types, so I don't > currently see any circumstances that would *require* interfaces. > Meanwhile, using classes would permit easier sharing of implementation code > (which is why everybody inherits from SqlProvider instead of > re-implementing ISqlProvider), makes it easier to add additional > non-behavioral-changing functionality, and thus simplifies maintenance. > > - Jon > > > On Thu, 2009-05-07 at 22:43 +0100, Giacomo Tesio wrote: > > just some: > 3: in the medium term, I hope to find time to move dblinq to a better > service location infrastructure. > (actually i'm thinking about the Common Service Locator) > > I agree that some interfaces could be removed, but some should not (as > IQueryCache for example). We should only remove those interfaces that are > too much coupled with their user and/or their implementer that there's no > sane reason to reimplement in an alternative way. > (an example could be IDataMapper as far as I remember). > > But such interfaces often are index of a deep refactoring needed (as the > IDataMapper for example). > > I don't agree that interfaces complicate mantainence. When correcly > designed they have a single abstract responsibility, making mantainence far > easier, and allow to parallelize the programmers' work. > > So interfaces should be used each time that we could imagine a different > implementation with the same shape: adding a method could add a behaviour > not change an existing one. > > BTW when no other behaviour are possible (becouse of the coupling) we could > remove interface (but adding a TODO: evaluate refactoring needs here) > > > Giacomo > > On Thu, May 7, 2009 at 9:42 PM, Jonathan Pryor <[email protected]> wrote: > > I'd like to start a discussion about "cleaning up" the DbLinq source > tree. I have two annoyances I'd like to clean up. > > First #if removal. I understand (and support) the need for #ifs > (especially since they're needed for Mono). I don't think we need to use > #if as often as we do, though. Consider this, from > src/DbLinq/Data/Linq/Sugar/Implementation/QueryCache.cs: > > #if MONO_STRICT > namespace System.Data.Linq.Sugar.Implementation > #else > namespace DbLinq.Data.Linq.Sugar.Implementation > #endif > { > internal class QueryCache : IQueryCache > > The class is internal, and thus will never be exported from the > assembly. Other assemblies are public, but only for the !MONO_STRICTbuild. > > Consequently, I would like to remove most of these, and just stick to the > DbLinq root namespace. > > Secondly, and more likely controversially, I'd like to remove most of the > interfaces (e.g. ISqlProvider, etc.), for several reasons: > > 1. FxDG suggests using classes over interfaces most of the time, because of > easier versioning. You can easily add methods to classes without "breaking" > existing derived types, but it's not possible to add new methods to > interfaces. (See also the earlier email for fixing .Count() SQL > generation.) For comparison, consider how .NET 1.0 had the IDb*interfaces, > while .NET 2.0 moved to the > Db* classes. Easier versioning is useful. > > 2. Most derived types are already using the helper classes instead of the > interfaces. > > 3. The interfaces *complicate* maintenance. If use VS.NET and you're in a > method, e.g. QueryBuilder.BuildSqlQuery(), and you right-click > SqlBuilder.BuildSelect(), right-click, and click *G*o To Definition, you > wind up at the interface definition. That's not very useful. Especially > since we use ObjectFactory.Get<T>(), so there can really only be one > implementation for the ISqlBuilder interface *anyway*. The "workaround" > is to use Find All References, which is slower and cumbersome compared to Go > To Definition. This is clunky. > > 3.a. Another place where maintenance is complicated is in the necessary > duplication of methods between the interface and the implemented types. > When this is needed, it's a necessary complication, but I don't see the need > for it. The result is that if you need to add behavior that requires > changing an interface, you change the interface and all implementations > (even when -- *especially when* -- there's a sane default behavior for the > added method). > > 4. The use of interfaces leads to having nested Implementation directories > everywhere, which makes for "deeper" project solutions and longer namespace > names (and thus harder to navigate to files within the VS Solution > Explorer). I would like to remove them, thus "flattening" the project > directory structure. > > Thoughts? > > - Jon > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
