架构师训练营第二周学习总结
理念
第一周主要讲理念和使用UML。UML是架构师的语言,表达与思考,都需要用到。程序员要为系统编写代码,编写可供编译器或解释器理解的代码,也要编写给人看的代码。架构师的语言是UML,架构师要为系统的众多相关方描述系统,面对不同的相关方,在不同的阶段,对不同规模的系统,对不同的团队,要使用不同的架构视图。主要目的只有一个,以技术架构来指导实现系统,但是情况不同则方式不同。需要两个前提,一是肚子里有货,自己对系统的架构有清晰的思路,二是懂得正确的表达。不举例展开说明了。
第二周继续讲理念以及设计模式的运用。理念的东西有些人不喜欢听,然而,我觉得这些才是更难得的。系统架构所用的知识,网上到处都是,就好像山上的木头,遍地都是,但是如何用这些木头设计出经典的建筑,就不是人人都可以做到了。老师讲自己的经验,讲如何去运用架构知识,我觉得很受用,没学两招,但已经信心十足了,三四节课,已经明白了目标和方向,剩下的只是时间问题了。这两周也开始有意识地对参与的项目进行架构设计工作了。系统架构无非就是架构思维与架构表达,剩下的就是强化训练,提高思维力、表达能力、实际运用、积累经验罢了。说不定哪天也可以将自己的经验梳理成文,“点化”一下有缘的朋友。😊
架构师需要在系统开发中打开局面,面对繁复的系统,如何下手,能让团队有一致的技术思路,能让团队少走弯路,架构师第一个要站出来,打破僵局,而且基本正确。架构师要对自己的设计负责,自始至终要以负责的态度来对待自己的设计,不甩锅不抱怨。
探索编程
莱布尼兹、Ada在计算机诞生之前就已经在探索编程了。编程早于发明计算机之前,说明先有编程思想,慢慢才有实物--计算机,而计算机的出现,又极大的发展了编程。这是一个很重要的事实。思想是先于实物的,实物出现后,对思想会有很大的促进和演变。所以架构师必须对系统有初步的架构的思想,然后用相应的视图来表示,并在头脑中和计算机中验证自己的架构思想,就可以互相促进。思与行并重,“行”指对架构思想的表达。
编程思想里,数据就是程序,第一用数据表达程序的思想,如面向过程、面向对象等,用另一个程序来解释数据所表达的思想或者编译成机器的运行序列。机器只会0与1的变幻,而变幻的意义则是人赋予的,这就是思想。第二,数据可以是程序操作的对象,数据也可以是程序,同样的,数据就可以表示一切它可以表示的东西,如框架,架构师就是定架构的人,架构师的思维模式是架构性的、平台性的、框架性的。思想有了,数据也就不远了。
如何组织0和1?答案是通过编程,编程就是将思想用计算机来表达。一切问题,都是思想的问题,脑子不认为是个问题,就没有问题。问题有了,就要解决,计算机是个“好”工具,不是唯一的。
编程就是这么个转换过程,把自己的问题转换一下,丢给计算机。其实架构师也是个“计算机”,把系统开发问题转换一下,转换成不同架构视图的架构文档,转换成开发框架,转换成开发规范。不过这个“计算机”不是被动去工作,得主动学习转换知识,主动转换输出,才算是合格的架构师。
面向对象
把一个系统复杂系统,直接全部对应为机器语言0和1是不可能的,直接对应成汇编也是没办法的,直接对应成C或许可以,但是难度极大。将事物对应成什么?架构师得做这个工作,面向对象是一个好方法。将事物抽象为对象,人容易理解,面向对象语言也可以解析,“对象”则是合适的转换对象。将事物变成“对象”,交给计算机去处理,可以算是最理想的编程开发了。面向对象的思维、面向对象分析、面向对象的设计、面向对象编程,虽然分了这么多步,核心思想只有一个,就是对象思维抽象法。
面向对象的特性主要有:
万物皆对象
程序是对象的集合,通过消息来通讯
对象有自己的存储和类型
在实际使用中,不要为了概念而概念,面向对象是一种方便有效的思维模式,精髓是封装与多态
对象有什么特性?基本特性是封装、继承、多态。封装的好处,就是隐藏细节,隐藏细节就是隐藏复杂度。继承的主要作用是实现多态,多态是面向对象思维的核心。
面向对象编程不是使用面向对象的编程语言进行编程,而是利用多态性进行编程。
面向对象是将问题领域进行对象分析。
充血模型与贫血模型
领域驱动设计DDD
一、贫血模型
所谓贫血模型,是指Model 中,仅包含状态(属性),不包含行为(方法),采用这种设计时,需要分离出DB层,专门用于数据库操作。
二、充血模型
Model 中既包括状态,又包括行为,是最符合面向对象的设计方式。
充血模型与贫血模型各有特色,Web开发中,贫血模型用得较多。
DDD过程
DDD是一种软件设计的思维模式,以问题领域为中心,而不是以传统的数据库为中心的思维模式。目的都是控制系统复杂度
面向对象设计的目的与原则
面向对象设计的目的
强内聚,低耦合。从而使系统:
易扩展 - 易于增加新的功能
更强壮 - 不容易被粗心的程序员破坏
可移植 - 能够在多样的环境下运行
更简单 - 容易理解、容易维护
面向对象设计的原则
原则一:开闭原则(OCP)
对于扩展是开放的
对于更改是封闭的
不需要修改软件实体(类、模块、函数),就可以扩展功能
关键是抽象!
策略模式
适配器模式
观察者模式
原则二:依赖倒置原则(DIP)
依赖倒置原则(Dependence Inversion Principle):
1、高层模块不应该依赖低层模块,二者都应该依赖抽象。
2、抽象不应该依赖细节,细节应该依赖抽象。
3、依赖倒置的中心思想是面向接口编程。
4、依赖倒置原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础搭建的架构要稳定的多。
5、使用接口或抽象类的目的是指定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类来完成。
高层需要的不是具体的对象、实现、模块等,高层需要的是解决问题的“能力”,能力是抽象的,实现是细节。依赖倒置倒置了模块或包的依赖关系以及开发顺序和职责。依赖倒置是面向对象设计的原则之一,关键还是抽象。
好莱坞规则:
Don't call me,I'll call you.
倒转的层次依赖关系
原则三:Liskov替换原则(LSP)
一个正确的继承要符合什么要求?Liskov替换原则
LSP的反命题不成立
不符合IS-A关系的继承,一定不符合LSP
子类的契约不能比基类更严格
解决Liskov问题:重构提取基类、改用组合
原则四:单一职责原则(SRP)
一个类,只能有一个引起它的变化的原因(一个职责是一个变化的原因)
原则五:接口分离原则(ISP)
不应该强迫客户程序依赖它们不需要的方法,使用不同的接口拆分
设计模式
23种设计模式,需要明白在什么情况下使用何种模式来达到设计的抽象和遵循设计原则。
框架与工具
框架是用来实现某一类应用的结构性的程序,是对某一类架构方案可服用的设计与实现,框架如同框架结构的大厦的框架,可以简化应用开发者的工作,实现了多种设计模式,使应用开发者不需要花太大的力气就可以设计出结构良好的程序来。
不同领域的框架有:MFC、AWT、MyBatis、Spring、Tomcat等
框架与工具的区别:
框架调用应用程序代码,应用程序代码调用工具
架构师用框架保证架构的落地,架构师用工具提高开发效率
版权声明: 本文为 InfoQ 作者【王鑫龙】的原创文章。
原文链接:【http://xie.infoq.cn/article/06f84d69cf987cf9a31faefd2】。
本文遵守【CC BY-NC】协议,转载请保留原文出处及本版权声明。
评论