c# – 对这个阶级的建设性批评

2019-06-10 23:03:32 阅读：190 来源： 互联网

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

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 
     }

}

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

解决方法:

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

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

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

标签：c,class-design
来源： https://codeday.me/bug/20190610/1214473.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

c# – 对这个阶级的建设性批评