oop - 违反 SRP、Demeter 法则等的影响

Question

我知道以下是一个主观问题，但您的指导方针确实有助于我追求干净、可测试的代码。

请考虑以下示例，我认为它违反了一系列设计原则。

public class OfferEligibilityCheckerServiceImpl implements OfferEligibilityCheckerService, Refreshable{

     private Map<String, OfferCriteria>  offerIdToOfferCriteriaMap;

     private OffersAccessorService offersAccessorService

     public OfferEligibilityCheckerServiceImpl (OffersAccessorService offersAccessorService ){
            this.offersAccessorService = offersAccessorService;
            initValidOfferIdSet();
     }

     protected void initOfferIdToOfferCriteriaMap(){
          offerIdToOfferCriteriaMap = offersAccessorService.get..Criteria();
     }

     //REAL BUSINESS LOGIC, i.e. this is why the service is used by clients!!
     @Override 
     public boolean isUserEligible(String offerId, UserInfo userInfo){
          offerCriteria = offerIdToOfferCriteriaMap.get(offerId);
          return offerCriteria.isEligible(userInfo); // let's not worry about NPE
     }


     // Gets invoked at regular intervals by some scheduler, say Spring.
     @Override // from Refreshable
     public void refresh(){ // ANOTHER responsibility
         initOfferIdToOfferCriteriaMap();
     }
}

我觉得上面的代码在很多层面上都是错误的，但我缺乏足够深入的知识来说服其他人它是平庸的/不可测试的。

据我所知，上述设计的问题在于它看起来可测试，因为某些部分可以替换，但它有点违反所有“可测试设计”准则。

我和其他人之间的对话。

1. 我:构造函数中的复杂逻辑。

   其他:不，我正在从构造函数中调用 protected 方法，如果您需要测试替身，可以覆盖该方法。

2. 我:违反得墨忒耳法则 - 要求确切的东西，而不是中介。

   其他:了解“代码到接口(interface)”的强大功能。我正在传递一个 serviceImpl，而构造函数需要一个服务。所以我总是可以在测试时进行替换，这样 serviceImpl 就不会在单元测试期间真正与 DAO/数据库对话。

3. 我:违反 SRP - 处理业务逻辑，处理让我在构建过程中得到我自己的东西，处理让我恢复精神。

   其他:没关系!我不想将这个类分成 3 个类，并承担安排它们/连接它们的开销。

4. 我:混合业务逻辑和对象构建逻辑。

   其他:我什至不明白你的意思。

问题 1)我说得对吗？

我可能没有指出正确的问题或没有以正确的方式表达它们。

如果您能列出我们在未来使用上述设计可能面临的问题，那就太好了。如果您能解决或验证我的第 1 点到第 4 点，那就更好了。

问题2:你会如何重新设计它(包括布线部分)？

Answer 1

这就是一般设计模式和原则的问题 - 过分关注它们会使我们远离编写代码/生产软件的真正目的......这是为了解决业务问题。

首先，让我告诉你为什么这段代码没问题:

• 它简单(我，作为一个与项目无关的人，或多或少可以说出它的作用)
• 它小(一个类解决一个问题的 20 行代码)
• 它是可测试的(正如您的同事提到的，他们可以注入(inject) stub 并对其进行良好测试)

话虽如此，结论很明显 - 除了可能违反 SRP 之外，没有太大的改进空间；令人耳目一新的部分确实可以在不同的组件中。但是，然后您将有两个必须连接在一起(正如您的同事也提到的那样 - 事实上，此类已经这样做了)。有人可能会争辩说这是要走的路，但是当类/职责这么小时，付出的努力通常得不偿失，而且往往会给代码带来不必要的复杂性。

您的第 1、2 和 4 点并不是重新设计的最佳论据。 SRP 是对的。但是，您的同事的论点更有说服力 - 将这么小的类(class)分成 3 个很可能不会有任何好处，而且肯定会让人稍后提出问题。

总而言之，值得记住的是在某些时候必须有人阅读您的代码。您需要知道何时停止关注模式和完美设计，以及何时开始关注让您的代码尽可能简单以供其他人遵循。