1
14
静态方法和其他成员本身并不是不好的实践。只是,不太熟悉OO概念的人倾向于在代码中到处乱丢静态方法、属性和字段,而不知道结果是什么。 通常,对于配置设置、助手和实用程序类、抽象工厂、单例等,拥有静态成员是完全可以接受的。 |
2
2
在C中,你将很难反对好的OO设计,因为你无法摆脱OO。它不像C++那样可以将结构化与OO编程混合和匹配——这些类型的参数经常出现的领域。 类上的静态成员是OO。微软生成的设置也是如此,因为代码生成为它们创建OO封装,或者至少在它们周围创建一个“对象容器”。所以它们永远都不是全局变量,因为它不存在于C中——它们只是类中的静态成员——没有非OO的。 如果参数是关于singleton和static成员的,那么它将一个oo参数与另一个oo参数进行比较。 还有哲学观点和实践观点。在大多数领域中,理想的哲学观除了学术研究外,没有真正的价值。现实世界需要真正的解决方案,混合的解决方案。 |
3
1
公共静态类或成员并不总是一个坏主意(即使它不是完全OO)。许多优秀的OO设计使用公共静态成员来处理诸如记录器或设置之类的事情(如您所指出的)。一个很好的例子就是 Static Gateway . |
4
1
全局变量,比如goto,是所有初学者都应该避免的,但是对于高级程序员非常有用。 我要说的是,如果你不自信,你没有一个具体的,合理的理由为什么它是一个很好的应用,不要使用它们。在返回全局变量之前掌握OO。 |
5
0
设置机制…隐马尔可夫模型。。。 我主要把这些看作是环境的一部分。像操作系统或时间,但对于应用程序。它们并不像在init期间声明的那样是真正的“变量”。 但是,您可以将一个对象包装在它们周围,并且只能通过该对象访问它们,而不是在运行时需要时读取它们。我还没有测试过它,但它可能是一个性能清洗(如果你没有很好的内存管理,那么对原始数据的读取是负面的)。 最终,随着应用程序的成熟,像这样的事情最终会让对象围绕在它们周围。我的规则是,每当我开始思考,“不,这太简单了,太原子化了,不需要一个物体……”这就是我把它变成物体的线索。 |
Robert King · Unity C#语法问题-转换位置 1 年前 |
JBryanB · 如何从基本抽象类访问类属性 1 年前 |
law · 检查答案按钮的输入字符串格式不正确 2 年前 |
i_sniff_ket · 在unity之外使用unity类 2 年前 |