内聚

网上有许多讲组件化开发、模块化开发的文章，但大家一般都是将这两个概念混为一谈的，并没有加以区分。而且实际上许多人对于组件、模块的区别也不甚明了，甚至于许多博客文章专门解说这几个概念都有些谬误。 想分清这两个概念我觉得结合一下软件的渐进式开发场景更容易理解。但是下面的篇幅会比较长，所以我先说结论，不耐烦的同学可以先看： 概念区别 对比 说明 l 组件： 最初的目的是代码重用，功能相对单一或者独立。在整个系统的代码层次上位于最底层，被其他代码所依赖，所以说组件化是纵向分层。 l 模块 ：最初的目的是将同一类型的代码整合在一起，所以模块的功能相对复杂，但都同属于一个业务。不同模块之间也会存在依赖关系，但大部分都是业务性的互相跳转，从地位上来说它们都是平级的。 因为从代码组织层面上来区分，组件化开发是纵向分层，模块化开发是横向分块，所以模块化并没有要求一定组件化。也就是说你可以只做模块化开发，而不做组件化开发。那这样的结果是什么样的呢？就是说你的代码完全不考虑代码重用，只是把相同业务的代码做内聚整合，不同模块之间还是存在大量的重复代码。这样的成果也算是做到了模块化，只不过我们一般不会这样而已。 和组件模块近似的一对概念是库和框架。库的概念偏近于代码的堆集，是分层的概念，所以对应组件化。框架是结构化的代码，所以应用于模块化。框架是骨，模块化是肉。 讲到这给大家介绍一个快速开发平台

本文算是《领域驱动设计》这本书的读书笔记，加上自己的一些读后感。网上有很多这本书的读书笔记，但是都是别人的，不如自己总结的理解深刻。建议大家在读这本书时结合《实现领域驱动设计》一起看，同时，一定要去实际建模和编码，理论联系实际才能得其精髓。 本文是【DDD】系列文章的第一篇，可参考： 使用领域驱动设计思想实现业务系统 定义 DDD是Domain driven design（领域驱动设计）的简称，是一种软件设计和开发的方法论，特别适用于复杂业务领域软件设计和开发。可参考wiki： Domain-driven_design 核心 将所有业务逻辑内聚到业务领域（domain）层，将设计和开发的关注点聚焦到业务领域； 建立通用的‘业务领域语言（Ubiquitous Language）’，Ubiquitous Language是工程师和业务领域专家（可以是产品经理、运营、业务相关人员）的桥梁； 战略上，通‘上下文（Bounded Context）’解耦各个业务系统/组件，通过‘防腐层（Anticorruption layer）’确保自有业务领域不受外界污染，通过‘开放主机服务（Open Host Service）’向外界公开服务； 战术上，将业务对象建模为entity和value object，entity有唯一业务标识且在其生命周期中状态可变，value object与之相反

软件分析 用户和开发者都会关心软件的需求，都希望通过需求分析弄清楚 “需要软件做什么”，但他们理解问题的角度却各不相同。一般来说，用户只注重软件的外在表现，即软件需求。开发者更加关注软件的内部逻辑，称为软件分析。前者从软件使用者角度出发，而后者则是从软件开发者的角度出发 这里首先介绍以下软件分析这一过程，具体采用什么方式实现这一过程，在之后的文章会给出答案 软件设计 软件设计的任务是将分析阶段建立的分析模型转变为软件设计模型。这一过程需要细化解决方案的可视化设计模型，确保设计模型最终能平滑过渡到程序代码。分析模型强调软件应该做什么，设计模型回答该怎么做的问题 特点 模块与构件 模块是一个拥有明确输入、输出和特性的程序实体。如果模块的所有输入都是实现功能必不可少的，所有输出都有动作产生，即成为定义明确的模块。对象也是一种模块，由于对象自我封闭的特点，因而更容易在软件设计中被重复使用，这种可重复使用的软件组件称为软件构件 抽象与细化 抽象是控制复杂性的基本策略之一。抽象是分层次的，在软件的抽象层次中，最高层抽象程度最高，若需要系统某部分细节，可移向较低层次的抽象 软件设计其实就是在不同抽象级别考虑和处理问题的过程。首先在最高级抽象级别上，概括问题解的形式；然后不断具体化，降低抽象级别；最后在最低的抽象级别上给出实现问题的解，即源代码。在由高级抽象到低级抽象转换的过程中

# Spring 第一天 ##Spring大纲内容 SpringIOC容器 ​ Spring依赖注入 ​ Spring中Bean的声明周期 重点：SpringIOC容器和Spring依赖注入都作为重点。 注入方式：set注入方式、构造函数注入方式、集合注入 创建Bean方式：构造函数创建、静态工厂创建、普通工厂创建 第1章 Spring 概述 1.1 spring 概述[了解] 1.1.1 spring 是什么 Spring 是分层的 Java SE/EE 应用 full-stack 轻量级开源框架，以 IoC（Inverse Of Control：反转控制）和 AOP（Aspect Oriented Programming：面向切面编程）为内核，提供了展现层 SpringMVC 和持久层 Spring JDBC 以及业务层事务管理等众多的企业级应用技术，还能整合开源世界众多著名的第三方框架和类库，逐渐成为使用最多的 Java EE 企业应用开源框架。 1.1.2 Spring 的发展历程 1997 年 IBM 提出了 EJB 的思想 1998 年， SUN 制定开发标准规范 EJB1.0 1999 年， EJB1.1 发布 2001 年， EJB2.0 发布 2003 年， EJB2.1 发布 2006 年， EJB3.0 发布 Rod Johnson（spring 之父）

耦合度 一、什么是耦合度 软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分摸块的一个准则就是高内聚低耦合。 耦合度 (Coupling)是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。 模 块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越 差。降低模块间的耦合度能减少模块间的影响，防止对某一模块修改所引起的“牵一发动全身”的水波效应，保证系统设计顺利进行。 内 聚和耦合密切相关，同其它模块存在强耦合关系的模块常意味这弱内聚，强内聚常意味着弱耦合。 耦合度就是某模块（类）与其它模块（类）之间的关联、感知和依赖的程度，是衡量代码独立性的一个指标，也是软件工程设计 及编码质量评价的一个标准。耦合的强度依赖于以下几个因素： （1）一个模块对另一个模块的调用； （2）一个模块向另一个模块传递的数据量； （3）一个模块施加到另一个模块的控制的多少； （4）模块之间接口的复杂程度。 耦合按从强到弱的顺序可分为以下几种类型： a)非直接耦合：两模块间没有直接关系，之间的联系完全是通过主模块的控制和调用来实现的 　　 b)数据耦合：一个模块访问另一模块，彼此间通过简单数据参数来交换输入、输出信息。这里的简单数据参数不同于控制参数、公共数据结构或外部变量。 　

程序的三种基本控制结构： 顺序 选择 重复 面向对象的分析方法主要是建立： 对象模型 动态模型 功能模型 模块独立性的衡量标准： 耦合性 内聚性 软件开发是 自顶向下逐步求精 ；软件测试是 自底向上集成 面型对象： 多态性 唯一性 封装性 继承性 功能内聚 内聚性最高； 偶然内聚 内聚程度最低 继承性是子类自动共享其父类的 数据结构和方法 白盒覆盖测试六种覆盖方法中，由 弱 至 强 ：语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖 软件测试用例主要由 测试输入数据 和 测试的预期结果 组成 E-R图包含： 实体 联系 属性 数据流图包括： 处理 数据流 动作对象 数据存储对象 着重描述数据对象及数据对象之间的关系 分层数据流图：顶层数据流图描述了系统的 输入与输出 软件结构图： 扇入 指一个模块的直接上级模块个数，能反映程序重用率； 扇出 指一个模块的直接下级模块个数； 宽度 指同一层次上的模块总数最大值 对象图：用于描述对象模型 层次图：软件结构使用的图形工具 SC图：软件结构化设计（总体设计）使用的图形工具；详细设计与概要设计衔接的图形工具 PAD图：经常用于详细设计阶段 McCall模型：适应性属于面向软件产品修改 COCOMO模型：用于成本估算 螺旋模型：引入了“风险驱动”思想，适用于大规模的内部开发项目 瀑布模型：缺乏灵活性 喷泉模型

请选择一种我们课程中介绍的设计模式，用您熟悉的编程语言提供一个典型的应用范例，并分析其代码结构特性。完成一篇研究报告，具体要求如下： 引用关键代码（引用代码是为解释说明服务的，不要贴对解释问题无关的代码）解释该设计模式在该应用场景中的适用性； 引入该设计模式后对系统架构和代码结构带来了哪些好处； 解释其中用到的多态机制； 说明模块抽象封装的方法； 分析各个模块的内聚度和模块之间的耦合度； 提供该应用范例完整的源代码包括构建部署的操作过程，建议以github版本库URL的方式提供源代码，其中README.md中说明构建部署的操作过程。 如下为图像分辨率增强项目 生成式对抗网络GAN近年来复杂分布上无监督学习最具前景的方法之一。模型通过框架中（至少）两个模块：生成模型（Generative Model）和判别模型（Discriminative Model）的互相博弈学习产生相当好的输出。 SRGAN旨在增强图像分辨率，是在keras框架上的代码实现。 如上目录，首先使用VGG19进行特征提取，使用迁移学习可以节省大量的训练时间，imagenet的初始权重本身在图像类任务上具有十分优秀的效果，用来做特征提取可以有效的获取图片的有效特征信息。 接下来是生成器和判别器的构建，因为GAN的原理就是通过在这两个容器上进行相互博弈缩小损失函数的期望值，最终来产生比较好的输出，下为构建模型。

简单理解一下内聚和耦合。 什么是模块 模块就是从逻辑上将系统分解为更细微的部分，分而治之。 复杂问题因为复杂性的问题，比较难解决，但是可以将复杂问题拆解为若干简单问题，逐个击破地解决这些简单问题，最后实现解决复杂问题的效果。 模块的粒度划分可大可小，可以是函数，类或功能块等等。 耦合主要描述的是模块与模块之间的关系，内聚则主要描述的是单个模块的内部构成。 什么是耦合 如果模块之间存在依赖，则可能会导致一个模块的改动影响了另外的模块的问题，甚至是相互影响。 两个模块之间的关系越紧密，耦合就越强，模块的独立性就会越差。 比如一个模块A直接操作了模块B中数据，则视为强耦合；若A只是通过数据与模块B交互，则视为弱耦合。 独立的模块便于扩展、维护和单元测试，如果模块之间重重依赖的话，就会极大降低开发效率。 什么是内聚 一个模块应当尽可能独立完成某个功能，模块内部的元素关联性越强，则内聚越高，模块单一性就越强。 如果有各种场景需要被引入到当前模块，代码的质量将变得非常脆弱，这种情况建议拆分为多个模块。 低内聚的模块代码，不管是维护、扩展还是重构都相当麻烦。因为要兼顾内部元素的关联性，如果不理清楚的话可能会难以下手。 接口设计原则 好的接口应当满足设计模式六大原则，很多的设计模式或框架都是基于高内聚低耦合这个出发点的。 1.单一职责原则：一个类只负责一个功能领域中的相应职责。 2.开闭原则

设计模式（Design Pattern）一般指的是面向对象的二十三种设计模式，模式的解释是在某些场景下，针对某类问题的某种通用的解决方案。所谓设计模式就是一套被反复使用、经过分类的、代码设计经验的总结。使用设计模式的目的无非是为了在构架系统时保持高可扩展，高内聚，低耦合的特性，清晰，灵活，稳定的框架。 为何要让系统保持如何使系统保持高可扩展，高内聚，低耦合的特性的呢？ 首先高扩展意味着系统在开发过程中和开发完成后的升级中都能简单易行，可以比较容易的适应需求的变化改进系统。 内聚和耦合是模块独立程度的两个定性衡量标准，模块的独立使得软件开发，测试和维护都较为容易。模块化的设计使得系统功能可以分割，接口可以简化，分配给开发组中不同的人实现不同的功能；模块化的设计能使得修改设计和程序的工作量比较小，系统发生错误传播范围被限制，需要扩充时能插入模块。 什么耦合和内聚： 耦合是一个软件结构内模块之间的互连程度的度量，模块间的耦合程度强烈影响系统的可理解性，可测试性，可靠性和可维护性。耦合度从高到低： 内容耦合（content coupling） ：直接使用另一模块的内部数据/通过非正常入口进入模块内部。（一个模块可以通过非正常入口访问另一个模块内部，一个模块可以访问另一个模块的内部数据，两个模块一部分代码重叠，一个模块有多个入口） 公共耦合（common coupling ）

内聚与耦合 耦合性 ：也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。 模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。 内聚性 ：又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语句之间、程序段之间）联系的越紧密，则它的内聚性就越高。 内聚 内聚 ：故名思议，表示内部间聚集、关联的程度，那么高内聚就是指要高度的聚集和关联。高内聚是指类与类之间的关系而定，高，意思是他们之间的关系要简单，明了，不要有很强的关系，不然，运行起来就会出问题。一个类的运行影响到其他的类。由于高内聚具备可靠性，可重用性，可读性等优点，模块设计推荐采用高内聚。内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系。 偶然内聚：一个模块内的各处理元素之间没有任何联系，只是偶然地被凑到一起。这种模块也称为巧合内聚，内聚程度最低。 逻辑内聚：这种模块把几种相关的功能组合在一起， 每次被调用时，由传送给模块参数来确定该模块应完成哪一种功能 。 时间内聚：把需要同时执行的动作组合在一起形成的模块称为时间内聚模块。 过程内聚：构件或者操作的组合方式是