尝试让main/form1以外的类互相交互是不好的形式？

Question

我正在尝试学习在我的代码中使用类的正确方法,当它不像一组客户,从动物继承的狗等明显的东西时.

我已经折断的大段代码为"特色",例如Installer.cs,Downloader.cs,UiManager.cs.我可以找到让这些类与彼此的属性和方法相互作用的唯一方法是使它们都是静态的,我在另一个问题中被告知是错误的方法.

所以我的问题是三件事之一:

1. 有一种方法可以让课程互相交流,我还不明白.

2. 类不应该试图相互交谈,而是执行一次性操作然后返回一些东西,然后main/form1主类可以使用它来传递到另一个类中进行一次性操作.

3. 类实际上只对大量实例有用,而且我需要了解一些其他结构,以便从主类中抽象出大块的功能.

我能找到的所有教程和我观看的讲座似乎只告诉你课程是如何工作的,而不是告诉你何时以及如何在真实产品中使用它们.

编辑 - 一个更具体的例子:

假设我有一个对整个应用程序至关重要的字符串,需要每个类都可能看到和/或修改.如何在代码中移动该信息,而无需将所有内容都放在一个类中或使其静态化？

我看不到让字符串存在Form1而不使其成为静态的方法(因为所有表单事件和函数都需要能够看到它以将其传递给类).

我无法看到一种方法将字符串放入另一个类而不必使字符串和整个类静态,所以其他类可以看到它.

也许我实际上没有关于实例化类,并使对象相互交互的东西.

Answer 1

我认为你所有的直觉都是对的。

1. 不，没有。静态或实例。

2. 这是一种设计选择（而且有很多选择）。我是一个务实的人，所以我认为生成 spaguethi 代码的设计模式是一个糟糕的设计模式选择。但是一个项目的糟糕设计模式对于另一个项目可能是一个好的设计模式。尝试阅读《Head First Design Pattern》一书。

3. 是的，有接口和抽象类。

还有一些想法：

我认为不必避免使用静态方法或类。必须避免的是错误使用静态方法或类，就像错误使用语言中的所有内容一样。但是很难定义什么是静态的错误使用，并且因为静态方法或类特别危险，所以人们喜欢说完全避免使用 static 关键字。除非您结束应用程序，否则静态方法将保留在内存中，因此如果您不在静态方法内释放连接，您将度过非常糟糕的一天。

我有一个实用程序项目，在实用程序项目中我有一个数据类。数据类提供对数据库的访问。这是一个静态类。为什么？

首先，它是静态的，因为连接字符串来自 webconfig。所以我有一个静态构造函数（在应用程序启动并提到类时运行一次），它读取 webconfig 并将字符串存储在静态私有成员变量中。我认为这比每天读取 webconfig 文件并创建一个作用域变量 100 亿次要好得多。这些方法是静态的，因为它们足够简单，这意味着它们不需要大量配置即可工作，只需要几个参数，并且仅在数据访问项目中使用。我的所有网站用户都使用该方法的相同实例（静态方法），但每个人都使用具有不同参数的静态方法，因此他们从中得到不同的响应（他们共享管道，但他们喝不同的水）。只需要在方法内部格外小心地清理所有内容（处置每个作用域实例），因为如果不这样做，它们将保留在内存中。最后，我的业务是关于数据操作的，非静态数据类意味着比静态数据类使用更多的内存（两种模式中的 CPU 使用率几乎相同）。

public abstract class Data
{

    [...]

    static Data()
    {
        #if DEBUG
            _Connection = ConfigurationManager.AppSettings["debug"];
        #endif

        #if RELEASE
            _Connection = ConfigurationManager.AppSettings["release"];
        #endif

        [...]
    }

    [...]

}

归根结底，我在以下情况下使用静态：

1. 如果它足够简单（我可以控制各个方面）；
2. 如果它足够小（我使用扩展方法进行验证，并且它们是静态的）并且；
3. 如果是重度使用的话。

除此之外，我使用图层来组织我的项目（poco + 工厂模式）。我有一个实用程序项目，然后是实体模型项目，然后是访问项目，然后是业务逻辑项目，然后是网站、api、管理器等。实用程序项目中的类不会相互交互，但实体模型项目中的类会相互交互（一个类可以在其中包含另一个类的实例）。实体模型项目不与实用程序项目交互，因为它们具有相同的级别，它们在访问项目中的另一个级别中相互交互，但在数据操作项目中更直观。