Question

我有一个静态类，它将包含各种实用程序，为了简化起见，我添加了客户和订单：

public static MyUtilityClass()
{
   public static readonly AnExpensiveObject ExpensiveObject = null; 
   public static Customers Customers;
   public static Orders Orders;

     static MyUtilityClass()
     {
        if (ExpensiveObject == null)
        { 
            ExpensiveObject = //Expensive operation
        }
     }   
}

在上面的代码中，AnExpesiveObject ExpensiveObject是Customers和Orders将使用的实用程序类的属性。

我已经宣布过这样的客户：

public class Customers
{
     public void SomeMethod()
     {
         var x = MyUtilityClass.ExpensiveObject; 
     }
}

理论如果我想做什么：

创建一个具有子类作为属性的静态类，以便我可以编写简洁的代码，如：

Utilities.Customers.GetCustomerById(50);
让这些实用程序类能够访问父类中的属性，这里因为父类是静态的，所以我只是直接访问它的属性而没有任何继承模型。这是正确的做法吗？
最后，Customers（该类）是非静态编码的，所以我必须在MyUtilityClass（）中创建它的新实例，还是因为它是MyUtilityClass的静态属性，这不是必需的？

Answer 1

冒着回答过于宽泛的问题的风险，我会给出我认为正确，简短的回答：不，这不是你做任何事情的正确方法。< / p>

不幸的是，当您询问继承时，您的代码示例中没有任何内容显示继承的任何使用。所以你不可能理解你的意思。

然而，更有问题的是你的第三点提出的问题：

最后，Customers（该类）是非静态编码的，所以我必须在MyUtilityClass（）中创建它的新实例，还是因为它是MyUtilityClass的静态属性，这不是必需的？

你必须提出这个问题的事实强烈暗示这个设计存在根本性的缺陷。

特别是，问题我会问你：什么类型的班级是Customers？也就是说，你的程序有多个实例才有意义吗？

这个问题很重要，因为两个可能的答案都会导致后续问题，这两个问题都指出提议的设计是错误的：

可能的答案＃1：“不，一次只能有一个Customers个对象”。在这种情况下，将类实现为单例更有意义，这意味着访问者应该是例如Instance类本身中的Customers属性，而不是单独的“实用程序”类中的属性。
可能的答案＃2：“是的，在执行此程序期间可能有Customers个对象的多个实例”。在这种情况下，提出的问题是哪个实例成为“实用程序”类中的“特殊”实例，为什么？此外，是否有不止一个实例可以保持这种特殊地位？为什么，或为什么不呢？

希望上面的第一个答案是正确的，在这种情况下路径是明确的：使用单例模式而不是这个全能的“实用程序”类。

如果上面的第二个答案是正确的，那么我可以合理地相信你提出的设计是不正确的。不幸的是，要说什么设计是正确的将会更加困难，并且需要更多细节，使得问题本身对于StackOverflow而言过于宽泛。

Answer 2

它按照我的预期工作，并且易于重复使用，所以我将回答这个问题。

这是静态类实现的正确架构吗？

2 个答案: