以下为《软件设计模式笔记》的无排版文字预览,完整格式请下载
下载前请仔细阅读文字预览以及下方图片预览。图片预览是什么样的,下载的文档就是什么样的。
设计模式:
模式是在特定环境中解决问题的一种方案 、
软件模式:旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟。
软件模式是将模式的一般概念应用于软件开发领域,即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式,还包括架构模式、分析模式和过程模式等,实际上,在软件生存期的每一个阶段都存在着一些被认同的模式。
软件模式可以认为是对软件开发这一特定“问题”的“解法”的某种统一表示,它和Alexander所描述的模式定义完全相同,即软件模式等于一定条件下的出现的问题以及解法。软件模式的基础结构由4个部分构成:问题描述、前提条件(环境或约束条件)、解法和效果。
面向对象设计原则简介 :
单一职责原则(Single Responsibility Principle, SRP)定义如下:
一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。
另一种定义方式如下:
就一个类而言,应该仅有一个引起它变化的原因。
一个类(或者大到模块,小到方法)承担的职责越多,它被复用的可能性越小,而且如果一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作。
类的职责主要包括两个方面:数据职责和行为职责,数据职责通过其属性来体现,而行为职责通过其方法来体现。
开闭原则定义
开闭原则(Open-Closed Principle, OCP)定义如下:
一个软件实体应当对扩展开放,对修改关闭。也就是说在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,即实现在不修改源代码的情况下改变这个模块的行为。
抽象化是开闭原则的关键。
开闭原则还可以通过一个更加具体的“对可变性封装原则”来描述,对可变性封装原则(Principle of Encapsulation of Variation, EVP)要求找到系统的可变因素并将其封装起来。
依赖倒转原则定义
依赖倒转原则(Dependence Inversion Principle, DIP)的定义如下:
高层模块不应该依赖低层模块,它们都应该依赖抽象。抽象不应该依赖于细节,细节应该依赖于抽象。
另一种表述为:
要针对接口编程,不要针对实现编程。
简单来说,依赖倒转原则就是指:代码要依赖于抽象的类,而不要依赖于具体的类;要针对接口或抽象类编程,而不是针对具体类编程。
实现开闭原则的关键是抽象化,并且从抽象化导出具体化实现,如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要手段。
依赖倒转原则的常用实现方式之一是在代码中使用抽象类,而将具体类放在配置文件中。
类之间的耦合:
零耦合关系
具体耦合关系
抽象耦合关系
依赖倒转原则要求客户端依赖于抽象耦合,以抽象方式耦合是依赖倒转原则的关键
接口隔离原则:使用多个专门的接口来取代一个统一的接口
合成复用原则:在系统中应该尽量多使用组合和聚合关联关系,尽量少使用甚
至不使用继承关系
迪米特法则:一个软件实体对其他实体的引用越少越好,或者说如果两个类
不必彼此直接通信,那么这两个类就不应当发生直接的相互作
用,而是通过引入一个第三者发生间接交互
设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结,使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
设计模式一般有如下几个基本要素:模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式,其中的关键元素包括以 内容过长,仅展示头部和尾部部分文字预览,全文请查看图片预览。 个实例被创建。
单例模式的实现过程中,需要注意如下三点:
单例类的构造函数为私有;
提供一个自身的静态私有成员变量;
提供一个公有的静态工厂方法。
/
优点:提供了对唯一实例的受控访问。
缺点:由于单例模式中没有抽象层,因此单例类的扩展有很大的困难。
单例类的职责过重,在一定程度上违背了“单一职责原则”。
适用情况:
系统只需要一个实例对象
客户调用类的单个实例只允许使用一个公共访问点,除了该公共访问点,不能通过其他途径访问该实例。
在一个系统中要求一个类只有一个实例时才应当使用单例模式。反过来,如果一个类可以有几个实例共存,就需要对单例模式进行改进,使之成为多例模式。
[文章尾部最后300字内容到此结束,中间部分内容请查看底下的图片预览]请点击下方选择您需要的文档下载。
以上为《软件设计模式笔记》的无排版文字预览,完整格式请下载
下载前请仔细阅读上面文字预览以及下方图片预览。图片预览是什么样的,下载的文档就是什么样的。