对这一阶级的建设性批评

Question

我刚才回顾了一些看起来像这样的代码

public class ProductChecker
{
     // some std stuff
     public ProductChecker(int AccountNumber)
     {
         var account = new AccountPersonalDetails(AccountNumber);
         //Get some info from account and populate class fields
     } 
     public bool ProductACriteriaPassed()
     {
          //return some criteria based on stuff in account class 
          //but now accessible in private fields
     }

}

现在已经添加了一些额外的标准,这些标准需要不在AccountPersonalDetails类中的数据

新代码看起来像这样

public class ProductChecker
{
     // some std stuff
     public ProductChecker(int AccountNumber)
     {
         var account = new AccountPersonalDetails(AccountNumber);
         var otherinfo = getOtherInfo(AccountNumber)
         //Get some info from account and populate class fields
     } 
     public bool ProductACriteriaPassed()
     {
          //return some criteria based on stuff in account class  
          // but now accessible in private fields and other info
     }

     public otherinfo getOtherInfo(int AccountNumber)
     {
        //DIRECT CALL TO DB TO GET OTHERINFO 
     }

}

我对数据库部分感到困扰,但人们可以告诉我为什么这是错误的？或者是吗？

Answer 1

在系统的分层视图中,它看起来像ProductChecker属于业务规则/业务逻辑层,因此它不应该被"污染"用户交互功能(属于上面的层)或 - 这与你的情况密切相关 - 存储功能(属于下面的图层).

"其他信息"应该封装在自己的存储层类中,该类应该是处理持久化/检索功能的类(就像我想象的那样AccountPersonalDetails是为了它自己的东西)."个人详细信息"和"其他信息"最好是作为单独的类保存还是加入一个我无法从所提供的信息中分辨出来,但应该严格考虑并仔细权衡该选项.

保持层分离的经验法则有时可能会感到僵硬,并且通常很容易通过层的错位来快速添加特征 - 但为了保持系统的可维护性和清洁性,我几乎总是争辩说当出现这样的设计问题时,层分离.在OOP术语中,它表示"强大的凝聚力,但弱耦合"; 但在某种意义上它比OOP更基础,因为它也适用于其他编程范例及其混合! - )