在java中重构实用程序类（静态类）的最佳方法是什么_Java_Oop_Design Patterns_Immutability

在java中重构实用程序类（静态类）的最佳方法是什么

java oop design-patterns

在java中重构实用程序类（静态类）的最佳方法是什么,java,oop,design-patterns,immutability,Java,Oop,Design Patterns,Immutability,我正在考虑重构一些实用程序类（静态类）。静态类很难测试，主要问题是它的生成我们的代码紧密耦合，有很多依赖性。用于重构的最佳设计模式是什么？我考虑过使用构建器的不可变对象，但我不确定将此代码视为我要重构的1 public class UtilTest { public static boolean isEligibleItem(Item item){ if(isCondition1(item)){ return isConditio

我正在考虑重构一些实用程序类（静态类）。静态类很难测试，主要问题是它的生成我们的代码紧密耦合，有很多依赖性。用于重构的最佳设计模式是什么？我考虑过使用构建器的不可变对象，但我不确定

将此代码视为我要重构的1

public class UtilTest {

    public static boolean  isEligibleItem(Item item){
         if(isCondition1(item)){
             return isCondition2(item);
         }

         return false;
    }

    public static  boolean  isCondition1(Item item){
        //go to service that go to the data base  
        return false;
    }

    public static boolean  isCondition2(Item item){
        //go to service that go to the data base  
        return false;
    }
}

如果我想测试我的isEligibleItem（）方法，我需要模拟去db的2个方法。

我做不到，因为它们是静态的。我希望避免使用Powermock

将其简单转换为更易于测试的设置：

public class UtilTest {

    private final MyDatabaseService service;

    public UtilTest(MyDatabaseService service) {
       this.service = service;
    }

    public boolean  isEligibleItem(Item item){
         if(isCondition1(item)){
             return isCondition2(item);
         }
         return false;
    }

    public boolean isCondition1(Item item){
        this.service.goToDataBase();
        return false;
    }

    public boolean isCondition2(Item item){
        this.service.goToDataBase2();
        return false;
    }
}

这并不能消除所有问题，但这只是一个开始，您可以使用模拟数据库服务测试您的类

如果您想进一步推进，可以声明一个接口，其中包含您想要公开的所有方法（您可能还想重命名该类…），并使

UtilTest

实现它。所有使用

UtilTest

的代码都应该重写为使用接口，然后您可以完全直接地模拟

UtilTest

。这是否值得，在很大程度上取决于实际的

UtilTest

有多复杂。如果它执行的任务相对简单，你可能会认为它比它的价值更麻烦。但是，如果其中有一些繁重的处理，您肯定希望使其易于模仿。

实用程序类反模式人们说静态方法很难测试的原因更多的是它如何将不相关的类紧密地结合在一起，它降低了内聚性，并引入了不可见的副作用。这三件事比一些单元测试挥手抱怨要重要得多
测试交互作用它更多的是测试与其他代码的交互，而不是测试
静态方法本身。这就是Java真正需要函数作为第一类对象的地方在大多数情况下，只有静态方法的类肯定是一种代码味道。也有例外，但这种反模式往往被非面向对象语言的初学者和老手滥用规则的例外-不可变异常主要是标记为final 的类中可能被认为缺少的东西，比如String 是不可变的拥有一个具有通用的静态方法的Strings 类并不坏，因为String 是不可变的（没有副作用），并且您不能向String 类添加任何内容，因此您没有太多的选择。同样适用于Integer 等，Guava 具有这种命名约定，它适用于这些不可变对象副作用静态方法往往会引入很多副作用。以某种不透明的方式获取对象并操纵该对象的事情是不好的，更糟糕的是，当他们根据传入的实例查找其他对象并操纵它们时，它们会混淆正在发生的事情，并且是紧密耦合和低内聚性的高内聚紧密内聚不像耦合那样被谈论得那么多，但它同样重要。它们是同一枚硬币的两面，忽视其中一方会导致另一方因此而受苦这些静态方法应该在它们作为参数的类上，它们与这些类紧密耦合。在这种情况下，为什么它们不在项类中一旦您添加另一个采用SomeOtherItem 的static 方法，您就间接地将不相关的类耦合在一起了纠正这种情况的最简单方法是将事物移到更靠近它们所属的位置（在本例中为项类）工厂/提供者模式如果您有真正属于常规的内容，或者由于最终或其他原因而无法添加到类中的内容，那么使用接口和提供程序模式是使用工厂生成提供程序实例的最佳方法然后，您可以使用Guice 之类的工具来注入您需要的任何实现，具体取决于它是否是测试甚至还有一种混合的实用程序模式，可以从提供者中注入实现，这将为您提供静态方法的便利，以及不使用它的灵活性和可维护性。也许一个示例会有用。你能展示给我们看吗？有时候你想模仿他们，这样做可能会很麻烦。你能展示一些代码吗？如果不知道代码在做什么，就很难做出回应。如果没有具体的代码来讨论，这个问题就不清楚或太广泛。如果您确实有具体的代码要讨论，那么您最好继续提问。与流行的观点相反，静态方法很容易测试。另一方面，调用静态方法的方法…不是。是的，这是一个良好的开端（依赖注入）。但是我们的utils类依赖于其他服务，我不希望我的构造函数太大。这就是为什么我会想到immutable和builder，因为我可以构建我想要的，然后运行它并进行测试it@MosheTsabari看起来这些实用程序类根本不是实用程序类。实用程序类处理非业务逻辑类型代码。如果您是协同服务，那么它很可能不是一个实用程序类，应该被烘焙到处理这些服务的对象中。@JoseMartinez或它们应该被转换为更高级别的服务。这就是我正在处理的问题。一些开发人员希望创建方法并使用它们，而无需创建