章丘公司做网站,wordpress配置微信支付,网页传奇发布网,wordpress导航栏制作教程软件体系结构概述
体系结构#xff1a;一种思想#xff0c;而框架就是思想的实现#xff0c;设计模式就是根据某一特殊问题实现的框架。 体系结构#xff1a;体系结构是软件系统的高级结构。它定义了系统的主要组成部分#xff0c;以及这些部分之间的关系和交互方式。 框…软件体系结构概述
体系结构一种思想而框架就是思想的实现设计模式就是根据某一特殊问题实现的框架。 体系结构体系结构是软件系统的高级结构。它定义了系统的主要组成部分以及这些部分之间的关系和交互方式。 框架框架是一个半完整的应用。它实现了一种或多种体系结构并为特定类型的应用程序提供了一个重用的结构和方法。开发者使用框架作为基础添加特定功能来创建完整的应用。 设计模式设计模式是在特定情境下反复出现的问题的通用解决方案。它不是可以直接转化为代码的模板而是一个关于如何解决问题的描述或模板。 有一个设计模式叫观察者模式可以根据不同的用户给出不同的视图。 观察者模式 观察者模式是一种行为型设计模式它定义了对象之间的一对多的依赖关系当一个对象的状态发生变化时所有依赖于它的对象都会得到通知并被自动更新。 关键组成部分 主题Subject持有某个重要状态并允许观察者对象注册和取消注册。 观察者Observer一旦主题的状态发生变化所有注册的观察者都会收到通知。 应用场景
在前端开发中观察者模式经常被用于实现事件监听和响应。例如当用户点击按钮或填写表单时观察者如事件处理程序会被通知并执行相应的操作。但是观察者模式不仅仅是关于“通知变化”它还可以根据不同的观察者提供不同的信息或视图。这意味着 可定制的通知当主题的状态发生变化时不同的观察者可能对不同的信息感兴趣。例如一些观察者可能只关心主题的某个特定部分的变化而其他观察者可能需要更广泛的更新。 响应差异不同的观察者可能会以不同的方式响应相同的状态变化。这种多样性可以通过为每个观察者定义不同的接口或回调函数来实现。 提供差异化的视图或接口在某些实现中主题可以为不同的观察者提供不同的“视图”或接口。例如一个数据模型作为主题可以为管理员观察者提供一个视图而为普通用户观察者提供另一个视图。这样基于观察者的角色或需求他们可以看到数据的不同表示或不同的数据子集。 这种差异化的方法使得观察者模式更加灵活和强大可以满足各种各样的应用场景和需求。 软件体系结构分类 构件连接的方式比如过程调用或者中断。 一个系统可能有多个体系结构。 管道和过滤器结构 编译程序、视频播放器就是管道和过滤器结构信息隐藏过滤器是一个黑匣子要很精准的很专注的完成一件事情
层次体系结构 在软件工程和系统设计中层次体系结构是一种逻辑分区它将系统的不同部分分成相互堆叠的层。每一层都为上面的层提供服务并从下面的层中获得服务。层次体系结构有一个约束每一层都只依赖于下一层不依赖于其他层。 这种方法的主要好处是 解耦每一层只关心其下面的层这有助于隔离变化和减少依赖。复用性较低的层可以被多个上层复用。可维护性清晰的界限和定义有助于开发和维护。 常见的层次体系结构如OSI网络互连模型。
OSI网络互连模型 OSI开放系统互连模型是一个网络体系结构模型由国际标准化组织ISO定义。它将网络协议分成七个不同的层从物理传输到应用之间的交互。 从下到上这七层是 物理层Physical Layer涉及到物理连接、电压、时钟频率等。例如电缆、交换机、集线器。 数据链路层Data Link Layer确保在物理网络上有一个可靠的链接。这一层经常被分为两个子层逻辑链路控制LLC和介质访问控制MAC。 网络层Network Layer处理数据包的发送和路由例如IP协议。 传输层Transport Layer提供端到端的通信服务例如TCP和UDP。 会话层Session Layer负责建立、管理和终止会话。 表示层Presentation Layer处理数据格式、加密和解密等功能。 应用层Application Layer为应用程序提供网络服务例如HTTP、FTP和SMTP。 在OSI模型中每一层都只依赖于下一层来提供其所需的服务。
C/S与B/S架构 服务器掌管资源。其实可以看作两层客户机/服务器体系结构也可以看为胖客户机我们的目标就是让C端尽可能瘦。这样就诞生了三层C/S体系结构增加了数据库
MVC架构 由于增加了VIEW所以mvc更加适用于用户交互。对于mvc模式的讲解请见文章Springboot知识点必知必会一_Joy T的博客-CSDN博客 系统设计原理之模块化 边界元素{}、begin end等。 最小成本区7±2原则介绍请见软件工程第四周-CSDN博客 信息隐藏不是隐藏全部信息而是有针对的暴露信息要求高聚合内部实现再复杂都可以使用接口暴露出来 内部资源分配策略、控制接口controlled interface都需要保密 模块独立——耦合与内聚
耦合 尽量少出现内容耦合、公共耦合与控制耦合呦
数据耦合
main与sum函数之间交换参数很多情况下都是数据耦合。但是一定是局部变量的传递如果传递的是全局变量则表示公共耦合其耦合性会大大增加不好 特征耦合 这里住户情况就是整个的数据结构是一点也不细化啊。这样的话计算水费和电费都用的是住户情况。一旦住户情况出现问题这就不知道会不会影响水费或者电费的计算这就是特征耦合耦合性较强不太好。最好是你需要什么数据就传递什么数据修改如下 这就从特征耦合改进到数据耦合了耶
控制耦合
怎么去理解控制耦合定义中的信号呢本质上就是分支主要表示形式如下 若采用这种控制形式一旦计算平均分的方法从求平均值变成分别去掉一个最大值和最小值再求平均值那么计算最高分耶很有可能受到影响。联系第一周软件工程的内容软件修改是有副作用的所以我们应该把控制信号变成调用函数的调用判断对象 公共耦合 公共耦合是指多个模块共享相同的数据可能导致的问题是数据的不完整性和不一致性。 为了解决这些问题我们可以采用一些机制和策略来减少或管理公共耦合。比如下图中将读写公共数据的两个模块分为一个模块读另一个模块写 以下是减少公共耦合的一些建议和考虑
1. 封装 封装意味着将数据隐藏在模块或对象内部并只通过定义好的接口访问它。这样可以确保数据的完整性和一致性并防止外部模块直接修改数据。 2. 使用服务层或API 为数据访问提供统一的服务层或API确保所有的读写操作都经过这一层。这不仅可以保持数据的一致性还可以为数据访问提供安全和验证机制。 想象你在一个大型酒店办理入住。你不会直接去找清洁员或者房间服务员来拿钥匙而是去前台。前台是你和酒店的所有服务之间的中介。同样当软件需要数据时它不直接去数据库拿而是通过一个“前台”——服务层或API。这确保了所有的数据请求都统一和有序。
以图书管理系统为例我们将服务层和API展示在其他文章中请见
3. 数据访问对象DAO 在设计模式中DAO是一种将低级的数据访问逻辑或操作从高级的业务服务中分离出来的模式。这样可以避免多个模块直接与数据库进行交互从而减少公共耦合。 在软件设计中DAOData Access Object层是负责与数据源例如数据库进行交互的部分。对于像JDBC或MyBatis这样的技术DAO层就是定义SQL查询插入更新和删除操作的地方。
拿图书管理系统举例我们可以细化如下 实体层Entity Layer这里定义了“图书”这一实体的属性和行为。一个图书实体可能有诸如title标题、author作者、ISBN国际标准书号等属性。 DAO层Data Access Layer 这是我们定义如何从数据库中获取图书如何插入新的图书如何更新图书信息或如何删除图书的地方。如果你使用JDBC你的DAO层可能会包含原始的SQL语句来实现上述操作。 如果你使用MyBatis你可能会在XML映射文件或注解中定义SQL语句而DAO层通常称为Mapper接口将包含与这些SQL语句对应的Java方法。 服务层Service Layer这是应用程序的核心业务逻辑所在。例如如果要借出一本书服务层可能需要首先检查这本书是否已经被其他人借走。这个层级会调用DAO层来获取数据库中的相关数据。 表示层/控制器层Presentation/Controller Layer用户与此层互动。例如这可以是一个web页面用户在这里输入书名来查找书籍或者输入书籍的详细信息来添加新书。 在这个架构中DAO层是充当桥梁的角色连接业务逻辑在服务层和实际的数据在数据库中。其目标是封装与数据访问相关的所有代码使其他部分的应用程序不需要关心数据访问的具体细节。
4. 事件驱动架构 使用事件来触发或通知数据更改而不是直接进行数据操作。这样可以避免直接的数据耦合并允许模块独立地响应事件。 想象你在一个餐厅里当你的食物准备好时服务员会叫你。你不需要每隔几分钟去厨房检查食物是否准备好。这是因为餐厅采用了“事件驱动”的模式——当某个事件食物准备好发生时会有一个相应的动作叫你。在软件中系统也可以这样设计它不不断地检查数据是否已经改变而是当数据改变时系统会得到通知并采取相应的行动。
数据库中的读写分离 这个对于公共耦合的改进让作者瞬间意识到数据库中的读写分离机制 进一步讨论 公共耦合主要发生在多个模块或应用共享相同的数据库表或字段时。这意味着如果一个模块对共享数据结构进行了修改例如更改了表结构或删除了某些字段其他模块可能会受到影响。 读写分离是数据库架构中的一个策略主要目的是提高性能和扩展性。在读写分离的系统中写入操作通常发送到主数据库而读取操作可以从一个或多个从数据库进行。 读写分离可以降低公共耦合因为它使得读和写操作在逻辑上或物理上分离减少了对同一数据的并发访问。但是它并不完全消除公共耦合特别是在需要保持数据一致性的情况下。 读写分离如何帮助 减少资源竞争由于写操作通常只发生在主数据库上而读操作可以在多个从数据库上分散这减少了对同一数据资源的并发访问从而降低了因并发访问导致的数据不一致性的风险。 分离业务逻辑在某些场景中可能会有一个模块主要进行数据写入而其他模块主要进行数据读取。这就是上图改进后的效果。读写分离自然地分隔了读写这两种业务逻辑减少了它们之间的直接依赖。
但是读写分离不能完全消除公共耦合原因如下 结构共享仍然存在尽管读和写操作已经分离但如果多个模块共享相同的数据结构它们仍然是耦合的。例如如果更改了数据库的表结构那么与该表相关的所有读写模块都可能受到影响。 数据同步和一致性在读写分离的环境中从数据库需要定期从主数据库同步数据。这可能导致短暂的数据不一致。因此模块需要考虑这种不一致性特别是在高数据更新频率的应用中。 内容耦合 1. goto就是一种通过非正常路口随便进入另一个模块内部的方法会造成内容耦合。但是goto语句会在极端情况下对性能做出优化所以到现在仍然允许使用只不过需要强劲的实力。 2. 一个模块有多个入口其实也会违背controlled interface的机制接口不唯一了。 3. 模块代码重叠可以通过将重叠部分中间图阴影部分所示转换成可调用的部分。 数据库视图
对于内容耦合作者认为可以通过视图view这一机制降低。 数据库中的视图view可以帮助管理和降低内容耦合。内容耦合发生在一个模块直接访问另一个模块的内部数据或实现细节。在数据库上下文中这可以解释为应用或服务直接访问数据库表的具体结构和数据。 使用视图views具有以下优势 抽象视图提供了一个对基础数据的抽象表示。它们允许展现数据的特定部分或者以不同的方式整合和呈现数据而不需要改变基础的表结构。 隔离变化如果基础表的结构需要更改视图可以帮助保持对外部应用或服务的相同表示只要视图的定义和输出仍然是一致的。 安全通过视图可以控制对数据的访问只显示对特定应用或服务的必要数据从而提高数据的安全性。 简化复杂查询对于复杂的数据结构您可以创建视图来简化查询使得应用的查询逻辑更加简单和直接。 通过这些方式视图确实可以降低内容耦合因为它们为应用程序提供了一个与基础数据结构和逻辑解耦的数据访问层。然而值得注意的是使用视图并不完全消除耦合因为任何对视图定义的更改仍然可能影响到依赖它的应用程序。 在实践中要注意分析耦合情况分析模块对模块进行调整。
逻辑内聚往往与控制耦合相关内聚部分下周再讲解。
