C++ supported multiple inheritance. Generally a frowned upon feature, because
apparently some guy was able to repeatedly shoot himself into the foot with it,
multiple inheritance allowed for some conveniency when defining interfaces:
public: void blit(IBitmap target) {
blit(target, Region(0, 0, width, height));
}
public: virtual void blit(IBitmap target, Region region) = 0;
};
Any class implementing the IBitmap interface would now
automatically have a blit method that omits the Region
parameter.
Now C# comes along, says that interfaces are something different from classes,
that interfaces can only contain abstract methods, properties and events. Now
we have to make both blit methods abstract and reimplement the default logic
in all implementing classes - or remove it.
Then C# 3.0 tries to patch this and invents Extension Methods,
a nightmarish hack. Basically, you can now write some arbitrary method like…
public void blit(this IBitmap self, IBitmap target) {
self.blit(target, Region(0, 0, self.width, self.height));
}
}
…and it will allow you to act as if blit() was another member
of the IBitmap interface (notice the this
keyword on the method’s argument list):
IBitmap screen, sprite;
sprite.blit(screen); // calls IBitmapMethods.blit()
Fantastic, guys. Now I can basically write any method for any class in
any namespace and it will only be callable when the caller has the proper
namespace imported. Method definitions for my class can appear througout
the whole codebase, basically you could see code like:
public class Foo { /* look ma, no methods */ }
class Program {
static void Main() {
foo.Bar(); // WTF?
}
}
That’s an exaggerated example and nobody should misuse this feature like that,
you say? Well, the argumentation that “someone could” was enough to
give multiple inheritance a bad reputation. Bad programmers do bad things,
whether their tool is multiple inheritance or extension methods.
Recent Comments