在抽象基础 class 的帮助下避免 DRY 违规。 如何重构它？ 寻找替代品 / arguments

Question

(Note: one solution which works you can find at the bottom of this question)

I am currently trying to refactor a generic class/interface where I have a covariant and contravariant parameter. The reason for the refactor is that at the moment I have to implement for all given use-cases the class N-times.

My aim / the Idea therefor were to write an abstract class containing shared functionality and make the one complex method abstract which needs a concrete implementation for each use-case. The abstract base class would for legacy reasons still inherit from the original interface which is a generic one.

you can find the Original structure of the code here: https://dotnetfiddle.net/ZgGihl

What i tried to do was the following code snippet

https://dotnetfiddle.net/Aub8Ov

The are two problems with this way:

1. The obvious one is that this cannot compile because, if i understood contravariants correctly it expects the exact type.
2. The second problem is I have just created three distinct generic instances of the abstract class which cannot be used as common reference for the concret implementation.

Questions

• Is there a way to solve the problem in someway via generics and covariants without introducing a new Interface?

    interface test <out TInput, in TResult> 
    {
        void setResult(TResult result);
        TInput GetInput();
    }

    abstract class SemiConcreteTest<TInput, TResult> : test<TInput, TResult> 
    {
        public TResult field;

        public void setResult(TResult result)
        {
            field = result;
        }

        public abstract TInput GetInput();

    }

    //The UseCases

    ....

    class concreteTest_A<TResult> : SemiConcreteTest<int,TResult> 
    {
        public override int GetInput()
        {
            //Some information gathering
            throw new System.NotImplementedException();
        }


    }

    //UsesCase Specific Classes
    interface Itag
    {

    }

    class A : Itag{}
    class B : Itag{}
    class C : Itag{}

This way would still lead to n different reference as seen in the example. The first Generic parameter could be ditched by using generics on the method directly instead on the class but this would still left the problem regarding the contravariant

public static void Main()
{
        SemiConcreteTest<int, Itag> a = new concreteTest_A<A>();
        SemiConcreteTest<short, Itag> b = new concreteTest_B<B>();
        SemiConcreteTest<long, Itag> c = new concreteTest_C<C>();
}

---

My Solution ditching the contravarian parameter

What i would do personally is to ditch the contravariant parameter alltogther and replace it with a proper interface but i was asked by coworker , if possible, to avoid that .

My solution would have been this ( https://dotnetfiddle.net/iql682 ):

interface DitchTheContraVariant{}

//The legacy Interface
interface ITest 
{
    void setResult(DitchTheContraVariant result);
    TInput GetInput<TInput>();
}

I Solve the issue regarding the shared reference by using a generic method. as seen above in the interface.

abstract class SemiConcreteTest : ITest {

    DitchTheContraVariant result;
    public void setResult(DitchTheContraVariant result){

        this.result = result;

    }

    public abstract TInput GetInput<TInput>();
}

//The UseCases
class concreteTest_A : SemiConcreteTest
{

    public override T GetInput<T>()
    {
        //Some information gathering
        throw new System.NotImplementedException();
    }


}

class A :DitchTheContraVariant {}
class B :DitchTheContraVariant {}
class C :DitchTheContraVariant {}



public static void Main()
{
    SemiConcreteTest a = new concreteTest_A();
    a = new concreteTest_B();
    a = new concreteTest_C();

    a.setResult(new A());
    int b = a.GetInput<int>();

    Console.WriteLine("Hello");
}

But this would introduce a new interface into the codebase which i try to avoid but i have no idea how. I am not sure how to sell my version to my coworker.

Answer 1

Assuming the goal is to have share the logic of certain methods, we can do it the following way:

Define an abstract class for your test

abstract class SharedTest<TInput, TResult> : Itest<TInput, TResult>
{
    TResult result;

    public virtual void setResult(TResult result)
    {
        this.result = result;
    }

    public abstract TInput GetInput();
}

setResult is marked as virtual just in case other concrete tests want to override the base implementation. If this isn't required, remove the virtual keyword.

This allows your classes to be implemented like:

class concreteTest_A : SharedTest<int,A> 
{
    public override int GetInput()
    {
        //Some information gathering
        throw new System.NotImplementedException();
    }        
}

class concreteTest_B : SharedTest<short, B>
{
    public override short GetInput()
    {
        //Some information gathering
        throw new System.NotImplementedException();
    }
}

class concreteTest_C : SharedTest<long, C>
{
    public override long GetInput()
    {
        //Some information gathering
        throw new System.NotImplementedException();
    }
}

Usage:

Itest<int, A> a = new concreteTest_A();
concreteTest_B b = new concreteTest_B();
SharedTest<long, C> c = new concreteTest_C();