Consider an assembly dll called “D” that references some class (sealed or not) called “C”. This means that one can see in D things like (perhaps the list is not exhaustive):
SomeType someOtherMethod(…,C parameter,…);
class Cls:C (
(Scenario 1) At some later date, I would like to reuse D in a scenario where C is inappropriate, and another class, C1, would be better suited. C1 “looks” like C (has the exact same public surface, position in inheritance tree).
The end result is a version of D with no dependencies on C, and only dependencies on C1.
(Scenario 2) At this point, I realize that perhaps it’d be best if I created an interface, IC, with the same public surface of C. I would like D rewritten to reference IC. Instead of “new C”, use some factory that pulls some information from the configuration system as to which class to instantiate. If some class inherits from C – make a decision (options include: get the class to implement the interface and delegate to a private implementation of IC, which you instantiate with the same factory; or remove the class from the assembly and place it into another one).
The end result is that I obtain a version of D which has no dependency on C and only on IC. Moreover, I can select which IC implementation to use from some configuration mechanism (say app.config)
What I am looking for is a complete or partial solution to either Scenario 1 or 2. I’m interested in the problems that are encountered and the assumptions made to overcome them. Any problem scope-reducing assumption is valid, as long as “the end results” are obtained, i.e. it is valid to assume that C can only be deriving from object, for example, if that simplifies the problem.
To summarize, there are 2 deliverables: functional tool (source code and all) + some example setup (some dll that it all works on); and a report detailing: