As we have grown our CSLA-based application over the 18 months we have been working on it, we have discovered over time that we want to use different classes in the same context and have been gradually adding interfaces to them. So far, the most I have in one class is in the range of 5-10.
The vast majority of them have only a few members, and in a few cases only 1.
What potential pitfalls lurk as the number of implemented interfaces increase? Or should I not worry about this at all?. Without knowing for sure, I'd expect that casts might become increasingly expensive, but otherwise I can't think of what practical impact it they would have.
I freely admit that I am comparatively new to C# and come from long C++ background where I didn't have interfaces at all. So having the ability to have completely unrelated classes share a common interface that lets them be used in the same place is like being a kid in a candy store... :)
Interfaces are used everywhere in .NET. All the value types implement 5 interfaces, plus they have the Serializable attribute (which could have been implemented using ISerializable instead). I built an object for one of our company libraries that we use like a value type, and it implements 6 interfaces, as well as being marked Serializable. No one has complained about performance, and the interfaces are there so that the object plays nice with all the .NET stuff.
Admittedly, you're probably not building BO's that are intended to work as .NET value types, so let's look at an example a little closer to home - BusinessBase. The 3.0 version (the only code I currently have available to me) implements five interfaces, as well as inheriting from base classes that add two more. I'm pretty sure later versions don't change that.
As Andy said, I don't think it's the number of interfaces in use as much as how they're affecting the use of your class. If you were marking your classes with 15 or 20 of them, I might ask why, and whether there's a better way of structuring what you need. Heck, I might even ask on those where you're implementing 10. But I wouldn't look at it from a performance perspective - I'd look at it from a maintainability/use perspective. Since you're talking about "completely unrelated classes... [being] used in the same place", that makes me wonder a little. But since I don't know anything about your project, I can't comment any more beyond some vague personal preferences/feelings.
HTH
- Scott
Thanks for both replies. When I said "completely unrelated", I mainly meant that one is neither an ancestor nor descendant of the other from an inheritance perspective.
Usually what I am trying to do by adding an Interface is to reuse behavior from one previously existing BO in a new BO.
What usually happens is that all the necessary methods exist in one class, and I'm trying to extend that behavior to another class. So, I make an interface out of the required methods in the original class (which already implemented them anyway), and then add the interface to the new class and implement the necessary methods.
My situation may differ from the common one in that very few, if any of our concrete BO classes directly derive from a CSLA class, there is always an intervening classes that form our own application framework. The interfaces are usually in these intervening classes.
I also add interfaces for common functions I want to get to because anything derived from CLSA has generic parameters, and so you need something common to cast to get to the common function.
Copyright (c) Marimer LLC