面向对象设计之二 类的领域、依赖度与内聚类型

实战指南:如何用领域驱动设计(DDD)划分你的第一个业务中台 本文详细介绍了如何运用领域驱动设计(DDD)方法论划分业务中台,解决企业系统架构中的重复建设与数据孤岛问题。通过业务全景测绘、领域划分艺术、上下文映射和中台演进策略四个步骤,帮助开发者构建高效、可复用的中台服务,提升业务响应速度与系统可维护性。 阅读详情

1 类的领域

一个标准的面向对象的系统包含的类通常来自于四个主要的领域:应用领域、商业领域、结构领域和基础领域。在每个领域中都有几组类。

1.1  基础领域

基础领域中所包含的类具有非常广泛的使用范围,基础领域有三组类:基础性的、结构性的、语义性的。每组类都有一些类的实例:

基础类包括integer,Boolean,char等,这些类是是最基本的,多数语言都将它们作为内置的简单数据类型。

结构类可以实现一些数据结构,包括stack,list,set等。

语义类包括data,time,angle,point,line等。

一个基础性的类可以构造于其它基础性的类之上。

1.2 结构领域

结构领域包含三组类:机器间通信类、数据库操作类和人机接口界面类。

机器间通信类包括 port和host类

数据库操作类包括transaction类

人机界面类包括window和button等类

1.3 商业领域

商业领域局限于单一工业领域,如银行、电力等,商业领域包含三组类:属性性、角色类和关系类。

属性类描述了商业领域世界里事物的属性,如银行业的中帐户类。

角色类是商业行为中事物扮演的角色所演变而来,如银行业中的客户类。

关系类是从商业领域各种事物之间的相互关系演变而来的,如帐户所属关系。

此领域中的类的适用性变得比较狭窄,它们可能仅仅只对某个公司适用。

1.4 应用领域

应用领域中的类只能被一个单独的应用系统所使用。它包括两组类:事件识别类和事件管理类。

事件识别类是事件监控者,检测环境中特定事件的发生。

事件管理类当一个给定类型的事件发生时执行适当的商业策略。

1.5 领域类的来源

保证可重用软件的能力是面向对象设计的必要条件,但来自不同领域的类具有不同的可重复使用级别。处于最低级别领域的类具有最大的可重复使用能力,处于最高级别领域类却具有最小的可重复使用能力。

2 依赖度

2.1 依赖度的定义

假设C的直接类引用集包含了类C1、C2、…、Cn。那么C的间接类引用集就是C的直接类引用集和C1、C2、…、Cn的间接类引用集的并集。这个定义是递归的,通过说明对基础领域中每个类的类引用都是空值来终止这种递归。

类C直接引用另一个类D的方式有以下几种:

C继承D,C中能一个D类的属性,C的方法有类D的参数,C的方法中有一个类D的局部变量等。

一个类的直接依赖度是指这个类的直接类引用集的大小。

一个类的间接依赖度的大小是指这个类的间接类引用集的大小。

2.2 依赖度的使用

依赖度为我们提供了一种衡量类的复杂程序的方法。因此高级别领域的类具有较高的间接依赖度,处于低级别的类则具有较低的间接依赖度。

出现一个并非希望得到的间接依赖度即意味着类的设计中存在问题。例如在一个低级别的领域中一个类具有很高的依赖度,这个类的内聚就存在问题。而一个高级别的领域的类具有很低的依赖度,说明这个类也比较糟糕,它是由简单的基本类型创建的。

2.3 Demeter规则

有人称之谓最少知识原则,通常是以如下语言描述的:

对类C而言,在其所有定义的方法中,所有消息的目的地是下面形式之一:

1 类C自身,调用this,self等上的方法

2通过方法参数传入的对象

3 类C自身的成员对象

4 在方法中创建的其它对象

5 通过全局变量引用的一个对象

Demeter规则有强弱之分,两者只在第3条有差异,强规则只允许使用类C中定义的成员变量,而弱规则还允许使用继承自基类的成员。

这个规则之所以有用是因为它一个给定类对其它类的任意调用。强规则严格限制超过封装边界的继承。可以简化系统的可维护性和可扩展性。

3 类的内聚性

一个低级内聚的类具有一组并不属于一个整体的特性,一个高内聚的类具有一组可以通过类来实现的抽象类型的特性。

可以通过观察使用类变量的方法中出现重叠的强度,如果重叠越多则内聚越强。然而这种方法需要人为去观察类的实现,而且此方法也不够稳定。

通过下面不够成熟的三种内聚特性,我们可以避免实现较差的内聚。

3.1 混合属性内聚

混合属性内聚的类具有一些属性,对类的某些对象来说这些特征是未被定义的。

混合属性内聚通常指出一个非正确的类层次结构。例如对于经理也是雇员而言,但经理有额外分成,如果让经理和雇员使用一个类的话,则雇员需要多出来一个额外分成的属性,而这个属性普通雇员不会使用,即使使用也需要置为0。较好的方法是分离为两个派生类,一个子类拥有此属性,另一子类没有。

3.2 混合领域型内聚

如果类A在不涉及任何类B概念的前提下可以得到充分的定义,那么对于类B是A的非本征类。

如果类B捕获了A中固有的一些特性,则B是A的本征类。

一个混合领域型内聚的类包含一个元素,而这个元素是其它领域的非本征类的直接引用集。

比如让实数类支持三角运算、货币转换等操作。

当你设计给定领域的类时,如果需要将高级别领域的类引入到你正在设计的类中,则需要小心谨慎。

另一种判断两个类是否是同一领域的方法是假设在不涉及另一类的前提下,是否可以创建一个类。

3.3 混合角色型内聚

一个混合角色型内聚的类C包含这样一个元素,这个元素对C是非本征的,但其是同一领域其它类的依附集。

比如person类中含有一个成员,保存了一个人拥有多少个dog。这样做使得person类在不包含狗的应用场景中无法被重用。

Java架构师系统架构实现高内聚低耦合 目录 1 导语 2 边界内聚耦合概述 3 聚焦内聚 4 关注耦合 5 如何实现高内聚低耦合 6【案例分析】内聚耦合规划不当的反面教材集锦 7 总结 阅读详情

相关推荐

小米路由器R1D进阶玩法:MIXBOX工具箱安装与插件管理指南

本文详细介绍了为小米路由器R1D安装MIXBOX工具箱的完整指南。通过开启SSH、执行一键安装脚本,用户可以轻松解锁路由器的进阶功能,如安装离线下载、内网穿透等插件,从而将旧设备转变为强大的家庭网络服务中心。

weixin_29292431的博客 1110

领域类图(领域模型/概念类图)的绘制

领域类图(领域模型/概念类图)的绘制 显示最重要的业务概念和它们之间关系,是真实世界各个事物的表示(现实世界的可视化抽象字典)而不是软件中各构件的表示。(类:表示业务概念,通常只包含重要属性,少甚至不包含操作;关联、泛化:表达概念之间的关系)Tip: 关于类中到底是否应该有操作(方法),网上的资料说什么的都有,所以自己看情况决定吧,没太大影响。 总而言之:领域类图是描述业务领域(业务实体)的静态结构

猫多会咬狗 6万+

自适应IIR格型滤波器的Matlab实现

概述 在现有的众多抑制窄带干扰的信号处理手段中,时域自适应陷波干扰抑制技术具有实现简单、抗干扰性能好等优点。IIR陷波器按照结构可以分为直接型和格型两种。相比自适应直接型IIR陷波器,自适应格型IIR陷波器不仅可以准确地控制滤波器的陷波频率,也可以准确地调整陷波器的带宽。 传递函数 二阶自适应IIR格型陷波器的传递函数H(z)为: 其中α与陷波带宽有关,β与陷波频率有关;对应的结构如下图所示: Matlab算法实现 ...

剑藏锋的博客 2799

正确认识使用UML中的类图——辨析类图的两种存在形式

摘要      本文通过对一个“学生选课系统”示例的简要分析与设计,说明UML图之一类图的两种作用及存在形式,以期借此澄清有些朋友可能对类图存在的误解与困惑。前言      在OOA与OOD大行其道的今天,UML在系统分析与设计中得到了广泛的采用。而在UML的9种图中,类图是最重要也是使用最普遍的图之一。但是,在与一些朋友,特别是初学者的聊天当中,我发现很多朋友对类图的作用及使用方法存在一定的误解...

weixin_34349320的博客 910

Monocle2在R 4.3环境下的终极避坑指南:从安装到可视化全流程解析

本文提供了在R 4.3环境下安装和运行Monocle2的完整解决方案,重点解决了依赖包兼容性、源码修改及BEAM分析报错等关键问题。文章详细解析了从环境准备、依赖包处理、源码安装验证到从Seurat对象转换、拟时轨迹构建、高级可视化及性能优化的全流程,旨在帮助用户顺利完成单细胞拟时分析。

weixin_29206669的博客 1353

仓储控制系统(WCS)设计

WCS系统设计方法

cetclyb的博客 2万+

领域类之模型

关系模型 一、多对一和一对一 1、多对一模型 单向多对一模型,如下: class Face { Nose nose } class Nose { }双向多对一模型,如下: class Face { Nose nose } class Nose { static belongsTo = [face:Face] }在双向模型中 new Face(nose:n

LorenLuo的专栏 1126

STM32 USB AUDIO实战指南——从零构建音频设备

本文详细介绍了如何使用STM32F407构建USB音频设备,从硬件准备到软件配置,再到音频播放和录制功能的实现。通过STM32CubeMX配置和实战代码示例,帮助开发者快速掌握USB Audio Class规范,实现低延迟、高质量的音频传输,适用于语音交互、音乐播放等多种场景。

weixin_42549037的博客 484

统一建模语言UML(四):领域模型和类图

统一建模语言UML(四):领域模型和类图 领域模型 领域模型是对领域内概念类或现实世界中对象的可视化表示,也称为概念模型。是更为完整的业务模型的一个特例。从UML的表示法角度,领域模型被描述为一组没有定义操作的类图(概念类、关联、属性)。领域模型中的领域类通常只有属性,没有或很少的操作。 领域模型是对真实世界中概念类的表示,而不是软件对象的表示。(划重点!) 为模型建立适当的属性与关联。领域模型表现的是概念类之间的数量关系,对于数量关系的理解可以理解为与ER图中相似。 先上个领域模型图找找感觉: 领域模

qq_40324906的博客 4万+

Android 14.0 系统开机屏幕设置默认横屏显示

在14.0的系统ROM产品定制化开发中,对于产品需求来说,由于是宽屏设备所以产品需要开机默认横屏显示,开机横屏显示这就需要从 两部分来实现,一部分是系统开机动画横屏显示,另一部分是系统屏幕显示横屏显示,从这两方面就可以做到开机默认横屏显示了

安卓兼职framework和app工程师的博客 2150

eDP V1.4协议介绍

eDP的全称是Embedded DisplayPort嵌入式显示端口,主要应用与短距离系统内应用,例如手机、一体式台式机等。eDP V1.4b是基于DP V1.3标准制作完成,但因应用场景的不同,还是有很多区别。电压摆幅不同,eDP相对较低;eDP功耗相对较低;DP有线材和连接器的要求,eDP没有明确要求;AUX通道电路设计不同(相对DP取消了AC耦合电容和100KΩ/1MΩ的上下拉电阻):典型应用场景;

qflook的博客 4300

内聚的分类

②逻辑内聚:指模块内执行几个逻辑上相似的功能,通过参数确定该模块完成哪一个功能。③时间内聚:把需要同时执行的动作组合在一起形成的模块。⑤顺序内聚:指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行, 前一个功能元素的输出就是下一个功能元素的输入。④通信内聚:指模块内所有处理元素都在同一个数据结构上操作,或者指各处理使用相同的输入数据或者产生相同的输出数据。⑥功能内聚:是最强的内聚,指模块内所有元素共同完成一个功能,缺一不可。①偶然内聚:指一个模块内的各个处理元素之间没有任何联系。

m0_63839619的博客 971

uniapp:实现APP获取陀螺仪数据、加速传感器、线性加速传感器,uniApp实时监听陀螺仪【XYZ】数据及停止监听与资源释放等功能示例源码,根据需求做功能(完美兼容Android安卓、苹果ios)

uniapp陀螺仪,uniapp加速传感器,uniapp线性加速传感器,APP陀螺仪数据,uniapp app 端获取陀螺仪数据示例代码,手机中获取陀螺仪的数据,uniApp实时获取陀螺仪xyz数据,android陀螺仪方向,获得陀螺仪传感器,处理传感器数据,停止监听与资源释放,Android使用陀螺仪,uniapp苹果ios陀螺仪,uni-app设备之(加速计,罗盘,陀螺仪)插件安卓/IOS APP提供了获取陀螺仪数据的能力,手机陀螺仪传感器获得手机自身旋转的角度,陀螺仪获取旋转角度,陀螺仪、加速度传感器

✅ 精选推荐文章 4265

内聚和耦合的意思

1、内聚是同一个东西, 集中在一起, 便于维护.2、耦合是对其它东西的依赖度, 便于修改.

foart的专栏 1377

锂电池充电器电路设计 里面有电路

锂电池充电器电路设计 里面有电路 3.7V升压到5V电路设计。

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

【笔记】DDD领域驱动设计

领域驱动设计 原书第二部分

qq_40690815的博客 1278

pscad IEEE标准系统搭建说明

pscad IEEE标准系统搭建说明,包含典型的IEEE 9节点、14节点、30节点、39节点和118节点系统。内含标准测试系统的原始数据和潮流结果。

微服务架构与领域驱动设计应用实践

本篇文章一共分为三个部分,分别是微服务架构的演进过程、具体实践微服务的应用技术和领域驱动设计的意识转变。微服务架构已经渗透到互联网应用的方方面面,而领域驱动设计也逐渐被业...

开涛的博客 1970

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

年薪60W架构师详细解读微服务架构与领域驱动设计应用实践

本篇文章一共分为三个部分,分别是微服务架构的演进过程、具体实践微服务的应用技术和领域驱动设计的意识转变。微服务架构已经渗透到互联网应用的方方面面,而领域驱动设计也逐渐被业界所接收。 一、微服务架构的演进过程 微服务架构几乎都是从 ALL IN ONE 的单体架构演进而来,中间又经历了分布式架构、面向服务架构的演进过程。 单体架构往往以烟筒式方式发展,往往存在两个主要问题:中心化和耦...

qq_39662660的博客 381

软件设计与体系结构期末复习

瀑布式:大项目,从头到尾,按顺序完成,整个项目全部完成以后部署上线定义:将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型,包括需求分析、设计、编码、测试、运行和维护阶段。

Sakuraovu的博客 2925

架构设计内容分享(十六):微服务如何拆分?原则是什么?

2014年,Martin Fowler 与 James Lewis 共同提出了微服务的概念,定义了微服务是由以单一应用程序构成的小服务,自己拥有自己的进程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用HTTP API通信。在腾讯视频的DDD重构案例中,在老的微服务架构中,存在分层不明确,下层服务过于理解业务逻辑,存在下层调用上层的问题,出现了代码耦合严重,调用关系混乱的 “微服务小泥球”。如果是 数据驱动原则/界面驱动原则 ,那么,是一上来就定义数据库表结构,就去调整领域逻辑代码。

之乎者也·的博客 1415

DDD架构在合同管理系统中的实践与优化

领域驱动设计(DDD)是一种应对复杂业务系统的架构方法论,其核心在于通过领域模型将业务逻辑显式化。在合同管理系统这类业务规则复杂、状态流转频繁的场景中,DDD的价值尤为突出。合理的限界上下文划分和聚合根设计能有效解决业务耦合问题,而事件溯源和CQRS模式则提供了状态管理和查询优化的技术实现路径。本文通过企业级合同管理系统的开发实践,展示了如何通过DDD架构处理合同审批、财务条款等典型业务场景,并分享了性能优化和团队协作的经验。对于需要处理复杂业务流程的金融、法律等行业系统,这些实践具有重要参考价值。

weixin_33860553的博客 310
上一篇: 面向对象设计之一 封装与共生性
下一篇: 面向对象设计之三 类的状态空间和行为
zzulp
博客等级 码龄19年 464粉丝 176原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值