架构师训练营 - 第 2 周学习总结

用户头像
红了哟
关注
发布于: 2020 年 06 月 20 日

从编程历史慢慢了解到了常用的一些OOD原则和使用,以及到架构中的应用场景,哪些只有在架构时才会思考的优缺点,收获满满

1、编程语言的历史演进过程

1.1、汇编语言,每一种CPU都有独特的机器语言,因而需要不同的汇编语言

1.2、早期的Basic语言,早期Basic语言虽然号称为“高级语言”,但保留了汇编语言的特征--地址(即行号)

1.3、结构化的Basic语言(Quick Basic 、Visual Basic等),结构化的Basic 语言仍然兼容传统的Basic,而且提供了更好的继承开发环境。

结构化的编程取消了“地址”和Goto语句,代之以集中程序控制“结构”,如:循环、条件等。

1.4、Perl语言,Perl是一种脚本语言,最强大的功能是正则表达式。但Perl的语法比较晦涩难懂。Perl是一种“伪”的面向对象语言。

1.5、C语言是一个结构化语言

1.6、C++向后兼容C的所有功能,并且提供了面向对象的编程机制。

1.6、Java是一个完全面向对象的语言,尤其是在当今的Internet编程领域,占领了绝对的市场。

1.7、编程语言是一种“抽象”的机制,问题是对“谁”来抽象:

领域问题--分析,抽象-->模型<--设计抽象,开发实现-->软件系统



2、面向对象编程的三要素(特征)

2.1、封装性(隐藏实现,抽象方法)

2.2、继承性(接口重用,多实现多子类)

2.3、多态性(对象互换的魔法,父类引用指向子类对象)

2.4、面向对象编程不是使用面向兑现的编程语言进行编程,而是利用多态特征进行编程。

2.5、面向对象分析是将客观世界,即编程的业务领域进行对象分析。

2.5.1、充血模型和贫血模型

所谓充血模型,是指Model 中既包括状态,又包括行为,是最符合面向对象的设计方式

所谓贫血模型,是指Model 中,仅包含状态(属性),不包含行为(方法),采用这种设计时,需要分离出DB层,专门用于数据库操作

2.5.2、领域驱动设计DDD(Domain-Driven Design )

2.6、面向对象设计的目的和原则

2.6.1、强内聚、低耦合,从而使系统易扩展-易于增加新的功能,更强壮-不容易被粗心的程序员破坏,可移植-能够在多样的环境下运行,更简单-容易理解、容易维护

2.6.2、为了达到上述设计目标,有人总结除了多种知道原则;“原则”是独立于变成语言的,甚至也可以用于非面向对象的编程语言中。

2.7、设计模式,设计模式是用于解决某一种问题的通用的解决方案。设计模式也是语言中立的。设计模式贯彻了设计原则。

2.8、框架是用来实现某一类应用的结构性的程序,是对某一类架构方案可复用的设计与实现:

如同架构结构的大厦的框架。

简化应用开发者的工作。

实现了多种设计模式,使应用开发者不需要花太大的利器,就能设计出结构良好的程序来

2.9、架构 VS 工具

架构调用应用程序代码

应用程序代码调用工具

架构师用框架保证架构的落地

架构师用工具提高开发效率

3.1、面向对象设计的基本原则

3.1.1、软件设计的“臭味”,一个“不好的”软件,会发出如下“臭味”:

僵硬 - 不易改变。僵化性(Rigidity):很难对系统进行改动,因为每个改动都会迫使许多对系统其它部分的改动。

脆弱 - 只想改变A,结果B被意外破坏。脆弱性(Fragility):对系统的改动会导致系统中和改动的地方无关的许多地方出现问题。

不可移植 - 不能适应环境的变化。牢固性(Immobility):很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。

导致误用的陷阱 - 做错误的事比做正确的事更容易,引诱程序员破坏原有的设计。

粘滞性(Viscosity):做正确的事情比做错误的事情要困难。不必要的复杂性(Needless Complexity):设计中包含有不具任何直接好处的基础结构。

晦涩 - 代码难以理解。晦涩性(Opacity):很难阅读、理解。没有很好的表现出意图。

过度设计、copy-paste代码。不必要的重复(Needless Repetition):设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。

3.2、OOD原则一:开/闭原则(OCP-Open/Closed Principle)

对于扩展是开放的(Open for extension)

对于更改是封闭的(Closed for modification)

简言之:不需要修改软件实体(类、模块、函数等),就应该能实现功能的扩展

3.3、OOD原则二:依赖倒置原则(DIP-Dependency Inversion Principle)

高层模块不能依赖底层模块,而是大家都依赖于抽象。

抽象不能依赖实现,而是实现依赖抽象。

DIP倒置了模块或包的依赖关系,以及开发顺序和职责

软件的层次化,高层决定低层,高层被重用

层次依赖关系:

策略(Policy)<-- 机制(mechanism)<-- 公用(utility)

3.4、OOD原则三:Liskov替换原则(LSP)

在Java/C++这样的静态类型语言中,实现OCP的关键在于抽象,而抽象的威力在于多态和继承。

若对每个类型T1的对象o1,都存在一个类型T2的对象o2,使得在所有针对T2编写的程序P中,用o1替换o2后,程序P的行为功能不变,则T1是T2的子类型。

简言之:子类型(subType)必须能够替换掉它们的基类型(base type)。

重构代码,提取共性到基类

3.5、框架的核心

好莱坞规则:Don't call me,I‘ll call you.

倒转的层次依赖关系

3.6、OOD原则四:单一职责原则(SRP-Single Responsibility Principle)

又被称为“内聚性原则(Cohesion)”,意为:一个模块的组成原色之间的功能相关性。

将它与引起一个模块改变的作用力相联,就形成了如下描述:一个类,只能有一个引起它的变化的原因。

3.7、OOD原则五:接口分离原则(ISP-Interface Segregation Priciple)

不应该强迫客户程序依赖它们不需要的方法。

ISP和SRP是相关的,都和”内聚性“有关。

SRP指出应该如何设计一个类---只能有一种原因才能促使类发生改变。

ISP指出应该如何设计一个接口---从客户的需要出发,强调不要让客户看到他们不需要的方法。



发布于: 2020 年 06 月 20 日 阅读数: 38
用户头像

红了哟

关注

还未添加个人签名 2019.08.15 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营 - 第2周学习总结