关于工具类Utils的规范，以及引发的多个思考

今天补基础时候看见：

static多用于工具类

好像很久很久之前team leader和我讲过把巴拉巴拉抽成工具类会好一些，现在想想其实自己写了很多"工具类",但是都么有按照规范来。今天索性写个博客规范一下。

工具类是为了提供一些通用的、某一非业务领域内的公共方法，不需要配套的成员变量，仅仅是作为工具方法被使用。所以将它做成static静态方法最合适，不需要实例化，能够获取到方法的定义并调用就行。

一般直接通过类名调用，比如Math.pow 落实到具体项目里的话，建议另外建一个叫做Utils 

文件夹。   

如何保证一个工具类不能被实例化呢？私有化private其构造器

public class UtilsClass {  
      private UtilsClass(){  
         throw new Error("不要实例化我！");  
      }  
} 

至于不这样做行不行，当然是可以的，正常人使用工具类也不会想去实例化。写这个主要目的是规范化，并且告诉未来的自己，这他🐎是个工具类。

1.工具类定义为final class，考虑到工具类应该不能被继承

另外，在Java中

final修饰方法，目的是明确禁止子类覆盖这个方法
final修饰类，禁止继承
 

在C#中是如何实现这两个需求的呢？

需求1：编译器常量

const修饰常量，必须能在编译时用于计算。常量总是静态的但不必(实际上,是不允许)在常量声明中包含修饰符static

需求2：运行期常量

readonly关键字
有时可能需要一些变量,其值不应改变,但在运行之前其值是未知的。 
C#为这种情形提供了另一种类型的变量:只读字段
 

另外，在C#中

sealed修饰方法，目的是明确禁止子类覆盖这个方法
sealed修饰类，禁止继承
 

2.工具类的命名应该用Util结尾，例如LogUtil

3.工具类的构造方法应该首选是private的，同时工具类的工具方法为static的

4.工具类使用单例模式，或者static初始化某个单例。这个规范是因工具的不同而不同的，例如我要写一个gson的工具类，不应该在每个方法里都new Gson()再进行操作，如果一个类大量调用GsonUtil，那就会大量创建gson对象。

那么问题来了,一定要不能通过实例化来使用工具类吗？不是！

在ABP框架里，我看见了同事写道 

 public class PrintDataFactory : ITransientDependency

    {
        ........
    }

编写工具类俩种方式：

• 静态类式：

  1. 工具方法设计为static方法
  2. 工具 类所有构造方法都设计为private修饰
  3. 工具类本身以abstract修饰（目的就是只能用类调用方法,不能实例化)

• 单例模式:

  1. 工具方法都设为非static方法
  2. 将工具类设计为单列模式
  3. 注意这种方式需要获取工具类对象(实例化)才能调用方法

• 静态类优势：

  • 静态类不用引用就能调用，而单例需要有对象的引用，因此节约资源（我觉得这个影响微乎其微，可以忽略）
  • 静态类方便，随处可用；而单例必须有引用，需要注入或者new（是有点麻烦，我上次写静态类也是因为这个原因）

• 单件类优势：

  • 单例模式的类是普通的类，它具有面向对象的特性，方便扩展
  • 对于有配置的工具类，可以轻松的创建多个不同配置的单例对象（想起我主导的另一个项目就存在5-6个redis数据源，如果使用静态类就是灾难）

• 结论：

  • 如果没有配置信息的工具类，当然是静态类好，随处调用，不需引用爽得不要不要的。比如Math.abs()，如果写个单例，可能全世界都要笑话你了。
  • 如果有配置信息的工具类，最好还是使用单例模式吧，这样以后如果有多个数据源，你会感谢你自己。

• 区别
  我在静态方法里使用的单例模式，不是指的是我的工具类作为单例，而是第三方的类。

重要的思考！~

ABP里面为啥要继承ITransientDependency？你设置构造器为public，不是一样可以使用实例化对象吗？

查文档！直到我看见了仓储部分的文档。

 一样的道理，继承自ITransientDependency接口，所以工具类的对象只有在需要注入的时候，才会由IOC容器自动创建新实例。

好 问题什么是IOC容器？

 再次思考，这就是为什么在ABP中要先定义接口，再实现接口，因为我发现其实在应用层不实现接口也不会出现什么问题，但是一定要遵守框架的规范，定义接口，再继承。核心思想就是 解耦你声明一个xxx类的父类接口，然后只引用这个接口，就体现解耦了。