尝试让main / form1以外的类互相交互是不好的forms？
我正在尝试学习在我的代码中使用类的正确方法，当它不像一组客户，从动物inheritance的狗等明显的东西时。
我已将大部分代码分解为“function”，例如Installer.cs ， Downloader.cs ， UiManager.cs 。 我能找到让这些类与彼此的属性和方法相互作用的唯一方法就是使它们都是静态的，我在另一个问题中被告知是错误的方法。
所以我的问题是三件事之一：
-
有一种方法可以让课程互相交流，我还不明白。
-
类不应该尝试相互通信，而是执行一次性操作，然后将某些内容返回给
main/form1，然后主类可以使用它来传递到另一个类中进行一次性操作。 -
类实际上只对大量实例有用，而且我需要了解一些其他结构，以便从主类中抽象出大块的function。
我能找到的所有教程和我观看的讲座似乎只告诉你课程是如何工作的 ，而不是告诉你何时以及如何在真实产品中使用它们。
编辑 – 一个更具体的例子：
假设我有一个对整个应用程序至关重要的字符串，并且需要每个类都可能看到和/或修改。 如何在代码中移动该信息，而无需将所有内容都放在一个类中或使其静态化？
我没有办法让这个字符串在Form1生存而不使其成为静态（因为所有表单事件和函数都需要能够看到它以将其传递给类）。
我无法看到一种方法将字符串放入另一个类而不必使字符串和整个类静态，所以其他类可以看到它。
也许我实际上没有关于实例化类，并使对象相互交互的东西。
我认为你所有的直觉都是正确的。
-
不，没有。 静态或实例。
-
这是一个设计选择（那里有很多）。 我是务实的，所以我认为一种设计模式会产生spaguethi代码，这是一种糟糕的设计模式选择。 但是项目的糟糕设计模式对于另一个项目来说可能是一个很好的设计模式。 尝试阅读Head First Design Pattern一书。
-
是的，有接口和抽象类。
还有一些想法：
我不认为必须避免使用静态方法或类。 必须避免的是错过使用静态方法或类，比如错过使用语言中的所有内容。 但很难定义什么是静态的错过使用，并且因为静态方法或类特别危险，人们喜欢说要完全避免使用static关键字。 除非您结束应用程序，否则静态方法将在内存中，因此如果您不在静态方法中部署连接，那么您将度过非常糟糕的一天。
我有一个实用程序项目，在实用程序项目中我有一个数据类。 数据类提供对数据库的访问。 这是一个静态类。 为什么？
好吧，首先，它是静态的，因为连接字符串来自webconfig。 所以我有一个静态构造函数（在应用程序启动并且提到类时运行一次），它读取webconfig并将字符串存储在静态私有成员变量中。 我认为这比阅读webconfig文件并创建一个范围变量10 bilion times day要好得多。 这些方法是静态的，因为它们很简单，这意味着它们不需要很多配置就可以工作，它们只需要一些参数，它们只在数据访问项目中使用。 我的所有网站用户都使用相同的方法实例（静态方法），但每个人都使用不同参数的静态方法，因此他们得到不同的响应（他们共享管道，但他们喝不同的水）。 在方法中只需要额外注意清理所有内容（处理每个作用域实例），因为如果不这样做，它们将留在内存中。 最后，我的业务是关于数据操作，非静态数据类意味着比静态数据类更多的内存使用（两种模式中的cpu使用几乎相同）。
public abstract class Data { [...] static Data() { #if DEBUG _Connection = ConfigurationManager.AppSettings["debug"]; #endif #if RELEASE _Connection = ConfigurationManager.AppSettings["release"]; #endif [...] } [...] }
在一天结束时我使用静态时：
- 如果它足够简单（我可以控制每个方面）;
- 如果它足够小（我使用扩展方法进行validation，它们是静态的）和;
- 如果它很重。
除此之外，我使用图层来组织我的项目（poco +工厂模式）。 我有一个实用工程项目，然后是实体模型项目，然后是访问项目，然后是商业逻辑项目，然后是网站，api，经理等等。 实用程序项目中的类不会相互交互，但实体模型项目中的类会这样做（一个类可以在其中包含另一个类的实例）。 实体模型项目不与实用程序项目交互，因为它们具有相同的级别，它们在访问项目中在另一个级别中相互交互，但它在数据操作项目中更直观。
当类有引用时，类会互相通话，以便A将消息传递给B，A需要对B的引用（实例或静态引用）
类可以相互通信，也可以将信息返回给控制整个过程的另一个类（这实际上是一种设计模式）
要从主类（或任何类）中抽象信息，您需要具有接口和抽象类
来自四人帮的设计模式书在这种情况下必须阅读。 除此之外还要记住的是设计的简单性，有时候试图适应设计模式，因为最终可能会产生更多的spaguethi代码。 根据经验，总是尝试从逻辑中分离出演示function，并将课程视为与彼此交谈并执行工作的人（这有点奇怪我知道，但有时它有助于我这样思考）