下载文档原格式
第一部分-------填空，选择，判断1．软件工程三个要素：方法、工具和过程2．软件元素：程序代码、测试用例、设计文档、设计过程、需求分析文档3．构件分类：关键字分类刻画分类法和超文本组织法4．软件体系结构技术反战经历四个阶段（1）无体系结构设计阶段----以汇编语言进行小规模应用程序开发（2）萌芽阶段-----以控制流图和数据流图构成软件结构为特征（3）初期阶段-----出现了从不同侧面描述系统的结构模型，UML（4）高级阶段-----描述系统的高层抽象结构，出现“4+1”模型5．软件体系结构模型：结构模型、框架模型、动态模型、过程模型和功能模型。
6．“4+1”视图模型从五个不同的视角，包括逻辑试图，进程试图，物理视图，开发视图和场景视图来描述软件体系结构。
逻辑视图主要支持系统的功能需求，是系统提供给最终用户的服务。
通过抽象，封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图；开发视图也称模块视图，主要侧重于软件模块的组织和管理，主要考虑软件内部的需求，如软件开发的容易性、软件的重用等，通过系统输入输出关系的模型图和子系统图来描述,提供给编程人员的；进程视图侧重于系统的运行特性，主要关注非功能性的需求，如系统的性能和可用性。
进程视图强调并发性、分布性、系统集成性和容错能力管道和过滤器风格、客户/服务器风格等适合进程视图，提供给系统集成人员的；物理视图主要考虑如何把软件映射到硬件上，它通常考虑系统性能、规模、可靠性等，解决系统拓扑结构、系统安装、通信问题,提供给系统工程人员的。
而场景是那些重要系统活动的抽象，它使四个视图有机联系起来，是最重要的需求抽象，它可以帮助设计者找到系统结构的构件和他们之间的作用关系。
总之，逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
软件体系结构的核心模型由五中元素组成：构件、连接件、配置、端口和角色。
7. 软件体系结构的核心模型由五中元素组成：构件、连接件、配置、端口和角色。
系统架构设计师笔记一、系统架构基础。
1. 定义与概念。
- 系统架构的含义：从整体上描述系统的组成结构、各组件的功能与关系，以及系统运行的原理等。
- 与软件工程的关系：系统架构是软件工程中的高层次设计，为软件项目的开发提供蓝图。
2. 架构风格。
- 分层架构。
- 优点：各层职责明确，易于维护和扩展。
例如，常见的三层架构（表示层、业务逻辑层、数据访问层），表示层负责与用户交互，业务逻辑层处理业务规则，数据访问层操作数据库。
- 缺点：层与层之间可能存在过度耦合的情况，如果分层不合理会影响系统性能。
- 客户端 - 服务器架构（C/S）- 特点：客户端负责用户界面展示和部分业务逻辑处理，服务器端负责数据存储和核心业务逻辑处理。
如早期的邮件客户端软件，客户端软件负责邮件的收发界面操作，服务器端存储邮件数据并进行邮件的转发等操作。
- 适用场景：适用于对交互性要求较高、网络环境相对稳定的应用，如企业内部管理系统。
- 浏览器 - 服务器架构（B/S）- 特点：用户通过浏览器访问服务器上的应用，服务器端承担更多的业务逻辑和数据处理。
例如，Web邮件系统，用户只需在浏览器中输入网址即可使用邮件服务，服务器端负责邮件的存储、收发和用户管理等功能。
- 适用场景：便于部署和更新，适用于广泛的互联网应用，用户无需安装专门的客户端软件。
3. 架构视图。
- 逻辑视图：描述系统的功能组件及其关系，从功能角度展示系统的结构。
例如，在一个电商系统中，逻辑视图可能包括用户管理模块、商品管理模块、订单管理模块等，以及它们之间的交互关系，如用户管理模块为订单管理模块提供用户信息。
- 物理视图：关注系统的硬件部署和软件安装情况。
电商系统的物理视图可能包括服务器的分布（如应用服务器、数据库服务器的部署位置），网络设备（路由器、防火墙等）的连接情况，以及软件在不同服务器上的安装情况。
- 进程视图：着眼于系统运行时的进程和线程情况。
在多用户的电商系统中，进程视图会描述订单处理进程、用户登录验证进程等的并发执行情况，以及进程之间的同步和通信机制。
第1章软件体系结构概述✓SEI软件体系结构讨论群定义如下：一个程序/系统构件的结构，它们之间的相互关系，以及在设计和交付的整个过程中的原则和指导方针。
✓Mary Shaw和David Garlan认为软件体系结构包括构成系统的设计元素的描述，设计元素的交互，设计元素组合的模式，以及在这些模式中的约束。
✓软件体系结构包括构件(Component)、连接件(Connector)和约束(Constrain)或配置(Configuration)三大要素。
✓国内普遍接受的定义：软件体系结构包括构件、连接件和约束，它是可预制和可重构的软件框架结构。
✓构件是可预制和可重用的软件部件，是组成体系结构的基本计算单元或数据存储单元✓连接件也是可预制和可重用的软件部件，是构件之间的连接单元✓构件和连接件之间的关系用约束来描述✓软件体系结构= 构件+ 连接件+ 约束软件体系结构的优势容易理解、重用、控制成本、可分析性第2章软件体系结构风格♦软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
♦体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。
词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
♦体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
♦数据流风格: 批处理序列; 管道/过滤器。
♦调用/返回风格：主程序/子程序；面向对象风格；层次结构。
♦独立构件风格：进程通讯；事件系统。
♦虚拟机风格：解释器；基于规则的系统。
♦仓库风格：数据库系统；超文本系统；黑板系统。
♦过程控制环路♦C/S风格体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。
♦B/S风格浏览器/Web服务器/数据库服务器。
优点：C/S体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。
将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。
1.软件设计的特征(1)软件设计的开端是出现某些新的问题需要软件来解决，这些需要促使设计工作的开始，并成为整个设计工作最初的基础(2)软件设计的结果是给出一个方案，它能够用来实现所需的、可以解决问题的软件，方案的描述可能是文字、图表，甚至数学符号、公式等组成的文档或模型(3)软件设计包含一系列的转换过程，即把一种描述或模型转换为另一种描述或模型，转换后的形态可能更加具体，或更接近于实现(4)产生新的想法或思路对软件设计非常重要，因为设计也是一个创造性的过程，不同的问题或需求总会存在各自的特点，即使同样的问题在不同时期和环境下也会存在区别，因此设计不会是一成不变的(5)软件设计的过程是不断解决问题和实施决策的过程，因为整个设计是解决一个大的问题，在设计过程中将会分解成众多小问题，涉及真需要一次解决这些小的问题，并在出现多种方案或策略时进行决策，选择其中最合适的(6)软件设计也是一个满足各种约束的过程，因为软件可能在性能、运行环境、开发时间、成本、人员技术水平等各个方面存在约束，设计必须在满足这些约束的情况下给出最佳的设计方案(7)大多数的软件实际是一个不断演化的过程，因为需求在一开始很可能是不完整或不精确的，在设计过程中还会不断发生变化并逐步稳定下来，因此设计需要根据需求的变化而不断演化。
2.软件设计的要素( 1 ) 目标描述 ( 2 ) 设计约束 ( 3 ) 产品描述 ( 4 ) 设计原理 ( 5 ) 开发规划 ( 6 ) 使用描述3.软件设计体系的定义( 1 )软件设计体系结构是软件系统的结构，包含软件元素、软件元素外部可见的属性以及这些软件元素之间的关系( 2 )软件体系结构是软件系统的基本组织，包含构建、构件之间、构件与环境之间的关系，以及相关的设计与演化原则4.软件设计的主要活动( 1 ) 软件设计计划 ( 2 ) 体系结构设计 ( 3 ) 界面设计 ( 4 ) 模块/子系统设计 ( 5 ) 过程/算法设计( 6)数据模型设计5.体系结构“4+1 ”多视图建模( 1 )逻辑视图：该视图关注功能需求，即系统应该为最终用户提供什么服务，它与应用领域精密相关( 2 )进程视图：该视图捕获设计中关于并发和同步的内容，重视一些非功能需求，例如性能、可扩展性等，定义了运行实体和它们的属性。
1、构件是核心和基础，重用是必需的手段。
2、软件重用是指在两次或多次不同的软件软件开发过程中重复使用相同或相近软件元素的过程。
3、软件元素包括程序代码、设计文档、设计过程、需求分析文档甚至领域知识。
4、把可重用的元素称作软构件，简称为软构件。
5、可重用软件元素越大，就说重用的粒度越大。
6、构件是指语义完整、语法正确和有可重用价值的单位软件，是软件重用过程中可以明确辨识的系统；结构上，它是语义描述、通信接口和代码实现的复合体。
7、面向对象技术达到类级重用，以类为封装的单位。
8、构件模型是对构件本质特征的抽象描述。
三个主要流派，分别是OMG(对象管理组织)的CORBA（通用对象请求代理结构)、Sun的EJB和Microsoft的DOM（分布式构件对象模型）。
9、获取构件的四个途径：（1）从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用构件。
（2）通过遗留工程，将具有潜在重用价值的构件提取出来，得到可重用构件。
（3）从市场上购买现成的商业构件，即COTS构件。
（4）开发符合要求的构件。
10、构件分类方法三大类：关键字分类、刻面分类法、超文本组织方法11、构件检索方法：基于关键字的检索、刻面检索法、超文本检索法和其他检索方法。
12、减少构件修改的工作量，要求工作人员尽量使构件的功能、行为和接口设计更为抽象画、通用化和参数化。
13、构件组装技术：基于功能的组装技术、基于数据的组装技术和面向对象的组装技术。
14、软件体系结构的定义：软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
软件体系结构的意义：（1）体系结构是风险承担者进行交流的手段；（2）体系结构是早期设计决策的体现--①软件体系结构明确了对系统实现的约束条件②软件体系结构决定了开发和维护组织的组织结构③软件体系结构制约着系统的质量属性④通过研究软件体系结构可能预测软件的质量⑤软件体系结构使推理和控制更改更简单⑥软件体系结构有助于循序渐进的原型设计⑦软件体系结构可以作为培训的基础；（3）软件体系结构是可传递和可重用的模型。
软件设计与体系结构知识点1.引言1.1 概述在软件设计与体系结构的研究领域，了解相关知识点对于开发高质量、可维护和可扩展的软件至关重要。
软件设计是关于如何将需求转化为实际可行的软件系统的过程，而软件体系结构则是指软件系统的整体结构和组织方式。
本文将介绍一些重要的软件设计和体系结构的知识点。
在软件设计方面，我们将讨论一些常用的设计原则和设计模式。
设计原则是经验总结出的指导性原则，可以帮助开发人员在设计软件时做出合理的决策。
其中一些著名的设计原则包括开闭原则、单一职责原则和依赖倒置原则等。
设计模式则是在设计过程中反复出现的问题的解决方案，它们提供了可复用的设计思想和模板。
一些广为人知的设计模式有观察者模式、工厂模式和适配器模式等。
而在软件体系结构方面，我们将探讨一些常见的体系结构模式。
分层架构是一种常见的体系结构模式，它将系统划分为多个层次，每个层次负责不同的功能。
这种分层的结构可以提高系统的可复用性和可扩展性。
另外，客户-服务器架构也是一种常见的体系结构模式，它将软件系统划分为客户端和服务器端两个部分，客户端发送请求，服务器端处理请求并返回结果。
这种架构模式可以实现系统的分布式部署和协作处理。
通过本文的学习，读者将能够掌握一些重要的软件设计原则和设计模式，了解常见的软件体系结构模式，并能够在实际的软件开发过程中应用它们。
这些知识点对于开发高质量的软件系统以及应对未来软件发展的挑战都具有重要意义。
接下来的章节将详细介绍这些知识点，并总结归纳它们的应用场景和优缺点。
文章结构部分的内容可以写成以下方式：1.2 文章结构本文将围绕软件设计与体系结构的知识点展开详细介绍。
首先，在引言部分，我们将概述本文的主要内容并介绍文章的结构。
接着，我们将在正文部分分为两个主要部分，分别是软件设计知识点和软件体系结构知识点。
在软件设计知识点部分，我们将深入探讨设计原则和设计模式的概念与应用。
而在软件体系结构知识点部分，我们将介绍分层架构和客户-服务器架构的原理和特点。
第五章-信息系统⼯程1-软件⼯程1.1-架构设计1.软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述，构件的相互作用（连接体）、指导构件集成的模式以及这些模式的约束组成。
2.软件架构主要研究内容涉及软件架构描述、软件架构风格。
软件架构评估和软件架构的形式化方法等。
3.研究软件架构的根本目的是解决好软件的复用、质量和维护问题。
4.软件架构设计的一个核心问题是能否达到架构级的软件复用，也就是说，能否在不同的系统中使用同一个架构软件。
软件架构风格是描述某一个特定应用领域找那个系统组织方式的惯用模式。
5.通用软件架构：数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。
6.数据流风格：包括批处理序列和管道/过滤器两种风格。
7.调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。
8.独立构件风格包括进程通信和事件驱动的系统9.虚拟机⻛格包括解释器和基于规则的系统。
10.仓库⻛格包括数据库系统、⿊板系统和超⽂本系统。
11.在架构评估过程中，评估⼈员所关注的是系统的质量属性。
1.2-需求分析1.虚拟机⻛格包括解释器和基于规则的系统。
需求是多层次的，包括业务需求、⽤户需求和系统需求，这三个不同层次从⽬标到具体，从整体到局部，从概念到细节。
2.业务需求：指反映企业或客户对系统⾼层次的⼀个⽬标追求，通常来⾃项⽬投资⼈、购买产品的客户、客户单位的管理⼈员、市场营销部⻔或产品策划部⻔等。
3.⽤户需求：描述的是⽤户的具体⽬标，或者⽤户要求系统能完成的任务，⽤户需求描述了⽤户能让系统来做什么。
4.系统需求：是指从系统的⻆度来说明软件的需求，包括功能需求，⾮功能需求和设计约束。
5.质量功能部署QFD是⼀种将⽤户要求转化成软件需求的技术，其⽬的是最⼤限度地提升软件⼯程过程中⽤户的满意度。
为了达到这个⽬标，QFD将需求分为三类，分别是常规需求、期望需求和意外需求。
6.需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。
第1章软件体系结构概述✓SEI软件体系结构讨论群定义如下：一个程序/系统构件的结构，它们之间的相互关系，以及在设计和交付的整个过程中的原则和指导方针。
✓Mary Shaw和David Garlan认为软件体系结构包括构成系统的设计元素的描述，设计元素的交互，设计元素组合的模式，以及在这些模式中的约束。
✓软件体系结构包括构件(Component)、连接件(Connector)和约束(Constrain)或配置(Configuration)三大要素。
✓国内普遍接受的定义：软件体系结构包括构件、连接件和约束，它是可预制和可重构的软件框架结构。
✓构件是可预制和可重用的软件部件，是组成体系结构的基本计算单元或数据存储单元✓连接件也是可预制和可重用的软件部件，是构件之间的连接单元✓构件和连接件之间的关系用约束来描述✓软件体系结构= 构件+ 连接件+ 约束软件体系结构的优势容易理解、重用、控制成本、可分析性第2章软件体系结构风格♦软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
♦体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。
词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
♦体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
♦数据流风格: 批处理序列; 管道/过滤器。
♦调用/返回风格：主程序/子程序；面向对象风格；层次结构。
♦独立构件风格：进程通讯；事件系统。
♦虚拟机风格：解释器；基于规则的系统。
♦仓库风格：数据库系统；超文本系统；黑板系统。
♦过程控制环路♦C/S风格体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。
♦B/S风格浏览器/Web服务器/数据库服务器。
优点：C/S体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。
将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。
缺点：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一，使用繁杂不利于推广使用、软件移植困难、软件维护和升级困难、新技术不能轻易应用优点：基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。
缺点：B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
B/S体系结构的系统扩展能力差，安全性难以控制。
采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远低于C/S体系结构。
B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。
第3章软件需求与架构♦需求的基本概念✓IEEE (1997)➢(1) 用户解决问题或达到目标所需的条件或能力➢(2) 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力➢(3) 一种反映上面（1）或（2）所描述的条件或能力的文档说明♦业务需求✓反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求♦用户需求✓描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。
♦系统需求✓从系统的角度来说明软件的需求，包括用特性说明的功能需求、质量属性，以及其他非功能需求，还有设计约束等。
♦非功能需求✓指产品必须具备的属性或品质，如正确性、可靠性、性能、容错性和可扩展性等。
♦功能需求✓需求的主体，需求的本质✓功能需求定义：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作♦设计约束♦获取需求的方法✓面谈（访谈）✓问卷调查✓会议（需求讨论会、重点问题讨论会、业务专题讨论会、设计专题讨论会）✓文档研究✓任务示范（观察）✓用例与角色扮演✓原型设计（小规模试验）研究类似公司♦需求的层次化✓业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。
✓用户级需求：用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？✓开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？♦需求分类✓功能需求：更多体现各级直接目标要求✓质量属性：运行期质量+ 开发期质量✓约束需求：业务环境因素+ 使用环境因素+ 构建环境因素+ 技术环境因素✓功能模型——如UC✓业务流程模型——如DFD✓数据建模模型——如ER♦用例建模（Use Case Modeling）是使用用例的方法来描述系统的功能需求的过程，用例建模促进并鼓励了用户参与，这是确保项目成功的关键因素之一。
♦粒度原则：♦用例要有路径，路径要有步骤。
而这一切都是“可观测”的。
✓需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。
♦外部质量对于用户而言是可见的包括正确性、健壮性、可靠性、性能、安全性、易用性、兼容性等。
♦内部质量只有开发人员关心它们可以帮助开发人员实现外部质量包括易理解性、可测试性、可维护性、可扩展性、可移植性、可复用性等✓依赖注入♦构造注入(Constructor Injection)：通过构造函数注入实例变量。
♦设值注入(Setter Injection)：通过Setter方法注入实例变量。
♦接口注入(Interface Injection)：通过接口方法注入实例变量。
1.用例文档♦用例编号♦用例名♦执行者♦前置条件♦后置条件♦涉众利益♦基本路径✓1…..××××✓2……××××✓3…..××××2.需求规格说明书第1章_统一建模语言基础知识a)视图(View)i.用户视图：以用户的观点表示系统的目标，它是所有视图的核心，该视图描述系统的需求。
ii.结构视图：表示系统的静态行为，描述系统的静态元素，如包、类与对象，以及它们之间的关系。
iii.行为视图：表示系统的动态行为，描述系统的组成元素如对象在系统运行时的交互关系。
iv.实现视图：表示系统中逻辑元素的分布，描述系统中物理文件以及它们之间的关系。
v.环境视图：表示系统中物理元素的分布，描述系统中硬件设备以及它们之间的关系。
用例图(Use Case Diagram): 又称为用况图，对应于用户视图。
在用例图中，使用用例来表示系统的功能需求，用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。
用例图与用例说明文档(Use Case Specification)是常用的需求建模工具，也称之为用例建模。
类图(Class Diagram)：对应于结构视图。
类图使用类来描述系统的静态结构，类图包含类和它们之间的关系，它描述系统内所声明的类，但它没有描述系统运行时类的行为。
♦类之间的关系✓关联关系•关联关系(Association)是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系。
•双向关联•单向关联•自关联•重数性关联✓聚合关系•聚合关系(Aggregation)表示一个整体与部分的关系。
通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。
✓组合关系•组合关系(Composition)也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。
一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。
✓依赖关系•依赖关系(Dependency)是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。
大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。
✓泛化关系•泛化关系(Generalization)也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。
在UML中，泛化关系用带空心三角形的直线来表示。
✓接口与实现关系•接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系(Realization)，在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。
在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。
♦顺序图定义✓顺序图(Sequence Diagram)是一种强调对象间消息传递次序的交互图，又称为时序图或序列图。
♦状态图定义✓状态图(Statechart Diagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。
第2章_面向对象设计原则♦单一职责原则要求在软件系统中，一个类只负责一个功能领域中的相应职责。
♦开闭原则要求一个软件实体应当对扩展开放，对修改关闭，即在不修改源代码的基础上扩展一个系统的行为。
♦里氏代换原则可以通俗表述为在软件中如果能够使用基类对象，那么一定能够使用其子类对象。
♦依赖倒转原则要求抽象不应该依赖于细节，细节应该依赖于抽象；要针对接口编程，不要针对实现编程。
♦接口隔离原则要求客户端不应该依赖那些它不需要的接口，即将一些大的接口细化成一些小的接口供客户端使用。
♦合成复用原则要求复用时尽量使用对象组合，而不使用继承。
♦迪米特法则要求一个软件实体应当尽可能少的与其他实体发生相互作用。
第3章_设计模式概述♦设计模式的定义✓设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
✓设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式，其中的关键元素包括以下四个方面：♦模式名称(Pattern name)♦问题(Problem)♦解决方案(Solution)♦效果(Consequences)第4章_简单工厂模式✓简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。
在简单工厂模式中，可以根据参数的不同返回不同类的实例。
简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
✓重构后的代码：public abstract class AbstractPay{public abstract void pay();}public class CashPay extends AbstractPay{public void pay(){//现金支付处理代码}}public class PayMethodFactory{public static AbstractPay getPayMethod(String type){if(type.equalsIgnoreCase("cash")){return new CashPay(); //根据参数创建具体产品}else if(type.equalsIgnoreCase("creditcard")){return new CreditcardPay(); //根据参数创建具体产品}……}}✓简单工厂模式最大的缺点是当有新产品要加入到系统中时，必须修改工厂类，加入必要的处理逻辑，这违背了“开闭原则”。
