静态类认为是不好的做法？ [英] static classes considered bad practice?

问题描述

我在几天前读了一篇文章静态课程被认为是不良实践。大部分时间我使用静态分类为效用函数。所以静态类被认为是坏代码这是正确的，如果是这样，出于什么原因？

解决方案

静态类似乎是不灵活的。你不能接口它们，你不能覆盖它们，你无法控制它们的构造时间，你不能在泛型中很好地使用它们。你不能真正对它们进行版本化。



静态的使用肯定有用：常数值很好。您可以在静态块中建立数据库连接或打开任何文件资源



所以一般情况下，不坏的做法但明智地使用它们。



-KR

我同意我之前的演讲者 - 明智地使用它们。



让我们看看反过来：什么时候创建一个类是合适的？

请将class理解为对象的构造计划。将静态类理解为无类或与类相反。

将对象理解为具有自身功能的Data togehter的一个单元来操纵它。换句话说：对象具有状态，可以更改它。另一个基本概念：你可以拥有同一类的几个不同的对象。



这就是你需要一个类的时候：你想要那个类的几个对象，以及对象应具有不同的状态。



回答这个问题：如果你有功能但没有数据存储在几个陈述的对象中，那么你就没有需要一个类。



作为声明对象的示例，采用FileInfo-class：每个FileInfo包含自己的数据（有关文件的信息），以及它自己的操作功能。因为光盘上有很多文件，所以需要创建许多FileoInfos - 需要类概念。



作为功能的示例，不相关使用System.Math-static-class获取数据：它没有状态：创建几个Math对象根本就没有意义。与FileInfo不同，每个Math-Function都通过参数获取所需的数据并返回结果 - 没有状态数据存储。



所以我看到你的静态 - 用法完全正确：静态类是存储实用程序功能。当然你仍然可以做错事，但一般来说，实用程序是一个关注点，它在静态类中是有意义的。



另一种方式，即创建每次一个实用对象，每当你需要一个函数并在之后销毁它时 - 我称之为：brain-f ***。

一个对象应该有一个状态，并且应该设计几次改变它。这就是课堂概念的发明。



将类概念应用于不需要的关注点是一种错误的设计。 / BLOCKQUOTE>

i read an article "Static classes considered bad practice" couple day ago. most of time i use static classed for utility function. so static class are consider bad code Is this correct, and if so, for what reasons?

解决方案

Statics tend to be inflexible. You can't interface them, you can't override them, you can't control the timing of their construction, you can't use them well in generics. You can't really version them.

There are certainly uses of statics: constant values work great. You can make database connection or open any file resource in static block

So in general, not bad practice but use them wisely.

-KR

i agree with my previous speaker - "use them wisely".

Lets have a look the other way round: when is it appropriate to create a class?
please understand "class" as "construction-plan of objects". Understand "static class" as no-class or the opposite of class.
And understand object as a unit of Data togehter with its own functionality, to manipulate it. Other words: An object has a state, and can change it. Another basic concept: you can have several different objects of the same class.

So that is when you need a class: you want several objects of that class, and the object shall have different states.

To answer the question: if you have functionality, but no data, which is to store in several stated objects, then you don't need a class.

As sample for stated objects take FileInfo-class: each FileInfo contains its own data (information about a file), and its own functionality to manipulate it. And because there are many files on disc, it is required, that one can create many FileoInfos - the class-concept is required.

As sample for functionality, not associated to own data take the System.Math-static-class: It has no state: creating several Math-objects would make no sense at all. In difference to FileInfo each Math-Function gets the data it needs by arguments and returns a result - no state-data is to store.

so i see your static-usage as propably completely right: A static class is to store utility-functions. Of course you can still do something wrong, but in general "utility" are a concern which is meaningful placed within a static class.

The other way round, namely create an "utility-object" each time, whenever you need a function and destroy it afterwards would be - i call it: "brain-f***".
An object should have a state, and should be designed to change it several time. That is what the class-concept was invented for.

It is a mis-design, to apply the class-concepts to concerns, which do not need that.

这篇关于静态类认为是不好的做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！