软件开发杂谈

原创已于 2025-06-24 21:16:57 修改 · 328 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#软件工程

于 2025-06-11 20:58:50 首次发布

面向对象编程思想

高内聚，低耦合是最基本原则

四大特征

继承
抽象
多态
封装

五种关系

关联

类之间的特定对应关系

聚集

整体与部分之间的关系

泛化

类之间的继承关系

实现

类与接口之间的关系

依赖

类之间的调用关系

七大原则

单一职责

职责要精要且内聚高。
单一职责要与抽象层次相匹配，越高层的模块其职责越抽象，因此高层的模块要实现单一职责要依赖抽象。

比如底层模块要实现某个职责可能就是某个方法的具体实现；然而一个高层模块要实现职责一定是调用底层类而非直接实现该方法。

量化标准：当模块的修改原因只有一个时，算满足单一职责。

开放封闭

对扩展开放，对修改封闭。
实际上，功能要变动时，修改一定会发生，只是发生的位置要正确，并且要事先预留位置。
通过抽象定义修改点位置，通过多态（也可以是其他）实现扩展。
一般来讲，当发生功能修改或扩展时，根据功能对应的抽象等级，要修改抽象等级小于等于功能抽象等级且为预留修改点的模块。
如果一个很高级很抽象的功能要发生变动，自然一些高级模块要进行修改。但是一般情况下变动的都是低级的具体的功能，对应修改的也应该是低级模块，不能动高级模块。

对变化进行抽象：
一般变化频率越高，且变化的抽象等级高的地方，抽象等级越高。

我们要通过抽象建立更稳定的接口以减少变化。
我们希望变化多发生于底层，越高层的模块变化越少。

里氏替换

子类继承父类时，可以添加新方法增加新功能，但尽量不要重载或重写父类的方法

父类中定义好的一系列方法（抽象方法除外），实际上是一种约定规范，任意修改会增大不确定性，甚至发生故障

依赖注入（依赖倒置）

底层和高层模块都不应相互依赖，都应依赖于抽象
抽象本身由高层定义，实现方式有接口依赖、注入函数依赖等，底层实现抽象。
可以这样理解：要面向抽象（接口）编程。而非面向实现编程。

接口隔离原则

暴露的接口都是必要的，且越细分越好，尽量不出现“胖接口”。

根据实际，且逐步优化，好的架构都是逐步优化的

最小知识原则（迪米特法则）

一个类暴露的信息越少越好

低耦合的具体实现之一

合成复用原则：

多使用对象组合而非继承

has a && is a

总结

开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭。
里氏替换原则，告诉我们不要破坏继承体系。
依赖倒置原则，告诉我们要面向接口编程。
单一职责原则，告诉我们类的职责要单一。
接口隔离原则，告诉我们要在设计接口时精而简单。
迪米特法则，告诉我们要降低耦合度。
合成复用原则，告诉我们要多用组合或聚合关系，少用继承复用关系

设计模式

总览

创建型模式

工厂方法模式抽象工厂模式建造者模式单例模式原型模式

结构型模式

适配器模式装饰器模式代理模式外观模式桥接模式组合模式享元模式

行为型模式

策略模式模板方法模式观察者模式迭代子模式责任链模式命令模式
备忘录模式状态模式访问者模式中介者模式解释器模式

创建型模式

用来创建对象的模式，抽象了实例化过程

抽象工厂模式

抽象工厂模式包含工厂模式
概述

为一个产品族提供统一的创建接口。当需要这个产品族的某一系列的时候，可以从抽象工厂中选出相应的系列创建一个具体的工厂类

在这里插入图片描述
多个抽象产品类，每个抽象产品类可以派生出多个具体产品类
一个抽象工厂类，可以派生出多个具体工厂类
每个具体工厂类可以创建多个具体产品类的实例

建造者模式

概述

将复杂对象创建与表示分离，同样的创建过程可创建不同的表示。允许用户通过指定复杂对象类型和内容来创建对象，用户不需要知道对象内部的具体构建细节；

在这里插入图片描述
Builder：为创建一个Product对象的各个部件指定抽象接口
ConcreteBuilder：实现Builder接口来构造和装配产品各个部件，提供一个检索产品的接口
Director：构造一个使用Builder接口的对象
Product：表示被构造的复杂对象

单例模式

保证一个类有且仅有一个实例，提供一个全局访问点

原型模式

概述

通过“复制”一个已经存在的实例来返回新的实例（不新建实例）

在这里插入图片描述
客户：客户端类向原型管理器提出创建对象请求
抽象原型：它是对各种具体原型的抽象，通常由一个接口或抽象类实现
具体原型：被复制的对象。此角色需要实现抽象的原型角色所要求的接口
原型管理器：创建具体原型类的对象，记录每一个被创建的对象

结构型模式

结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象来实现新的功能（对象结构型模式）

适配器模式

适配器(Adapter)模式：将一个类的接口适配成用户所期待的接口。一个适配器允许因为接口不兼容而不能在一起工作的类工作在一起，做法是将类自己的接口包装在一个已存在的类中；

在这里插入图片描述

组合模式

组合（Composite）模式：定义一个接口，使之用于单一对象，也可以应用于多个单一对象组成的对象组；

在这里插入图片描述
是一个树形结构，leaf是叶节点（单一对象），component代表子树（子组合）

装饰器

装饰器（Decorator）模式：给对象动态添加额外的职责，就好像给一个物体加上装饰物，完善其功能；
不改变接口，但加入责任。

在这里插入图片描述

Component
对象接口：可以给对象动态地添加职责
ConcreteComponent
具体对象,被装饰的对象
Decorator
维持一个指向Component对象的指针，并定义一个与Component接口一致的接口
ConcreteDecorator
向组件添加职责
Decorator将请求转发给它的Component对象，并有可能在转发请求前后执行一些附加的动作

装饰器与继承

使用Decorator模式可以很容易地向对象添加职责。可以用添加和分离的方法，在运行时添加和删除职责;
使用Decorator模式可以很容易地重复添加一个特性，而两次继承则极容易出错;
避免在层次结构高层的类有太多的特征：可以从简单的部件组合出复杂的功能。具有低依赖性和低复杂性;

外观模式

外观（Facade）模式：外观模式为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度，使子系统更易于使用和管理。外观承担了子系统中类交互的责任；

在这里插入图片描述
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。外观模式提供一个高层的接口，使得子系统更易于使用

行为型模式

着力解决的是类实体之间的通讯关系，希望以面向对象的方式描述一个控制流程
模版（Template ）模式：定义了一个算法步骤，并允许子类为一个或多个步骤提供实现。子类在不改变算法架构的情况下，可重新定义算法中某些步骤；

迭代子（Iterator）模式：提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示；
责任链（Chain of Responsibility）模式：很多对象由每一个对象对其下一个对象的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使系统可以在不影响客户端的情况下动态的重新组织链和分配责任
状态（State）模式：允许一个“对象”在其内部状态改变的时候改变其行为，即不同的状态，不同的行为

解释器(Interpreter) 模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子
中介者（Mediator）模式：用一个中介对象来封装一系列的对象交互
策略（Strategy）模式：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化.

命令（Command）模式：将请求及其参数封装成一个对象，作为命令发起者和接收者的中介，可以对这些请求排队或记录请求日志，以及支持可撤销操作

观察者模式

观察者（Observer）模式：定义了对象之间一对多的依赖，当这个对象的状态发生改变的时候，多个对象会接受到通知，有机会做出反馈；

在这里插入图片描述
Subject：抽象的主题，即被观察的对象
Concrete Subject：具体被观察对象
Observer：抽象的观察者
Concrete Observer：具体的观察者
注意：在观察者模式中，Subject通过Attach和Detach方法添加或删除所关联的观察者，并通过Notify进行更新，让每个观察者观察到最新的状态

备忘录模式

备忘录（Memento）模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态;

在这里插入图片描述

访问者模式

访问者（Visitor）模式：表示一个作用于某对象结构中的各元素的操作。可以在不改变各元素的类的前提下定义作用于这些元素的新操作

在这里插入图片描述

软件体系结构风格

最常见的是客户/服务器架构（CS架构）

基于资源不对等，且为实现共享而提出
包括

数据库服务器
客户端应用程序
网络

在这里插入图片描述

统一建模语言（UML）

总览

视图：

用户视图：以用户的观点表示系统的目标，它是所有视图的核心，该视图描述系统的需求。
结构视图：表示系统的静态行为，描述系统的静态元素，如包、类与对象，以及它们之间的关系。
行为视图：表示系统的动态行为，描述系统的组成元素如对象在系统运行时的交互关系。
实现视图：表示系统中逻辑元素的分布，描述系统中物理文件以及它们之间的关系。
环境视图：表示系统中物理元素的分布，描述系统中硬件设备以及它们之间的关系。

常见图

用例图

在用例图中，使用用例来表示系统的功能需求，用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。
用例图与用例说明文档(Use Case Specification)是常用的需求建模工具，也称之为用例建模。

类图

对应于结构视图。
类图使用类来描述系统的静态结构，类图包含类和它们之间的关系，它描述系统内所声明的类，但它没有描述系统运行时类的行为。

关联关系

实线箭头表示，若为双向关联则去掉箭头
在这里插入图片描述

聚合关系

弱聚合，表示成员与整体的关系，但是成员可以脱离整体而存在。
在这里插入图片描述
强聚合，也表示成员与整体的关系，但是成员与整体生命周期相同，是”同生共死“的。

依赖关系

在这里插入图片描述

泛化关系

在这里插入图片描述

实现关系

在这里插入图片描述

测试

黑盒测试

黑盒测试也称为功能测试或黑箱测试，其盒是指被测试的软件，“黑盒”则指测试人员只知道被测软件的界面和接口外部情况，不必考虑程序内部逻辑结构和特性，只根据程序的需求分析规格说明，检查其功能是否符合。

    以黑盒测试发现程序中的错误，应在所有可能的输入条件和输出条件中确定测试数据，检查程序是否都能产生正确输出。
    测试模块之间的接口，适合采用黑盒测试，适当辅以白盒测试，以便能对主要的控制路径进行测试。

黑盒测试常用方法：等价类划分（ECP）法

所谓等价类，是输入条件的一个子集合，该输入集合中的数据对于揭示程序中的错误是等价的。从每一个子集中选取少数具有代表性的数据，从而生成测试用例。
【案例1】“考试成绩”模块输入条件规定输入值的范围 (如“数据值”从0到 100 ),则可划分一个合理等价类(1且100的数)和两个不合理等价类(<0, 或>100的数)。