On 02/16/2012 04:01 AM, Kevin wrote:
I was implementing a framework and I found that I wanted two things.
- A strong set of interfaces so that I can get what I want from a
variety of sources.
- Some basic implementations of these interfaces.
For example, say I was writing a database class. I could either name the
interface Database and call the class DatabaseImplementation or
something but that is ugly. If I call the interface IDatabase, the
Database class looks nice but I need to convince users to write
functions that take IDatabases not Databases.
I was wondering if there was any way to implement a default
implementation. This way, I could create my Database interface and
classes could implement that but if you called `new Database()` you
would still get a basic database.
I thought about doing it in different modules but it just gets messier
as you have to fully qualify all of the names so both look ugly. I
though about overloading the new operator for the interface but it would
have to be final and that would mess everything up. I though about a
meathod like `Database.newDefault()` but that is messy and has no
meaning in a derived class.
I couldn't find anything about this so I was wondering what you would
recommend. Should I just pick a naming scheme?
As a user (read developer), I'd rather code to the generic interface
when possible. I like that concrete implementations looks rather long
and ugly :)
I don't think you should be worried that your users is using direct
implementations rather than the interface - their problem!
Remember that in D, interfaces can contain implementations that only
uses static methods on the interface:
interface DB {
@property string name();
// interfaces can have implementations
static DB createDefault() { return new GenericDB(); }
}
class GenericDB : DB {
@property string name() {
return "generic"; }
}
class MySQLDB : DB {
@property string name() {
return "mysql"; }
}
void main() {
assert(DB.createDefault().name == "generic");
assert((new MySQLDB()).name == "mysql");
}
