尝试让 main/form1 以外的类相互交互是不好的形式吗? [英] Is it bad form to try and have classes other than main/form1 interact with each other?

问题描述

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

I'm trying to learn the correct way to use classes in my code, when it's not something obvious like a set of customers, dogs inheriting from animals, etc.

我已将大部分代码分解为功能"，例如 Installer.cs、Downloader.cs、UiManager.cs.我可以找到让这些类与彼此的属性和方法交互的唯一方法是使它们全部为静态，我在另一个问题中被告知这是错误的方法.

I've broken off large sections of code into "features" such as Installer.cs, Downloader.cs, UiManager.cs. The only way I can find to have those classes interact with each others' properties and methods is to make them all static, which I've been told in another question is the wrong way to go.

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

So my problem is one of 3 things:

1. 有一种方法可以让班级之间相互交流，但我还不明白.

1. There is a way to make classes talk to each other that I just don't understand yet.

类不应该尝试相互交谈，而是执行一次性操作，然后将某些内容返回给 main/form1，然后主类可以使用它传递给另一个类一次性操作的类.

Classes should never try to talk to each other, but perform one-off actions and then return something back to main/form1, which the main class can then use to pass into another class for a one-off action.

类实际上只对创建大量实例有用，我需要完全了解其他一些结构，以便从主类中抽象出大量功能.

Classes are really only useful for making lots of instances, and there's some other structure entirely I need to learn about for abstracting large chunks of functionality out from the main class.

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

All the tutorials I can find and lectures I watch seem to only tell you how classes work, but not when and how to use them in a real product.

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

EDIT - A more specific example:

假设我有一个字符串，它是整个应用程序的核心，每个类都可能需要查看和/或修改.我如何在代码中移动这些信息，而不是将所有内容都放在一个类中或使其成为静态?

Say I have one string that is central to the entire app, and needs to be seen and/or modified potentially by every class. How do I move that information around the code without either having everything in one class or making it static?

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

I can't see a way to let that string live in Form1 without making it static (because all the form events and functions would need to be able to see it to pass it to a class).

我看不出有什么方法可以将字符串放入另一个类，而不必使字符串和整个类保持静态，以便其他类可以看到它.

I can't see a way to put the string into another class without having to make the string and the whole class static, so other classes can see into it.

也许我在实际实例化类和使对象相互交互方面遗漏了一些东西.

Maybe there's something I'm missing about actually instantiating the classes, and making objects interact with each other.

推荐答案

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

I think all your intuitions are right.

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

1. No, there's not. Static or instance.

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

It's a design choice (and there's a lot out there). I'm a pragmatic, so I consider a design pattern that generates spaguethi code a bad design pattern choice. But a bad design pattern for a project can be a good design pattern for another project. Try to read the Head First Design Pattern book.

是的，有接口和抽象类.

Yes, there are interfaces and abstract classes.

还有一些想法:

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

I don't think the use of static methods or classes must be avoided. What must be avoided is the miss use of a static method or class, like the miss use of everything inside a language. But is very hard to define what's a miss use of a static, and because static methods or classes are particulary dangerous, people like to say to avoid the static keyword at all. A static method will be in memory unless you end your application, so if you don't dispose a connection inside a static method, you will have a very bad day.

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

I have a utility project, and inside the utility project I have a data class. The data class provides access to the database. It's a static class. Why?

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

Well, first of all, it is static because the connection string comes from the webconfig. So I have a static constructor (runs once when the application starts and the class is mentioned) who reads the webconfig and store the string in a static private member variable. I think it's a lot better than read the webconfig file and create a scoped variable 10 bilion times day. The methods are static because they are simple enough, meaning that they don't need a lot of configuration to work, they just need a few parameters and they are used only in the data access project. All my website users are using the same instance of the method (the static one), but everyone uses the static method with different parameters, so they get different responses from it (they share the pipe, but they drink different water). It's only necessary extra care inside the method to clean everything (dispose every scoped instance), because if you don't they will stay in memory. And finally, my bussiness is about data manipulation, a non static data class means a lot more memory usage than a static one (the cpu usage is almost the same in both patterns).

public abstract class Data
{

    [...]

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

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

        [...]
    }

    [...]

}

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

In the end of the day I use static when:

1. 如果它足够简单(我可以控制各个方面)；
2. 如果它足够小(我使用扩展方法进行验证，并且它们是静态的)并且；
3. 如果使用量很大.

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

Besides that, I use layers to organize my project (poco + factory pattern). I have a utility project, then a entity model project, then a access project, then a bussiness logic project, then a website, a api, a manager, and so on. The classes in the utility project don't interact each other, but the classes inside the entity model project do (a class can have a instance of another class inside it). The entity model project don't interact with the utility project because they have the same level, they interact each other in another level, in the access project, but it's more intuitive in a data manipulation project.

这篇关于尝试让 main/form1 以外的类相互交互是不好的形式吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！