c# - 在C#类库中传递上下文，在不使用static的情况下寻找 "easy"的方式

Question

对于库(.NET Standard 2.0)，我设计了一些看起来大致如下的类:

public class MyContext
{
    // wraps something important. 
    // It can be a native resource, a connection to an external system, you name it.
}

public abstract class Base
{
    public Base(MyContext context)
    {
        Context = context;
    }

    protected MyContext Context { get; private set; }

    // methods
}

public class C1 : Base
{
    public C1(MyContext context, string x)
        : base(context)
    {
        // do something with x
    }

    // methods
}

public class C2 : Base
{
    public C2(MyContext context, long k, IEnumerable<C1> list)
        : base(context)
    {
        // do something with the list of C1s.
    }

    // methods
}

public class C3 : Base
{
    public C3(MyContext context, int y, double z)
        : base(context)
    {
        // do something with y and z.
    }

    public void DoSomething()
    {
        var something = new C2(this.Context, 2036854775807, new[]
            {
            new C1(this.Context, "blah"),
            new C1(this.Context, "blahblah"),
            new C1(this.Context, "blahblahblah"),
            }
            );
    }

    // other methods
}

// other similar classes

之所以批评这些类，是因为每个构造函数都需要使用“MyContext”参数。
有人说这会使代码困惑。
我说过需要参数来传播上下文，例如当您调用C3的DoSomething方法时，所包含的C1和C2实例都共享相同的上下文。
一种可能的替代方法是将参数定义为 Base而不是 MyContext，例如:

public abstract class Base
{
    public Base(Base b) // LOOKS like a copy constructor, but it isn't!
    {
        Context = b.Context;
    }

    protected MyContext Context { get; private set; }

    // methods
}

public class C1 : Base
{
    public C1(Base b, string x)
        : base(b)
    {
        // do something with x
    }

    // methods
}

public class C2 : Base
{
    public C2(Base b, long k, IEnumerable<C1> list)
        : base(b)
    {
        // do something with the list of C1s.
    }

    // methods
}

public class C3 : Base
{
    public C3(Base b, int y, double z)
        : base(b)
    {
    }

    public void DoSomething()
    {
        var something = new C2(this, 2036854775807, new[]
            {
            new C1(this, "blah"),
            new C1(this, "blahblah"),
            new C1(this, "blahblahblah"),
            }
            );
    }

    // other methods
}

// other similar classes

现在，您必须传递的参数更短了，但仍然引起了人们的注意。
(而且我不太喜欢它，因为从逻辑上讲C1/C2/C3/etc对象不需要 Base，它需要 MyContext。更不用说那个构造函数看似是复制构造函数，但事实并非如此!哦! ，现在该如何在 Base派生的类之外初始化C1，C2或C3，因为它们所有人都需要 Base，而 Base是抽象的呢？我需要在某个地方“引导”系统...我想所有类都可能具有两个构造函数，一个带有Base，一个带有 MyContext ...，但是每个类都有两个构造函数，对于将来的维护者来说可能是一场噩梦...)。
有人说:“为什么不像Project X那样将 MyContext变成单例呢？”。
Project X具有类似的类结构，但是“感谢”单例，类没有 MyContext参数:它们“可以正常工作”。这是魔法!
我不想使用单例(或通常使用静态数据)，因为:

单例实际上是全局变量，全局变量是一种不好的编程习惯。我使用了全局变量很多次，很多次我后悔自己的决定，所以现在我更愿意避免使用全局变量。

带有单例的

，类共享一个上下文，但只能共享一个上下文:您不能具有MULTIPLE上下文。我发现对于一个可供公司中未指定数目的人员使用的库来说，这太过局限了。

有人说，我们不应过于固守“学术理论”，对“好的”和“不好的”编程实践无用的观念，也不应以抽象的“原理”为名过度改造类。
有人说，我们不应该陷入“绕过巨大的上下文对象”的陷阱。
有人说YAGNI:他们很确定99％的用法将只涉及一种上下文。
我不想通过不允许他们的用例来激怒那1％的人，但是我不想用难以使用的类来挫败其他99％的人。
所以我想了一种吃蛋糕的方法。
例如: MyContext是具体的，但它本身也具有静态实例。所有类(Base，C1，C2，C3等)都有两个构造函数:一个构造函数带有 MyContext具体参数，另一个没有该构造函数(它从静态 MyContext.GlobalInstance读取)。
我喜欢它，但同时又不喜欢，因为它再次需要为每个类维护两个构造函数，而且恐怕它太容易出错(只使用一次不正确的重载和整个过程)结构崩溃，您只能在运行时才能找到它)。
因此，暂时不要考虑“静态和非静态”的想法。
我试图想象这样的事情:

public abstract class Base
{
    public Base(MyContext context)
    {
        Context = context;
    }

    protected MyContext Context { get; private set; }


    public T Make<T>(params object[] args) where T : Base
    {
        object[] arrayWithTheContext = new[] { this.Context };
        T instance = (T)Activator.CreateInstance(typeof(T),
            arrayWithTheContext.Concat(args).ToArray());
        return instance;
    }

    // other methods
}

public class C1 : Base
{
    public C1(MyContext context, string x)
        : base(context)
    {
        // do something with x
    }

    // methods
}

public class C2 : Base
{
    public C2(MyContext context, long k, IEnumerable<C1> list)
        : base(context)
    {
        // do something with the list of C1s.
    }

    // methods
}

public class C3 : Base
{
    public C3(MyContext context, int y, double z)
        : base(context)
    {
        // do something with y and z.
    }

    public void DoSomething()
    {
        var something = Make<C2>(2036854775807, new[]
            {
            Make<C1>("blah"),
            Make<C1>("blahblah"),
            Make<C1>("blahblahblah"),
            }
            );
    }

    // other methods
}

// other similar classes

对 Make的调用看起来更好，但它们更容易出错，因为 Make的签名不是强类型的。我的目标是简化为用户做的事情。如果我打开一个括号并且Intellisense向我提出了...一系列 System.Object，我将非常沮丧。我可以传递不正确的参数，而且只能在运行时才能找到(由于旧的.NET Framework 2.0很好，我希望忘记 System.Object的数组...)
所以呢？如果工厂为每个Base派生的类提供专用的，强类型方法，则该工厂是类型安全的，但看到它(以及违反开放式关闭原则的教科书)可能也很“丑陋”。是的，“原理” ， 再次):

public class KnowItAllFactory
{
    private MyContext _context;

    public KnowItAllFactory(MyContext context) { _context = context; }

    public C1 MakeC1(string x) { return new C1(_context, x); }
    public C2 MakeC2(long k, IEnumerable<C1> list) { return new C2(_context, k, list); }
    public C3 MakeC3(int y, double z) { return new C3(_context, y, z); }
    // and so on
}

public abstract class Base
{
    public Base(MyContext context)
    {
        Factory = new KnowItAllFactory(context);
    }

    protected MyContext Context { get; private set; }
    protected KnowItAllFactory Factory { get; private set; }

    // other methods
}

public class C1 : Base
{
    public C1(MyContext context, string x)
        : base(context)
    {
        // do something with x
    }

    // methods
}

public class C2 : Base
{
    public C2(MyContext context, long k, IEnumerable<C1> list)
        : base(context)
    {
        // do something with the list of C1s.
    }

    // methods
}

public class C3 : Base
{
    public C3(MyContext context, int y, double z)
        : base(context)
    {
        // do something with y and z.
    }

    public void DoSomething()
    {
        var something = Factory.MakeC2(2036854775807, new[]
            {
            Factory.MakeC1("blah"),
            Factory.MakeC1("blahblah"),
            Factory.MakeC1("blahblahblah"),
            }
            );
    }

    // other methods
}

// other similar classes

编辑(在评论后):我忘了提到，是的，有人建议我使用像“Project Y”中那样的DI/IoC框架。但是显然“Project Y”仅使用它来决定是否需要 MyConcreteSomething时实例化 MyMockSomething或 ISomething(由于这个原因，请考虑对这个问题进行模拟和单元测试，因为原因)，并且它绕过DI/IOC框架对象我绕过我的上下文...

Answer 1

在OP中列出的替代方案中，原始的是最好的。正如Zen of Python所述，显式优于隐式。
使用Singleton将使显式依赖项隐式化。那不会提高可用性。这使事情变得更加不清楚。它使API更加难以使用，因为API的用户在成功使用API​​之前还需要学习更多的知识(这与仅仅查看构造函数签名并提供使代码进行编译的参数相反)。
API是否需要使用更多的击键并不重要。在编程中，typing isn't a bottleneck。
通过构造函数传递MyContext只是普通的古老的Constructor Injection，即使它是concrete dependency。但是，不要让依赖注入(inject)(DI)行话骗了您。你don't need a DI Container to use those patterns。
您可能会考虑的一项改进是应用Interface Segregation Principle(ISP)。基类是否需要整个MyContext对象？是否可以仅使用MyContext API的子集来实现其方法？
基类是否根本需要MyContext，还是仅出于派生类的目的而存在？
您甚至需要基础类(class)吗？
以我的经验，您总是可以提出一个不使用继承的更好的设计。我不知道在这种情况下会发生什么，但是类似以下的情况呢？

public class C1
{
    public C1(MyContext context, string x)
    {
        // Save context and x in class fields for later use
    }

    // methods
}

public class C2
{
    public C2(MyContext context, long k, IEnumerable<C1> list)
    {
        // Save context, k, and the list of C1s in class fields for later use
    }

    // methods
}

public class C3
{
    public C3(MyContext context, int y, double z)
    {
        Context = contex;
        // do something with y and z.
    }

    public MyContext Context { get; }

    public void DoSomething()
    {
        var something = new C2(this.Context, 2036854775807, new[]
            {
            new C1(this.Context, "blah"),
            new C1(this.Context, "blahblah"),
            new C1(this.Context, "blahblahblah"),
            }
            );
    }

    // other methods
}

在重用 MyContext的单个实例时，是否具有基类没有什么区别。即使这三个类没有共同的父类(super class)型，您仍然可以执行此操作。