第二周学习总结

发布于: 50 分钟前

架构师,就是让别人依赖你的代码,你开发的框架,别人要基于你的框架去开发东西,有问题要找你才能解决,这时你在公司的架构师的地位就奠定了。框架也可以不是完全由你开发的,但至少是你选型的,或者是主要的维护者。

什么是框架?什么是工具?

框架:定义了规范,别人是要基于框架进行编码才能实现具体功能;

工具:提供了具体功能,别人只需要调用就可以;

例如:junit是一个框架,我需要实现单元测试内的逻辑;log4j是一个工具,根据入参实现日志记录的功能。

设计模式的收获

设计模式、设计原则真的是一个值得反复琢磨的东西,初看设计模式第一感觉就是晦涩难懂,看是看完了,还是不知道怎么在代码中应用。不过每过一段时间,看看不同人对设计模式的理解,都会有新的收获。

OOD原则一:开/闭原则(OCP)

可以通过策略模式、观察者模式、适配器模式打断类之间的强关系,解耦。达到新增功能只新增代码不修改原有代码的目的;

OOD原则二:依赖倒置原则(DIP)

依赖倒置原则的原始定义为:高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象

主要分辨接口是由谁定义的。由高层模块定义接口,底层模块仅实现,叫做依赖倒置。但是如果是由底层定义接口、底层实现,这种就不叫依赖倒置。

举一个形象,但可能不太恰当的例子:

1、service层定义接口,由controller调用,这个属于高层依赖低层;

2、controller定义接口,由service层实现,这个就是高层不依赖低层,是符合依赖倒置原则。

这个原则在做业务功能开发的时候,可能不太适用,因为分层架构强调的就是单向依赖。

在做系统框架的时候,理解比较深刻点。在做框架时,高层就是我们定义的通用业务规则,低层就是项目的具体实现细节。框架约束了实现的范围,具体细节依赖框架实现,框架不受具体实现细节的影响。

OOD原则三:里氏替换原则(LSP)

子类的访问控制不能比父类更加严格

OOD原则四:单一职责原则(SRP)

这个比较好理解:两个不太相关的逻辑不要放到一个类里面。PS:不过通常做业务的时候,当业务逻辑变大时才拆,逻辑简单的时候,拆开反而增加类间关系的复杂度。

OOD原则五:接口隔离原则(ISP)

推荐通过适配器模式,解决胖接口的问题。

用户头像

CP

关注

还未添加个人签名 2018.03.15 加入

还未添加个人简介

评论

发布
暂无评论
第二周学习总结