【架构训练营】第二期

发布于: 10 小时前

编程语言的实质

 

编程的目的是:用计算机来解决现实世界的问题

 

编程的过程:在计算机所能理解的“模型”(解空间)和现实世界(问题空间)之间,建立一种联系。

 

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

编程的核心要素

OOP三大特征

 

  1. 封装

  2. 继承

  3. 多态

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

 

OCP (Open/Closed principle)

  • 对于扩展是开放的(Open forextension)

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

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

策略模式

 

意图:定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。

主要解决:在有多种算法相似的情况下,使用 if...else 所带来的复杂和难以维护。

何时使用:一个系统有许多许多类,而区分它们的只是他们直接的行为。

如何解决:将这些算法封装成一个一个的类,任意地替换。

关键代码:实现同一个接口。

应用实例: 1、诸葛亮的锦囊妙计,每一个锦囊就是一个策略。 2、旅行的出游方式,选择骑自行车、坐汽车,每一种旅行方式都是一个策略。 3、JAVA AWT 中的 LayoutManager。

优点: 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。

缺点: 1、策略类会增多。 2、所有策略类都需要对外暴露。

使用场景: 1、如果在一个系统里面有许多类,它们之间的区别仅在于它们的行为,那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2、一个系统需要动态地在几种算法中选择一种。 3、如果一个对象有很多的行为,如果不用恰当的模式,这些行为就只好使用多重的条件选择语句来实现。

注意事项:如果一个系统的策略多于四个,就需要考虑使用混合模式,解决策略类膨胀的问题。

适配器模式

 

意图:将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

主要解决:主要解决在软件系统中,常常要将一些"现存的对象"放到新的环境中,而新环境要求的接口是现对象不能满足的。

何时使用: 1、系统需要使用现有的类,而此类的接口不符合系统的需要。 2、想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作,这些源类不一定有一致的接口。 3、通过接口转换,将一个类插入另一个类系中。(比如老虎和飞禽,现在多了一个飞虎,在不增加实体的需求下,增加一个适配器,在里面包容一个虎对象,实现飞的接口。)

如何解决:继承或依赖(推荐)。

关键代码:适配器继承或依赖已有的对象,实现想要的目标接口。

应用实例: 1、美国电器 110V,中国 220V,就要有一个适配器将 110V 转化为 220V。 2、JAVA JDK 1.1 提供了 Enumeration 接口,而在 1.2 中提供了 Iterator 接口,想要使用 1.2 的 JDK,则要将以前系统的 Enumeration 接口转化为 Iterator 接口,这时就需要适配器模式。 3、在 LINUX 上运行 WINDOWS 程序。 4、JAVA 中的 jdbc。

优点: 1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好。

缺点: 1、过多地使用适配器,会让系统非常零乱,不易整体进行把握。比如,明明看到调用的是 A 接口,其实内部被适配成了 B 接口的实现,一个系统如果太多出现这种情况,无异于一场灾难。因此如果不是很有必要,可以不使用适配器,而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类,所以至多只能适配一个适配者类,而且目标类必须是抽象类。

使用场景:有动机地修改一个正常运行的系统的接口,这时应该考虑使用适配器模式。

注意事项:适配器不是在详细设计时添加的,而是解决正在服役的项目的问题。

观察者模式

 

意图:定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。

主要解决:一个对象状态改变给其他对象通知的问题,而且要考虑到易用和低耦合,保证高度的协作。

何时使用:一个对象(目标对象)的状态发生改变,所有的依赖对象(观察者对象)都将得到通知,进行广播通知。

如何解决:使用面向对象技术,可以将这种依赖关系弱化。

关键代码:在抽象类里有一个 ArrayList 存放观察者们。

应用实例: 1、拍卖的时候,拍卖师观察最高标价,然后通知给其他竞价者竞价。 2、西游记里面悟空请求菩萨降服红孩儿,菩萨洒了一地水招来一个老乌龟,这个乌龟就是观察者,他观察菩萨洒水这个动作。

优点: 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。

缺点: 1、如果一个被观察者对象有很多的直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话,观察目标会触发它们之间进行循环调用,可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的,而仅仅只是知道观察目标发生了变化。

使用场景:

  • 一个抽象模型有两个方面,其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。

  • 一个对象的改变将导致其他一个或多个对象也发生改变,而不知道具体有多少对象将发生改变,可以降低对象之间的耦合度。

  • 一个对象必须通知其他对象,而并不知道这些对象是谁。

  • 需要在系统中创建一个触发链,A对象的行为将影响B对象,B对象的行为将影响C对象……,可以使用观察者模式创建一种链式触发机制。

注意事项: 1、JAVA 中已经有了对观察者模式的支持类。 2、避免循环引用。 3、如果顺序执行,某一观察者错误会导致系统卡壳,一般采用异步方式。

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

 

DIP - Dependency Inversion Principle

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

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

 

DIP倒置了什么?

  • 模块或包的依赖关系

  • 开发顺序和职责

 

软件的层次化

  • 高层决定底层

  • 高层被重用

框架的核心

 

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

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

 

使用父类的地方可以用子类代替

子类一定得拥有积累的整个接口

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

子类的“契约”不能比基类更“严格”

 

解决方法

  • 提取共性到基类

  • 改成组合

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

 

SRP - Single Responsibility Principle

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

  • 一个类,只能有一个引起它变化的原因

OOP原则五:接口分离原则(ISP)

 

ISP - InterfaceSegregation Principle

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

 

ISP和SRP的关系

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

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

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

用户头像

云064

关注

还未添加个人签名 2018.05.24 加入

还未添加个人简介

评论

发布
暂无评论
【架构训练营】第二期