[架构之路-135]-《软考-系统架构设计师》-软件工程-5-软件系统设计(面向对象设计基础)

前言:

第4节 系统设计

4.3 面向对象设计

4.3.1 概述

面向对象程序设计(Object Oriented Programming,OOP)是一种计算机编程架构。

OOP的一条基本原则是计算机程序由单个能够起到子程序作用的单元或对象组合而成。

OOP达到了软件工程的三个主要目标:重用性、灵活性和扩展性

OOP=对象+类+封装 + 继承+多态+消息,其中核心概念是类和对象

面向对象程序设计方法是尽可能模拟人类的思维方式,使得软件的开发方法过程尽可能接近人类认识世界、解决现实问题的方法和过程,也即使得描述问题的问题空间与问题的解决方案空间在结构上尽可能一致,把客观世界中的实体抽象为问题域中的对象。

面向对象程序设计以对象为核心,该方法认为程序由一系列对象组成。是对现实世界的抽象,包括表示静态属性的数据和对数据的操作,对象是类的实例化。

对象间通过消息传递相互通信,来模拟现实世界中不同实体间的联系。

在面向对象的程序设计中,是组成程序的基本模块

对象是什么?

  • 语言实现层次来看,对象封装了代码和数据

  • 规格层次面讲,对象是一系列可被使用的公共接口

  • 概念层面讲,对象是某种拥有责任的抽象

4.3.2 封装

封装是指将一个计算机系统中的数据以及与这个数据相关的一切操作语言(即描述每一个对象的属性以及其行为的程序代码)组装到一起,一并封装在一个有机的实体中,把它们封装在一个“模块”中,也就是一个类中,为软件结构的相关部件所具有的模块性提供良好的基础。符合高内聚、低耦合性的特征

面向对象技术的相关原理以及程序语言中,封装最基本单位是对象,而使得软件结构的相关部件的实现“高内聚、低耦合”的“最佳状态”便是面向对象技术的封装性所需要实现的最基本的目标。对于用户来说,对象是如何对各种行为进行操作、运行、实现等细节是不需要刨根问底了解清楚的,用户只需要通过封装外的通道对计算机进行相关方面的操作即可。大大地简化了操作的步骤,使用户使用起计算机来更加高效、更加得心应手。

4.2.3 继承

继承性是面向对象技术中的另外一个重要特点,其主要指的是两种或者两种以上的类之间的联系与区别。

继承,顾名思义,是后者延续前者的某些方面的特点,而在面向对象技术则是指一个对象针对于另一个对象的某些独有的特点、能力进行复制或者延续。如果按照继承源进行划分,则可以分为单继承(一个对象仅仅从另外一个对象中继承其相应的特点)与多继承(一个对象可以同时从另外两个或者两个以上的对象中继承所需要的特点与能力,并且不会发生冲突等现象);

如果从继承中包含的内容进行划分,则继承可以分为四类,分别为取代继承(一个对象在继承另一个对象的能力与特点之后将父对象进行取代)、包含继承(一个对象在将另一个对象的能力与特点进行完全的继承之后,又继承了其他对象所包含的相应内容,结果导致这个对象所具有的能力与特点大于等于父对象,实现了对于父对象的包含)、受限继承、特化继承。

4.2.4 多态

从宏观的角度来讲,多态性是指在面向对象技术中,当不同的多个对象同时接收到同一个完全相同消息之后,所表现出来的动作是各不相同的,具有多种形态

从微观的角度来讲,多态性是指在一组对象的一个类中,面向对象技术可以使用相同的源代码调用方式来对相同的函数名进行调用,即便这若干个具有相同函数名的函数所表示的函数代码执行是不同的。

4.3.5 面对对象设计的基本过程

上图中:

  • 左图是对象分析的结果

  • 中间是架构师的工作

  • 右边是架构师的设计输出!!!

4.3.6 面向对象的设计原则(七大原则)

变化是复用的天敌,面向对象设计最大的优势在于:抵御变化!

  理解面向对象是如何隔离的变化

  • 从宏观层次来看,面向对象的构建方式更能适应软件的变化,能将变化所带来的影响减为最小

 各司其职

  • 从微观层次来看,面向对象的方式更强调 各个类的“责任”  

  • 由于需求变化导致的新增类型不应该影响原来类型的实现—所谓的各负其责 

原则都是前人总结出来的经验,遵循这些原则,让我们开发的程序更加健壮、更易维护和可扩展、更容易应对未来不确定的变化!!!!

软件的可维护性和软件的可复用性(Reuse)或重用以及软件的可扩展性,拥有众多优点,如可以提高软件的开发效率,提高软件质量,节约开发成本,恰当的复用还可以改善系统的可维护性。

面向对象设计复用的目标在于实现支持可维护性的复用。

在面向对象的设计里面,可维护性复用都是以面向对象设计原则为基础的,这些设计原则首先都是复用的原则,遵循这些设计原则可以有效地提高系统的复用性,同时提高系统的可维护性。

面向对象设计原则和设计模式也是对系统进行合理重构的指南针,重构(Refactoring)是在不改变软件现有功能的基础上,通过调整程序代码改善软件的质量、性能,使其程序的设计模式和架构更趋合理,提高软件的扩展性和维护性。

对于面向对象的软件系统设计来说,在支持可维护性的同时,需要提高系统的可复用性。

软件的复用可以提高软件的开发效率,提高软件质量,节约开发成本,恰当的复用还可以改善系统的可维护性。

  • 单一职责原则:要求在软件系统中,一个类只负责一个功能领域中的相应职责。

  • 开闭原则:要求一个软件实体应当对扩展开放,对修改关闭,即在不修改原先已有代码的基础上扩展一个系统的行为。

  • 里氏替换原则:可以通俗表述为在软件中如果能使用基类对象,那么一定能够使用其子类对象。这是因为子类对象内存空间比父类对象的内存空间大,且子类继承下来的父类与原先的父类具有相同的结构体和内存空间分布

  • 依赖倒置原则:要求抽象不应该依赖于细节,细节应该依赖于抽象;要针对接口编程,不要针对实现编程。 之所以称为倒置,是因为在软件层次上,抽象在下层,具体实现在上层。

  • 接口隔禽原则:要求客户端不应该依赖那些它不需要的接口,即将一些大的接口细化成一些小的接口供客户端使用。使用单一功能的接口比功能丰富的接口要好。

  • 合成复用原则:要求复用时尽量使用对象組合,而不使用继承。继承导致子类与父类是强依赖关系,不符合低耦合的原则!

  • 迪米特法则:要求一个软件实体应当尽可能少的与其他实体发生相互作用。

原文链接:https://blog.csdn.net/m0_54178972/article/details/112313367

参考:

https://blog.csdn.net/m0_54178972/article/details/112313367

4.3.7 面对对象的设计模式 (就是套路)

基于面向对象技术构建软件系统的套路,就是设计模式。

采用这些套路设计出来的软件系统不会犯大的错误

采用这些套路设计出来的软件系统具备如下的特征

  • 已有功能的稳定性

  • 新环境的适应性

  • 新需求的快速应对性

  • 系统的可扩展性

这就是设计模式的意义所在!!!

4.3.7.1 设计模式中使用到的UML图

设计模式实际上类与类的关系的讨论,是如何使用类来构建软件系统的一种套路。

因此,UML类图以及类与类的关系是描述设计模式图形化的手段!!!

(1)泛化(Generalization)

【泛化关系】:是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为。例如:老虎是动物的一种,即有老虎的特性也有动物的共性。

【箭头指向】:带三角箭头的实线,箭头指向父类

(2)实现(Realization)

【实现关系】:是一种实现类(子类)与抽象接口(父类)之间的关系,表示实现类是接口类所有特征和行为的具体实现(不是实例化)

【箭头指向】:带三角箭头的虚线,箭头指向接口(抽象类)

(3)关联(Association)

【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。

【代码体现】:成员变量

【箭头及指向】:带普通箭头的实心线,指向被拥有者

上图中,老师与学生是双向关联,老师有多名学生,学生也可能有多名老师。但学生与某课程间的关系为单向关联,一名学生可能要上多门课程,课程是个抽象的东西他不拥有学生。

下图为自身关联:

(4)聚合(Aggregation)

【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系,轮胎离开车仍然可以存在。

聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。

【代码体现】:成员变量

【箭头及指向】:带空心菱形的实心线,菱形指向整体

(5)组合(Composition)

【组合关系】:是整体与部分的关系,但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系,没有公司就不存在部门。

组合关系是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

【代码体现】:成员变量

【箭头及指向】:带实心菱形的实线,菱形指向整体

(6)依赖(Dependency)

【依赖关系】:是一种使用的关系,即一个类的实现需要另一个类的协助,所以要尽量不使用双向的互相依赖.

【代码表现】:局部变量、方法的参数或者对静态方法的调用

【箭头及指向】:带箭头的虚线,指向被使用者

各种关系由强到弱顺序:

泛化 > 实现 > 组合 > 聚合 > 关联 > 依赖

下面这张UML图,比较形象地展示了各种类图关系:

4.3.7.2 架构模式、设计模式、惯用法区别

架构模式:使用与整个分布式软件系统。

设计模式:设计某个功能模块时,如果采用面向对象源代码编程,则设计模式指明源代码的类与类关系的模式。设计模式就是面向对象编程的套路,与具体的编程语言无关。

惯用法:编程语言在源代码编程时,一些常用的、习惯性的的做法,与编程语言强相关。

4.3.8 二十三种设计模式

(289条消息) [架构之路-116]-《软考-系统架构设计师》-软件工程-5-二十三种设计模式(面向对象的可复用设计)_文火冰糖的硅基工坊的博客-CSDN博客

参考:

图解23种设计模式,不信你学不会!(建议收藏) - 知乎 (zhihu.com)

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
\历年真题 的目录 2009年下半年 系统架构设计师 案例分析.docx 2009年下半年 系统架构设计师 综合知识.docx 2009年下半年 系统架构设计师 论文 .docx 2010年下半年 系统架构设计师 案例分析.docx 2010年下半年 系统架构设计师 综合知识.docx 2010年下半年 系统架构设计师 论文.docx 2011年下半年 系统架构设计师 案例分析.docx 2011年下半年 系统架构设计师 综合知识.docx 2011年下半年 系统架构设计师 论文.docx 2012年下半年 系统架构设计师 案例分析.docx 2012年下半年 系统架构设计师 综合知识.docx 2012年下半年 系统架构设计师 论文.docx 2013年下半年 系统架构设计师 案例分析.docx 2013年下半年 系统架构设计师 综合知识.docx 2013年下半年 系统架构设计师 论文.docx 2014年下半年 系统架构设计师 案例分析.docx 2014年下半年 系统架构设计师 综合知识.docx 2014年下半年 系统架构设计师 论文.docx 2015年下半年 系统架构设计师 案例分析.docx 2015年下半年 系统架构设计师 论文.docx 2015年下半年 系统架构设计师 综合知识.docx 2016年下半年 系统架构设计师 综合知识.docx 2016年下半年 系统架构设计师 论文.docx 2016年下半年 系统架构设计师 案例分析.docx 2017年下半年 系统架构设计师 案例分析.docx 2017年下半年 系统架构设计师 综合知识.docx 2017年下半年 系统架构设计师 论文.docx 2018年下半年 系统架构设计师 案例分析.docx 2018年下半年 系统架构设计师 综合知识.docx 2018年下半年 系统架构设计师 论文.docx \答案 的目录 2009年下半年 系统架构设计师 答案详解.docx 2010年下半年 系统架构设计师 答案详解.docx 2011年下半年 系统架构设计师 答案详解.docx 2012年下半年 系统架构设计师 答案详解.docx 2013年下半年 系统架构设计师 答案详解.docx 2014年下半年 系统架构设计师 答案详解.docx 2015年下半年 系统架构设计师 答案详解 .docx 2016年下半年 系统架构设计师 答案详解.docx 2017年下半年 系统架构设计师 答案详解.docx \赠送资料 的目录 2017年上半年软考论文答题卡.docx 2017年系统架构设计师考试大纲.docx 系统架构师论文范文50篇.pdf 系统架构师(第2版).pdf 系统架构设计师教程(第4版).docx 系统架构设计师教程(第4版)带目录超清.pdf 系统架构设计师考试考点突破、案例分析、试题实战一本通.pdf

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

文火冰糖的硅基工坊

你的鼓励是我前进的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值