To interface or not to interface

[Marianne Gagnon]

In my experience (not related to DCollections), having interfaces is useful to ensure reduced coupling, thus enabling the use of mock classes for unit tests (or simply to test your module, when your module needs to use services provided by another module that is being written by a colleague but not yet usable, etc...)

> A long discussion on the utility of interfaces has taken place on the  
> announce newsgroup following my announcement of dcollections for D2.
> 
> Dcollections supports interfaces peripherally.  Meaning the types in  
> dcollections are essentially concrete classes with interfaces tacked on  
> for cases where interfaces make sense.
> 
> Whenever I've used dcollections (D1 included) I don't think I've ever used  
> the interface for a container, only the concrete type.  But within  
> dcollections, there's some functions that use the interface type to do  
> (IMO) nifty things like compare two sets that have different  
> implementations.
> 
> The general consensus is that interfaces for dcollections do not add any  
> meaningful value, and that I should do everything with generic programming  
> and templates.  My view is that interfaces are useful for binary  
> compatibility and in reducing the footprint of executables.  But that  
> doesn't mean much at the moment, because D is statically linked.
> 
> I'd ask the naysayers of interfaces for dcollections, and also the  
> supporters: what is the point of having interfaces in D?  Are interfaces  
> pretty much obsolete, and I am just nostalgic about their utility?
> 
> What do you think?
> 
> -Steve