复杂类型的设计原则

作者: zsh2517 分类: 未分类 发布时间: 2021-07-07 23:26
  1. 面向过程与面向对象的思想
  2. 类与类之间的关系
  3. 复杂类型的设计原则

复杂类型的设计原则

REP、RI、AF、RE

REP:representation 表示

Invariants:不变量

在任何时候总是true。

Immutability是一个至关重要的不变量:一但不可变对象被创造,其在整个生命周期中,表现出相同的价值。

由ADT来负责其不变量,而与client端的任何行为无关

RI:Representation Independence 表示独立性

client使用ADT时无需考虑其内部如何实现,ADT内部表示的变化不应影响外部spec和客户端。

针对Rep的每一个field以及多个fields之间的关系,进行条件限定,要精确

AF:Abstract Function 抽象函数

可以通俗的理解为从实体类到抽象类的映射,这是一个满射,每一个抽象类都会有实体类对应,但是多个实体类可以对应同一个抽象类

RE:Rep exposure 表示泄露

一旦泄露,ADT内部表示可能会在程序的任何位置发生改变(而不是限制在ADT内部),从而无法确保ADT的不变量是否能够始终保持为true。

保证ADT表示不泄露方法:

构造器和生产器在创建对象时要确保不变量为true
变值器和观察器在执行时必须保持不变性。
在每个方法return之前,用checkRep()检查不变量是否得以保持

可以通过设置变量为Private fianl,但是也有缺陷(比如返回一个list),这时可以通过防御性拷贝即可。

OOP 的七大原则

一、单一职责原则 – SRP

(Single Responsibility Principle) 优化代码的第一步

一个类中应该是一组相关性很高的函数、数据的封装。

二、开闭原则 – OCP

(Open Close Principle) 让程序更稳定、更灵活

软件中的对象(类、模块、函数等)应该对于扩展是开放的,但是对于修改是封闭的。 在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会将错误引入原本已经经过测试的旧代码中,破坏原有系统。因此,当软件需要变化时,我们应该尽量通过扩展的方式来实现变化,而不是通过修改已有的代码来实现。

三、里氏替换原则 – LSP

(Liskov Substitution Principle) 构建扩展性更好的系统

有引用基类的地方必须能够透明地使用其子类的对象。 举个例子:如果对每一个类class1的对象o1,都有类class2的对象o2,使得以class1定义的所有程序P在所有对象o1都替换成o2的时候,程序P的行为都没有发生变化,那么类型class2是类型class1的子类型。

通俗点讲,只要父类出现的地方子类就可以出现,而且替换为子类也不会产生任何错误和异常。

四、依赖倒置原则 – DIP

(Dependence Inversion Principle) 让项目拥有变化的能力

依赖倒置原则指代了一种特定的解耦形式,使得高层次的模块不依赖与低层次的模块的实现细节的目的。

依赖倒置原则有以下几个关键点:

高层模块不应该依赖于底层模块,两者都应该依赖其抽象;
抽象不应该依赖细节;
细节应该依赖抽象。
依赖导致原则在Java语言中的表现就是:模块间的依赖关系通过抽象发生,实现类之间不发生直接依赖关系,其依赖关系是通过接口或抽象类产生的。 在编程过程中尽量面向接口编程,也就是说在写一个类前先写一个接口,然后用一个类来实现这个接口,通过面向接口编程,我们的程序就有了很高的扩展性,降低了类与类之间的依赖性,使实现类更依赖于接口,而不是其他实现类,提高了系统的稳定性。

五、接口隔离原则 – ISP

(Interface Segregation Principle) 系统有更高的灵活性

客户端不应该依赖于它不需要的接口。 另一种定义是:类间的依赖关系应该建立最小的接口上,不应该依赖于它不需要的接口。接口隔离原则将非常庞大的、臃肿的接口拆分成更小的和更具体的接口。简单来说就是接口应该尽量细分,使每一个类都没有它不需要实现的方法。

六、迪米特原则 – LOD

(Law of Demeter) 更好的可扩展性

一个对象应该对其他对象有最少的了解。 通俗的讲,一个类应该对自己需要耦合或调用的类知道的最少,类的内部如何实现与调用者或依赖者没关系,调用者或依赖者只需要知道它需要的方法即可。当我们在编写一个类时,这个类的属性能私有化就私有化,尽量不与其他类产生联系。一个对象应该对其他对象保持最少的了解,简单的理解就是高内聚,低耦合。

七、合成复用原则-CRP

(Conposite Reuse Principle)

尽量使用合成/聚合的方式,而不是使用继承。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注