重构-使代码更简洁优美II:实际经验之谈(项目分层是怎么扯上代码节省的)

2年前 (2022) 程序员胖胖胖虎阿
265 0 0

前言:

好几天没写文了,因为在折腾传说中的8国语言博客,实际目前预定义了10国+1自定义语言,代码还在慢慢的写着写着~~~~

目前最新进展预览网址为:http://cyq.tupianshop.com/ ,其强大之处及 CYQ.Data 框架 V3.N 系列   后文再介绍了。

写文章有时候是需要有灵感或一时的冲动的
~比如刚刚在改博客代码,经过一段思考,得到一些灵感,便有了此文。

 

在很久很久的 Long Long Ago 以前,写过一篇文章:重构-使代码更简洁优美:实际经验之谈(提供一技巧,让你省掉N多代码)

没看过的可以先去看看,在文章的最后,我提到这么一点:

当然你也可以反过来装载,在LogicBase时的构造函数增加IHttpCustom传入。

最终实现页面如下调用:

重构-使代码更简洁优美II:实际经验之谈(项目分层是怎么扯上代码节省的)

 

只是提到,但没提到具体怎么实现,其实并不难,就是基类增加一构造函数,传入IHttpCustom接口即可。

事实上,在我最近重构开发的博客中,也是使用这种方式,节省了大量的参数代码,看起来相当的简洁~

不过,这个不是本节要说的重点,那本节要说的是什么?

 

一:看看现实是什么,问题如何产生

 

1:从图片了解下看下项目分层

重构-使代码更简洁优美II:实际经验之谈(项目分层是怎么扯上代码节省的)

说明:

我们之前为了让逻辑项目Logic能节省大量参数代码,从HttpCustom页面基类中抽出了共同接口:IHttpCustom

同时用抽象基类LogicBase实现接口,这样达到上节说的省略N多参数代码的方法。

 

2:现在情况是什么呢

最后面有个解决方案:Web.Title。它是统一管理所有页面标题的解决项目,看一下Action里的方法:

//作者:路过秋天 博客:http://www.cnblogs.com/cyq1162/
public class Action
    {
        
public static TitleInfo GetTile(string urlPara, string urlType, MDataRow domainUser, MutilLanguage language)
        {
            
//...省略...
        }
    }

再看一下基类里面对这个的调用:

            Web.Title.TitleInfo info = Web.Title.Action.GetTile(UrlPara, UrlType,DomainUser,Language);
            
if (info != null)
            {
                
//...修改当前页面标题...
            }

简单的说就是在基类里要调用Web.Title的代码,一件很普通正常的事情。

那是什么问题?问题就是由于“项目的依赖关系”,Web.Title无法实现像Logic一样的方式。

 

3:神马!项目依赖关系,啥?

简单说:A项目添加了引用B项目的DLL,反过来B项目就不能再引用A的DLL,一引用系统会提示

 

重构-使代码更简洁优美II:实际经验之谈(项目分层是怎么扯上代码节省的)

那实际的情况是怎样?

A:Web.Title如果要实现IHttpCustom,就必然要引用Module项目。
B:HttpCustom要调用Web.Title的,就必然要引用Web.Title项目。
于是循环依赖就产生了,因此就无法实现像Logic那样的方式来解决问题[Module不调用Logic的代码,所以不会互相引用]

 

二:将就点,就那样?

1:好吧,无法实现了吧,传参吧,写N个方法吧,让它们一个一个的传进来,于是,一夜回到解放前~~~~~

其实解放前也不错,多几个参数,也没什么,多传几个参数还能mock,管它谁来mock,反正是能mock,实现不了就这么自我安慰着先~~~

 

2:要增加博客访问统计和文章访问统计了,有点打算把它新开项目去处理~~~

方式和Web.Title一个样,就叫Web.Visit?好吧,这么叫着!实现起来和Web.Title一个!也是在基类里写几行代码处理一下,分支具体交给Web.Visit处理。

Oh~~~继续呆在解放前?不怕不怕了,反正这样写能mock、能mock~~~

 

3:又要新增加XXX功能了,有点打算把它新开项目去处理~~~处理方式和Web.Title又差不多!!

看着一堆加一堆加一堆的参数~~脑迷糊了~心情毛造了~还要这样来几次呀呀呀呀呀!!!
~~oh~~fucX,解什么放什么mock什么~1次2次还能自我安慰,再自我安慰不是神经就是神禁~~~

 

只有当问题重复的出现的太多次时,我们才会去想怎么重构怎么优化...

人越成长,对这重复的次数值就要求的越小~~~

 

三:分层巧一点,理清依赖,重新回到解放后

 

1:对于分层,有这么一种现象

a:很多人不知道层该怎么分,于是动不动就三层
b:有一些人觉得自己理论墨水很多,于是硬写文章说清楚讲明白:三层是哪三层,大伙怎么误解三层,该怎么分才是对
c:有一些老鸟,看到三层就跑去说,你们都让Petshop毒害了

 

2:分层就分层,合理、理清依赖即可 [3只是数字,不是真理]

A:理清依赖,抽离出层,IHttpCustom离家出走

对于基类HttpCustom来说,要调用别人的东西太多了~~简单说就是依赖别人太多自己想要被别人依赖就很难了,
对于接口IHttpCustom来说,被依赖太多,经常被别人引用~~混在一个依赖别人太多的层里,就不合适了。
于是:IHttpCustom要和HttpCustom说拜拜了,该走的始终要走~~

B:IHttpCustom来到了新的项目新的家

新家起名,这是个很头疼的问题,我最后起了个Web.Core,因为后来会有很多人被别人依赖的强人住进来。

C:LogicBase也离家出走,来到了IHttpCustom的地址

重构-使代码更简洁优美II:实际经验之谈(项目分层是怎么扯上代码节省的)

D:两人商量大计,决定一起改名

重构-使代码更简洁优美II:实际经验之谈(项目分层是怎么扯上代码节省的)

 

3:效果已经出来了,循环依赖不见了

a:之前的Logic没什么变化,引用Module改成改用Web.Core,基类只是换了个名称
b:Web.Title终于可以和Logic一样了,引用Web.Core,同样继承CoreBase。
c:管它新来什么,一样引用Web.Core,同样继承CoreBase

 

我们看一下最后变更后调用方式:

A:Title实现,省略了一堆参数

重构-使代码更简洁优美II:实际经验之谈(项目分层是怎么扯上代码节省的)

    public class Action:CoreBase
    {
        public Action(ICore custom) : base(custom)  {  }
        public TitleInfo GetTitle()
        {
            TitleInfo info = new TitleInfo("路过秋天", "http://cyq1162.cnblogs.com", "8国语言博客");
            switch (UrlType)
            {
                case "error":
                case "home":
                case "sys":
                    info = new HomeTitle(this).Get();
                    break;
                case "index":
                case "article":
                case "photo":
                case "admin":
                case "guestbook":
                    info = new UserTitle(this).Get();
                    break;
            }
            info.Title += info.Split + Language.Get(IDLang.sitename);
            info.ClearHtml();
            return info;
        }
    }

 

B:HttpCustom调用

Web.Extend.TitleInfo info =new Web.Extend.Action(this).GetTitle();

 

 

结言:

项目的一开始,总对自己代码很满意,[需求产生了,于是将就写那么一点一点一点一点不太美观的代码]←如此循环。
 
终于有一天,回头发现自己编写了一堆垃圾代码~~~于是辞职走人,烂摊子留给别人了;
 
再于又就职了,接手别人的烂摊子,然后一个劲的叫爹娘~~~~
 
简洁的代码,人人有责~~让代码来的更简洁易懂些~~~
 

~一切只想让代码更简洁,看起来更优美,于是为之想了很多很多~~~

 

相关文章

暂无评论

暂无评论...