1.开闭原则
开闭原则:面向拓展开放,面向修改关闭
我对其的理解:一段代码,你将来要做拓展的时候,无论是技术应用上的修改,算法的修改,业务的修改,如果需要对原来的代码修改才能达成目的,便是违反了本原则。
所以在打代码的时候,我都是在实现功能的同时,多做设想,设想这个业务以后会怎么改,如果想改掉使用的技术需要怎么做,如果算法变了怎么办。
如何刹车:想得太多,肯定会把自己想歪,有时候这个问题可能本身就是无解的,所以还是要在敲下第一行业务代码前,先找别人做个简短的交流,把自己混乱的想法梳理清除并向别人阐述,再听取意见。
2.敲代码时的原则,extend,implement,implements
extend:父类出现的地方,子类一定要能够出现,其实就是在继承时,父类的方法的定义,子类必须完美的继承,不能父类是造飞机的,子类变成造火箭了,只能变成造喷气式飞机
implement:面向接口编程,不直接依赖其实现类,这个在spring中有大量的应用实例,如依赖注入的接口,我们只需要在写详细实现时,考虑下是否可以把这块抽象出一个接口就行了。
implements:接口拆分,接口不是简单拆分就行了,我们应该尽量考虑做必要的接口细分,在抽象C接口的时候,必要的将C接口拆分成A接口 + B接口,没必要,那就别拆
3.写业务时的原则,单一,组合,屏蔽
单一:一个封装,应该只做一个事情,不要让它承受过多它不应该承受的事情
那如果我一个业务比较复杂,需要多个单一的业务配合怎么办,这时候多用组合
组合:将多个单一的业务通过组合的方式组成一个新的单一业务封装层次,而尽量不要在某个单一业务,通过继承的方式集成进这一复杂业务
我们在组合出了新的业务封装层次后,这时候,我们最好能实现这一效果,屏蔽
屏蔽:我们组合出来的新的封装层次,能屏蔽掉组合所使用的多个单一业务之间的业务复杂度,使得其他业务能在不知道这几个单一业务之间业务复杂度的前提下,通该封装层次间接使用这些业务
写在最后:这3点对我来说发挥的作用主要还是让我在打代码的时候让这几大设计原则浮现在我眼前而已,但是实际上,业务代码错综复杂,在考虑到效率和易理解的前提下,即使设计出了很清晰的代码层次关系,有时候也要委曲求全。对我来说,能实现预期的业务,并适度留下适当的拓展空间,在别人能很快理解的前提下,做到低耦合,少bug,就是好代码。
最后推荐一个对7大设计模式说得比较好的博客