[原创微学堂首发]流氓程序员必备素质:代码重构(一)
整篇连载都不提及架构,因为没有某种架构模式是特定命名的,架构设计是一门哲学,要学会用之自如,象打太极一样,实则虚也,虚则实也,非虚则非实业。要想成事,不要以成事的态度去做事,要学会疯狂,冲动,同时也是艺术创作必备心里素质,编程也是,物极必反。本整篇连载我会挑战自我的,一直以来,我都不太善于用别人的思路及想象读者的感受去澄清事实。这种类型的人我也相识了好多,举个例子,Koumi,这孩子是疯子,有疯子的潜质,下班了,明天继续写吧。
首先,我先阐述下一些概念性的问题
关于几个关于松耦合强内聚重要原则需要谨记的
1.单一职责原则 (Single Responsibility Principle,SRP)
2.Liskov替换原则 (Liskov Substitution Principle,LSP)
3.打开、关闭原则 (Open-Closed Principle,OCP)
4.依赖倒转原则 (Dependency Invertion Principle,DIP)
5.接口隔离原则 (Interface Separate Principle,ISP)
这些原则都是重要的面向对象原则,我这里就不Ctrl CV概念了,大家自己找下度娘
下面给大家举个例子,是关于SRP的,大家一起探讨一下,如有不正确的地方,请多指教
SRP要记住的只有一点:不要真实的、直接的去设计某个功能(或某个类),抽象其子功能仅做一件(或者一方面)事情的单一元素。
如是,就说我们公司,现在大家都在一个大厅,市场部,测试部,开发部,研发部,等
情景一:当有人说,以下部门到会议室开会,那么所有部门的员工都要分心,把手头的工作停一下,认真听到底是哪个部门。
这就违反了SRP的原则,SRP可以这样做:
情景二:每一个部门在一个屋,通知员到每个屋都喊一下,大家到会议室开会即可。
那么我们来分析下实质问题。
情景一通知员只需要喊一次,但是所有人都会收到影响,这是我们得到一个问题,如果这个屋有越多个团队及部门,那么每个人浪费一分钟去听通知员,那么加起来就越很浪费大家的时间,何况通知员在念部门的时候还要浪费时间,不止是一分钟的问题啦
这时我们会得到一个结论:人越多,耽误的时间越多。那么既是:当一个类方法越多,修改起来越费事。我们要逐个的去找我们要通知的方法,当进行替换的时候,整个类都要重新编译,浪费大量时间
同时,我们再来分析SRP的弊端
情景二通知员逐个的跑每个部门进行通知,首先他必须要动脑知道我通知的部门是什么,需要计划下路线,而情景一照通知稿念就ok了,这一点要更费时。当部门不多的时候,或者有部门不在或者就一两人的情况下,那么通知员去通知,一定浪费事件。
这时,我们又得到一个结论:人越少,或部门少,耽误的时间也多。那么既是:当一个类方法少,或相对后期变动不大,那么呕心沥血的去迎合SRP只会另你更痛苦。我们不要因为折磨自己而养成自虐倾向,这也是流氓程序员的必备素质之一:某些情况不要为了迎合定义原则,被原则虐待,这会直接或间接阻碍你的执行力,甚至智商,相信我,那样你只会学会如何变得更脑残而已!
上面分析也差不多了,该上代码的时候了
//设计关于通知方面的接口实现单一职责
//单一职责,SRP,通知接口
public interface TongZhiYuan
{
void Fun_TongZhi(string Context, string HuiYiShiBH);
}
//公司基础类,提供一些公司结构
public class GongSi
{
internal static string HuiYiShi;
}
//开发部门
public class KaiFaBu : GongSi, TongZhiYuan
{
public void Fun_TongZhi(string Context, string HuiYiShiBH)
{
//实现通知去哪个会议室
throw new NotImplementedException();
}
}
//业务部门
public class YeWuBu : GongSi, TongZhiYuan
{
public void Fun_TongZhi(string Context, string HuiYiShiBH)
{
//已经收到去哪个会议室了
HuiYiShi = HuiYiShiBH;
//继承公司
//大家得知了,会思考父类,公司的这个会议室在哪,怎么去,等等
}
}
欢迎大家批评,指正,我会虚心接受。嗯,我知道我在推翻传统甚至主流思想,但我会坚持我自己的路让别人说去吧。有些道理我写完就会遭到骂声一片,但我仍然会义无反顾的去做,我相信不久的将来,大批流氓程序员也会编程主流,也有自己的原则。
讨论群:Asp.net(一群)29123371,微学堂 9940051