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

简介:

前言:

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

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


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

 

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

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

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

最终实现页面如下调用:
复制代码

 

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

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

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

 

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

 

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

说明:

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

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

 

2:现在情况是什么呢

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

复制代码
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,一引用系统会提示

 

那实际的情况是怎样?

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的地址

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

 

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

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

 

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

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

复制代码
    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();

 

 

结言:

复制代码
项目的一开始,总对自己代码很满意,[需求产生了,于是将就写那么一点一点一点一点不太美观的代码]←如此循环。
 
终于有一天,回头发现自己编写了一堆垃圾代码~~~于是辞职走人,烂摊子留给别人了;
 
再于又就职了,接手别人的烂摊子,然后一个劲的叫爹娘~~~~
 
简洁的代码,人人有责~~让代码来的更简洁易懂些~~~
 
~一切只想让代码更简洁,看起来更优美,于是为之想了很多很多~~~
复制代码
相关文章
|
设计模式 算法 Java
设计模式第十五讲:重构 - 改善既有代码的设计(下)
设计模式第十五讲:重构 - 改善既有代码的设计
279 0
|
3月前
|
Java Android开发
Android项目架构设计问题之要提升代码的可读性和管理性如何解决
Android项目架构设计问题之要提升代码的可读性和管理性如何解决
38 0
|
6月前
|
前端开发 JavaScript 测试技术
修改代码的艺术——如何高效开发、维护和重构复杂的现有系统
这篇文章回忆了作者在高三时期通过努力进入班级前列的故事,并引申到软件开发领域。作者指出,开发工作往往被认为困难重重,但实际上,通过良好的方法、设计和工具,可以提高开发效率和享受编程带来的成就感。文章以最近完成的一个复杂核心需求为例,详细介绍了如何分析、设计和实现这个需求,包括采用领域驱动设计(DDD)理念,数据库字段变更,代码实现,自动化单元测试,重构和代码维护的重要性。最后,作者推荐了几本关于软件开发的经典书籍,并鼓励开发者不断提升自己,以更好地应对挑战。
|
设计模式 Java 测试技术
设计模式第十五讲:重构 - 改善既有代码的设计(上)
设计模式第十五讲:重构 - 改善既有代码的设计
315 0
|
设计模式 测试技术
重构·改善既有代码的设计.02之代码的“坏味道”
之前在《重构·改善既有代码的设计.01》中初步了解了重构的基本前提,基础原则等入门知识。今天我们继续第二更......
205 1
重构·改善既有代码的设计.02之代码的“坏味道”
|
算法
第七章 多用模板专注设计(上)
第七章 多用模板专注设计
101 0
第七章 多用模板专注设计(上)
|
数据库
高质量代码优化!谈谈重构项目中if-else代码的几点建议
本篇文章探讨了代码的重构以及优化,主要针对代码中大量的条件判断if-else语句问题提出了具体的优化建议。介绍了优化if-else语句的几种有效的方法,包括switch,接口interface以及数据库实现对条件语句进行的优化。
172 0
高质量代码优化!谈谈重构项目中if-else代码的几点建议
|
设计模式 Java 程序员
《重构:改善既有代码的设计》-学习笔记一(+实战解析)
《重构:改善既有代码的设计》-学习笔记一(+实战解析)
204 0
《重构:改善既有代码的设计》-学习笔记一(+实战解析)
|
程序员
《重构:改善既有代码的设计》-学习笔记二(+实战解析)
《重构:改善既有代码的设计》-学习笔记二(+实战解析)
573 0
《重构:改善既有代码的设计》-学习笔记二(+实战解析)
下一篇
无影云桌面