编程思想
面向对象编程OOP
面向对象编程(Object Oriented Programming,OOP)思想是以现实世界中事物,建立模型体现出来的抽象思维过程。 根据抽象的模型,依照事物之间的关系及方法进行操作,以求达到重用性、灵活性和扩展性的设计目的。
面向对象编程是把构成问题的事务分解成各个对象,建立对象的目的不是为了完成一个步骤,而是为了描叙某个事物在整个解决问题的步骤中的行为。
OOP=对象+类+继承+多态+消息,其中核心概念是类和对象。
特点: 封装、多态、继承
优点:
- 结构清晰,程序是模块化和结构化,更加符合人类的思维方式;
- 易扩展,代码重用率高,可继承,可覆盖,可以设计出低耦合的系统;
- 易维护,系统低耦合的特点有利于减少程序的后期维护工作量。
缺点:
- 开销大,当要修改对象内部时,对象的属性不允许外部直接存取,所以要增加许多没有其他意义、只负责读或写的行为。这会为编程工作增加负担,增加运行开销,并且使程序显得臃肿。
- 性能低,由于面向更高的逻辑抽象层,使得面向对象在实现的时候,不得不做出性能上面的牺牲,计算时间和空间存储大小都开销很大。
面向过程编程POP
面向过程编程(Procedure-Oriented Programming,简记为POP),就是分析出解决问题所需要的步骤,然后用函数把这些步骤一步一步实现,使用的时候一个一个依次调用就可以了。
优点:
- 流程化使得编程任务明确,在开发之前基本考虑了实现方式和最终结果,具体步骤清楚,便于节点分析。
- 效率高,面向过程强调代码的短小精悍,善于结合数据结构来开发高效率的程序。
缺点:
- 需要深入的思考,耗费精力,代码重用性低,扩展能力差,后期维护难度比较大。
函数式编程
函数式编程类似于面向过程的程序设计,但其思想更接近数学计算。允许把函数本身作为参数传入另一个函数,还允许返回一个函数。是一种抽象程度很高的编程范式,纯粹的函数式编程语言编写的函数没有变量。
面向过程编程体现的是解决方法的步骤,而函数式编程体现的是数据集的映射
函数式编程关心数据的映射,命令式编程关心解决问题的步骤
六大设计原则
六大设计原则主要是指:
- 单一职责原则(Single Responsibility Principle): 一个类或接口只承担一个职责。
- 开闭原则(Open Closed Principle): 一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
- 里氏替换原则(Liskov Substitution Principle): 子类可以扩展父类的功能,但不能改变原有父类的功能。只要父类能出现的地方,子类就可以出现,而且替换为子类也不会产生任何错误或异常。
- 迪米特法则(Law of Demeter),又叫"最少知道法则" : 最少知道原则,尽量降低类与类之间的耦合
- 接口隔离原则(Interface Segregation Principle): 建立单一接口,类之间依赖关系应该建立在最小的接口上
- 依赖倒置原则(Dependence Inversion Principle): 面向接口编程,高层模块不应该依赖于低层模块,而应该依赖于抽象。抽象不应依赖于细节,细节应依赖于抽象
把这 6 个原则的首字母(里氏替换原则和迪米特法则的首字母重复,只取一个)联合起来就是:SOLID(稳定的),其代表的含义也就是把这 6 个原则结合使用的好处:建立稳定、灵活、健壮的设计。
单一职责原则
单一职责原则(Single Responsibility Principle):一个类或者一个方法只负责一项职责,尽量做到类的只有一个行为原因引起变化。
该原则适用于类、接口、方法。
单一职责的好处
- 复杂性降低,实现什么职责都有清晰明确的定义
- 可读性高,复杂性降低,可读性自然就提高了
- 可维护性提高,可读性提高了,那自然更容易维护了
- 变更引起的风险降低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,这对系统的扩展性、维护性都有非常大的帮助。
里氏替换原则
里氏替换原则(LSP liskov substitution principle):子类可以扩展父类的功能,但不能改变原有父类的功能。只要父类能出现的地方,子类就可以出现,而且替换为子类也不会产生任何错误或异常。
在面向对象的语言中,继承是必不可少的、非常优秀的语言机制,它有如下优点:
- 代码共享,减少创建类的工作量,每个子类都拥有父类的属性和方法
- 提高代码的重用性
- 子类可以形似父类,但又异于父类
- 提高代码的可扩展性
- 提高产品或项目的开放性。
继承是侵入性的。只要继承,就必须拥有父类的属性和方法。
- 降低代码的灵活性。子类会多一些父类的约束。
- 增强了耦合性。当父类的常量、变量、方法被修改时,需要考虑子类的修改。
依赖倒置原则
依赖倒置原则(dependence inversion principle):面向接口编程(通过接口作为参数实现应用场景),高层模块不应该依赖于低层模块,而应该依赖于抽象。抽象不应依赖于细节,细节应依赖于抽象。
含义:
- 上层模块不应该依赖下层模块,两者应依赖其抽象
- 抽象不应该依赖细节,细节应该依赖抽象
通俗点就是说变量或者传参数,尽量使用抽象类,或者接口。抽象就是接口或者抽象类,细节就是实现类。
依赖倒置原则的使用建议:
- 每个类尽量都有接口或抽象类,或者接口和抽象类两者都具备。
- 变量的表面类型尽量是接口或抽象类。
- 任何类都不应该从具体类派生。
- 尽量不要重写基类的方法。如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要重写。
- 结合里氏替换原则使用。
接口隔离原则
接口隔离原则(Interface Segregation Principle): 建立单一接口(扩展为类也是一种接口,一切皆接口)
定义:
- 客户端不应该依赖它不需要的接口;
- 类之间依赖关系应该建立在最小的接口上;
接口的设计粒度越小,系统越灵活,但是灵活的同时结构复杂性提高,开发难度也会变大,维护性降低。如一个臃肿的接口拆分为三个独立的接口所依赖的原则就是接口隔离原则
迪米特法则
迪米特原则(law of demeter LOD):最少知道原则,尽量降低类与类之间的耦合
迪米特法则的核心观念就是类间解耦,弱耦合,只有弱耦合了以后,类的复用率才可以提升上去。
如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,那就放置在本类中。
开闭原则
开闭原则(open closed principle): 指一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
为什么要用开闭原则
- 开闭原则非常著名,只要是做面向对象编程的,在开发时都会提及开闭原则。
- 开闭原则是最基础的一个原则,前面介绍的5个原则都是开闭原则的具体形态,而开闭原则才是其精神领袖。
- 开闭原则提高了复用性,以及可维护性。
MVC 模式
MVC是软件工程中的一种软件架构模式,把软件系统分为三个基本部分:模型(Model)、视图(View)和控制器(Controller)。经典MVC模式中,M是指业务模型,V是指用户界面,C则是控制器。
MVC模式的目的是实现一种动态的程式设计,使后续对程序的修改和扩展简化,并且使程序某一部分的重复利用成为可能。除此之外,此模式透过对复杂度的简化,使程序结构更加直观。
使用MVC的目的是将M和V的实现代码分离,从而使同一个程序可以使用不同的表现形式。其中,View的定义比较清晰,就是用户界面。
- 模型(Model) - 程序员编写程序应有的功能(实现算法等等)、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
- 视图(View) - 界面设计人员进行图形界面设计。
- 控制器(Controller) - 负责转发请求,对请求进行处理。