Reputation: 937
I have an interface called IProjectUser that defines a read function and a write function for reading and writing to project files. I also have a class called Project that holds a generic list of IProjectUser objects to manage project files. Both of these are in the class library Project.dll.
I also have a class library called A.dll that contains a class called Foo which implements IProjectUser. The ability to read/write project files is secondary to this class. It holds and manipulates some data. A.dll references Project.dll.
The application also contains some forms and other classes that implement IProjectUser.
I can imagine a situation in the future where I might want to use A.dll in another project that doesn't use project files. However I will be forced to include Project.dll just because A.dll requires it. Even though the functionality is optional.
Is there a different design pattern that would allow me to essentially make an interface optional?
I hope I explained this clearly enough.
Update
What about casting objects to interfaces? This would open up the possibility that an interface is not implemented correctly. Is that a good or bad design approach for this kind of problem?
if (Foo is IProjectUser) {
ProjectUsers.Add(Foo as IProjectUser);
// etc
}
Upvotes: 1
Views: 310
Reputation: 307
Casting your object to an interface that it doesn't implement will not work -- you'll end up with a null value in your variable. What's wrong with using proper design and adding B.dll as suggested below? A.dll becomes completely reusable, and you still get to have a version of Foo that implements IProjectUser.
Upvotes: 1
Reputation: 190976
Use inherited or multiple interfaces. You cannot make an interface method optional.
Upvotes: 2