Reputation: 24406
I'm designing a framework which users can extend. Basically I will provide them a set of interfaces which they can implement, and my "manager" class will call their implementations like this:
abstract1 = factory.GetConcreteExtension1()
abstract2 = factory.GetConcreteExtension2()
abstract1.DoSomething(abstract2)
Where my client implements the concrete version of the abstractions. However they might decide to add data to concrete2 which is not in the abstract2 interface. This will force them to downcast abstract2 to concrete2 in concrete.DoSomething implementation.
This looks like a code smell because I force them to implement a method (DoSomething) which in its signature expects abstract1 but actually can only get concrete1 (plus I force them to write the casting).
I can't find a solution that both keeps contract well defined and allows my framework to manage the process by itself. Any ideas?
Upvotes: 2
Views: 437
Reputation: 3018
So abstract1's DoSomething is called with the parameter abstract2 and you want to get to abstract2's data from the DoSomething method?
In this case it seems to me that it would be better to give abstract2 behaviour so that abstract1 interacts with it through abstract2's behaviour and not through its data.
Upvotes: 2
Reputation: 60498
It would depend on the language you are using, but in C# for example you could use templates with a constraint on them to give you type safety while still enforcing that the class must be derived from your abstract base class.
Upvotes: 1