设计代码的经验总结

设计模式虽然好,但也并非任何场景都适合,我觉得在设计代码时只要时刻牢记高内聚、低耦合这两个原则,并在编码中实践,写出来的代码必定不会差。

衡量代码优异的标准:拓展性,复用性,维护性;23种设计模式;亦或者面向对象的封装、继承、多态在我看来无非是对高内聚低耦合原则的不同维度的阐述。

下面分别阐述个人的一些理解。

高内聚低耦合这两个原则都是围绕相互间的关联来定义的,内聚指的是将相互间关系密切的代码聚合到一个模块,怎么划分“关系密切”是重点,这就要强调“单一职责”了,用面向对象来解释就是定义一个类,类的属性和行为都是履行这个类的职责定义的,不属于这个类职责的属性和行为就不应该定义在这个类里,如此,类的职责就很明确了,而类里的属性和行为也都是密切相关的,也就符合所谓的高内聚。耦合从字面意思来看,耦可解释为藕断丝连,也就是关系杂乱,合可解释为串联合作,例如给耳机插入电脑合作我们就能通过耳机听音乐了,低耦合即是减少这些关系,用尽可能少的关系来完成联合工作,我觉得这个用迪米特法则来解释比较贴切,即对一个对象的了解越少越好,比如你去菜市场买猪肉,你只需要到猪肉贩那买猪肉即可,还用替猪肉贩操心你这猪肉没了帮他杀猪再进行买卖吗?将这个例子转化为程序例子即是:你得到一个猪肉贩对象,你先调用猪肉贩对象的查询猪肉量的接口,判断有没有足够你想买的猪肉量,如果没有,就调用猪肉贩对象杀头猪的接口,然后再调用买猪肉的接口,搞得人家猪肉贩跟个白痴似的。假设猪肉贩就是个白痴,没猪肉了你调用杀猪接口帮他杀猪,ok,猪肉贩以前都是在肉摊旁杀猪,所以你调用杀猪接口能帮他杀猪,但后来菜市场规定不能再菜市场内杀猪,那样太扰民了,猪肉贩找了个搭档,自己专门在肉摊上卖猪肉,搭档则负责在其他地方杀猪,要新的猪肉就扣个电话叫搭档把杀好的猪送过来,这样就相当于原本杀猪的接口没用了,如果猪肉贩还是你想象的那么白痴,那么新的接口变了的时候,你就要自己去追踪变化和修改变化,这样势必增加了编程的负担,这也是典型的一个耦合严重的例子,买个猪肉还用操那么多心。那怎么降低耦合呢?很简单,首先我们要明确职责,我只是个买主,我只想买猪肉,人家猪肉够不够卖用得着我操心吗?这个问题应该是猪肉贩的职责,杀猪也是人家猪肉贩的职责,我们只需要关心怎么买猪肉的这个接口即可。

如果想将这个接口进一步优化,我们也可以把猪肉贩这个对象设计成超级猪肉贩,即所有的猪肉贩都继承这个超级猪肉贩,这样的话我们的设计就不是和某一猪肉贩强行捆绑在一块了,比如这个猪肉贩猪肉卖完了,市场安排了另一个猪肉贩在这个摊位卖猪肉,你不会因为之前的猪肉贩不在了就买不了猪肉了,这也就是所谓的面向对象的依赖倒置原则,即应该依赖于接口,不依赖于具体的对象。

拓展性我的理解是对于一个模块,我可以很容易的拓展它的功能,不用担心添加新功能会给其他平级功能造成影响。我觉得编码想达到这种成效,结合设计模式的“开闭原则”即可达成,即对拓展开发,对修改关闭。

复用性是指对于一个模块或者一个方法,我不用关心它内部的结构和运作的细节,只需要了解参数的使用即可拿来协作,而关于它的具体定义的理解,有兴趣可以看看我之前写过的这篇《代码复用性的理解》

维护性我的理解是围绕对代码的可读和易改两个方面的阐述,如果一份代码让人看起来就特别别扭费劲,那么光理解代码就得花不少时间,不好理解的代码改起来也势必要关心备至(也就是操不少心),当然好读懂的代码也有不容易改的,比如全局变量的滥用。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值