架构风格

简介: 管道-过滤器风格:每个构建都有一组输入和输出,数据输入构建,经过内部处理,然后产生数据输出。主程序-子程序:面向过程的架构,所有的计算构件作为子程序协作工作,并由一个主程序顺序的调用这些子程序,构件用共享存储区交换数据。面向对象风格:面向对象架构风格的特征是将数据标识和基本操作封装在对象中。这种模式的构件是对象,对象维护自身表示的完整性,对象之间通过消息机制进行通信,对

  • 管道-过滤器风格:每个构建都有一组输入和输出,数据输入构建,经过内部处理,然后产生数据输出。
  • 主程序-子程序:面向过程的架构,所有的计算构件作为子程序协作工作,并由一个主程序顺序的调用这些子程序,构件用共享存储区交换数据。
  • 面向对象风格:面向对象架构风格的特征是将数据标识和基本操作封装在对象中。这种模式的构件是对象,对象维护自身表示的完整性,对象之间通过消息机制进行通信,对象交互时需要知道彼此的标识,通过对象之间的协作完成计算过程。
    面向对象好处:
    1. 可以自然映射到现实对象上,易于理解和编程(传统的说法)
    2. 低耦合:OO的继承和多态使得服务提供者可以仅提供接口,而将具体实现推迟到运行时,从而降低调用者和被调用者之间的耦合。(解耦是为了适应变化
    3. 高类聚:OO是将数据,和对数据的操作绑定在一个类中,并通过可见性约束,只暴露给Client应该看见的操作和变量。(内聚是为了重用
    4. 因为低耦合,高内聚,所以提供了更好的可维护、可重用、可扩展、灵活性。
  • 事件驱动风格(隐式调用):系统中的其他构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程。实例,数据库系统,用户界面。
  • 分层(C/S,B/S, 三层, n层结构)
    三层:展现层,业务层,数据库层
    n层:在三层的基础上,将业务层划分为多层的模块。
  • C2风格:构件与构件之间的直接连接是不允许的,件之间的通讯是通过以连接件为中介的异步消,交换机制来实现的,构件相对独立,构件之间依赖性较少。
    实例:有多个Client端的和一个Sever端的聊天工具,ClientA发消息给ClientB需要经过Sever连接转发。
  • 仓库风格:在仓库(Repository)风格中,有两种不同构件:中央数据结构(共享数据)说明当前状态,独立构件在中央数据存储上执行。共享数据可以是传统数据库,也可以是黑板系统。实例,智能系统。
  • 回调机制:回调机制是一种常见的设计模型,他把工作流内的某个功能,按照约定的接口暴露给外部使用者,为外部使用者提供数据,或要求外部使用者提供数据。
  • 虚拟机风格:解释器;基于规则的系统。实例,Java虚拟机,解释执行的程序。
  • 过程控制环路(闭环):控制环路风格是将过程输出的指定属性维护在一个特定的参考值(设定值),将事务处理看成输入、加工、输出、反馈、再输入的一个持续的过程模型。实例,空调的温度自动调节器(设定值是温度),巡航系统(设定值是速度)。
     闭环控制是根据控制对象输出反馈来进行校正的控制方式,它是在测量出实际与计划发生偏差时,按定额或标准来进行纠正的。闭环控制,从输出量变化取出控制信号作为比较量反馈给输入端控制输入量,一般这个取出量和输入量相位相反,所以叫负反馈控制,自动控制通常是闭环控制。比如家用空调温度的控制
  • 微内核:
    用例:Windows NT 操作系统,JBoss Web服务器
    优点:
    1. 灵活性和扩展性。微内核系统把最小核心功能同扩展功能和特定应用分离开来,使系统高内聚、低耦合、可以用plug-in的形式对应用进行扩展。
    2. 系统具有更高的可移植性。
    3. 健壮性,微内核系统将许多服务移植到用户空间,二者各自占用独立的内存空间,某个具体应用本身的错误或存在的问题不会影响内核的正常运行。并且模块各自独立的设计也可以把安全问题分解,使系统服务程序严格按照安全要求运行。
    4. 策略和机制的分离,从某种意义上讲微内核体系结构模式是一种特殊的层体系结构,这种把核心功能、扩展功能和特定应用分离,分处在不同的抽象层,分别实现机制和策略的思想,进一步体现了系统设计的高内聚、低耦合。
  • 回调机制
    回调(Callback)机制是一种常见的设计模型,他把工作流内的某个功能,按照约定的接口暴露给外部使用者,为外部使用者提供数据,或要求外部使用者提供数据。

=======================================================

软件模块之间总是存在着一定的接口,从调用方式上,可以把他们分为三类:同步调用、回调和异步调用。

 

同步调用:一种阻塞式调用,调用方要等待对方执行完毕才返回,它是一种单向调用;

回      调:一种双向调用模式,也就是说,被调用方在接口被调用时也会调用对方的接口;

异步调用:一种类似消息或事件的机制,不过它的调用方向刚好相反,接口的服务在收到某种讯息或发生某种事件时,会主动通知客户方(即调用客户方的接口)。

回调和异步调用的关系非常紧密:使用回调来实现异步消息的注册,通过异步调用来实现消息的通知。



黑板系统(Blackboard system):

黑板模型主要由“黑板”、知识源(Knowledge Source)和控制机构三大部分组成。


  • 黑板
    所谓黑板,就是一个分层的全局工作区(或称全局数据库)。它用来存储初始数据、中间结果和最终结果。整个黑板被分为若干层,每一层用于描述领域问题的某一类信息。高层信息可以看作是下层信息的抽象(或整体),反之,下层信息可以看作是上层信息的实例(或部分)。
  • 知识源
     所谓知识源,就是一个知识模块。黑板结构中具有多个知识源,每个知识源能用来完成某些特定的解题功能。知识源可以表示完成过程、规则集或逻辑断言等形式。一个知识源可以视为一个大规则,其条件部分称为知识源先决条件,动作部分称为知识源体。知识源的先决条件一旦与黑板状态匹配,该知识源便被激活,这时知识源体执行,其结果将导致黑板状态的变化。知识源之间互相独立,它们只能通过黑板进行通讯和互相调用。
  • 控制机构
    控制机构是求解问题的推理机构,由监督程序和调度程序组成。监督程序时刻注视着黑板状态,根据黑板状态采用某种策略选择合适的知识源。将其条件部分放入调度队列,随后条件部分与黑板状态匹配,若匹配成功,则将其动作部分放入调度队列。动作部分的执行便又改变了黑板状态。调度程序通过选择所谓“聚焦”来优先使用队列中最重要、最有希望的知识源来执行。

黑板模型是一种适时推理模型,即系统能按最适宜的原则自行决定什么时候和怎样使用知识。在黑板模型中,解空间被组织成层次性结构,层次结构中每一层上的信息都表示局部解,相应层次上的知识模块对这种信息进行处理,生成更高级的局部解,直到最后的解。

理想的黑板模型中没有控制机制,知识源含有领域知识且是自驱动的。这样,每个知识源都“注视”着黑板上的状态信息,而且能“适时”地决定是否要对黑板进行操作。所以,在理想黑板模型中,各知识源实际上是并行执行的(这非常类似于现在的股票交易),但在现有的串行环境下这种并行却难以实现。因此,才增设了控制机制等方法把黑板变成串行系统(这又类似于拍卖过程)。当然,这样就限制了黑板模型的潜在功效。



面向对象设计原则:

设计原则名称

设计原则简介

重要性

单一职责原则

(Single
Responsibility Principle, SRP)

类的职责要单一,不能将太多的职责放在一个类中。

开闭原则

(Open-Closed
Principle, OCP)

软件实体对扩展是开放的,但对修改是关闭的,即在不修改一个软件实体的基础上去扩展其功能。

里氏代换原则

(Liskov
Substitution Principle, LSP)

在软件系统中,一个可以接受基类对象的地方必然可以接受一个子类对象。

依赖倒转原则

(Dependency
Inversion Principle, DIP)

要针对抽象层编程,而不要针对具体类编程。

接口隔离原则

(Interface
Segregation Principle, ISP)

使用多个专门的接口来取代一个统一的接口。

合成复用原则

(Composite Reuse
Principle, CRP)

在系统中应该尽量多使用组合和聚合关联关系,尽量少使用甚至不使用继承关系。

迪米特法则

(Law of Demeter,
LoD)

一个软件实体对其他实体的引用越少越好,或者说如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,而是通过引入一个第三者发生间接交互。




目录
相关文章
|
9天前
|
消息中间件 编解码 前端开发
软件体系结构 - 软件架构风格
【4月更文挑战第13天】软件体系结构 - 软件架构风格
10 0
|
1月前
|
移动开发 前端开发 C#
MVVM风格架构
MVVM风格架构
28 2
|
11月前
|
移动开发 自然语言处理 BI
【架构风格】架构风格演进和领域架构分类
【架构风格】架构风格演进和领域架构分类
|
运维 前端开发 Java
|
存储 运维 Cloud Native
保持我的风格
保持我的风格
53 0
保持我的风格
|
消息中间件 XML 缓存
浅谈API设计风格
API 风格是一个备受争议的话题,大多数开发者都熟悉 REST 与 GraphQL 的争论,更不用说其他风格了。本文将介绍常见的8种不同的API风格。
357 0
|
编译器 数据库
【系统架构】-软件架构的5大风格
软件架构有哪几种风格?
1457 0
【系统架构】-软件架构的5大风格
|
缓存 API 网络架构
架构风格:你真的懂REST吗?
本文探讨如下几个问题: 什么是REST REST包含哪些约束 什么是RESTful 纯RESTful API的难点在哪里 如果你去搜索「什么是REST」的话,大部分情况下,你看到的基本都是RESTful! 这类内容主要说的是: 资源URL应该怎么写 要用GET来获取资源 要用POST来新建资源...
1580 0
|
XML 存储 设计模式
如何形成统一设计风格-实践篇
在上一篇《业务团队如何统一架构设计风格?》中,探讨了一种业务架构的设计规范,以期达到这些目标:用标准约束技术细节;用技术工具而非文档推行标准;持续重构而非造新轮子;重视业务建模。但通篇表述较为抽象。本篇将总结团队近来的架构演进工作,以更具体的技术细节,详细阐释该理念,作为“统一业务设计风格”的实践篇。文中详述了多个层面的设计规约和基于规约的搭建方式,并在末尾回答了上一篇的诸多疑问。
如何形成统一设计风格-实践篇

热门文章

最新文章