在上篇中咱们讲解了几类UML2.0语言新推出的建模图形,整体来讲经过这些图形能更详细的将某类信息表达出来。在这里咱们简单回顾上篇讲解的内容。html
上图中已经简单介绍了上章讲述的内容,具体内容请看:系统架构师-基础到企业应用架构-系统建模[下篇]。数据库
本章将主要的简单介绍在系统架构中的设计模式及相应规范准则。并结合相应的代码来讲明如何遵循系统架构中的一些基本的设计规范及准则。而咱们将在本文介设计模式
绍几类经常使用的设计规范,咱们先来看看结构化设计的二个基本原则:安全
固然既然提出了基本的准则,那么咱们如何来知足准则呢,而且能更好的设计呢?咱们能够经过以下手段来达到这样的要求:性能优化
固然图中演示了功能分离的策略,经过把需求按照不一样的功能详细的划分开来,每一个功能都是独立服务器
的,固然咱们这里也能够成为是关注点。下面咱们将针对这些原则进行详细的讲解。架构
一、上章回顾。模块化
二、摘要。函数
三、本章内容。性能
四、设计规范及原则。
五、如何知足设计要求。
六、本章总结。
七、系列进度。
八、下篇预告。
首先咱们来看看内聚的含义:软件含义上的内聚实际上是从化学中的分子的内聚演变过来的,化学中的分子间的做用力,做用力强则表现为内聚程度高。在软件中内
聚程度的高低,标识着软件设计的好坏。
咱们在进行架构设计时的内聚高低是指,设计某个模块或者关注点时,模块或关注点内部的一系列相关功能的相关程度的高低。
例如:下单模块:
通常状况下,下单模块都会有以下的信息,订单的信息,产品的信息及谁下的单(买家信息)。这是基
本的,那么咱们设计的时候就要把相关的功能内聚到一块儿。固然这是从大功能(下单管理)上来讲,固然这些模块还能够再细化分红产品、订单、会员等子模块。
例如咱们在设计数据库操做辅助类提供的方法有:
经过这样的方式,那么这个组件只负责数据库操做。这样带来的好处也是显而易见的。高内
聚提供了更好的可维护性和可复用性。而低内聚的模块则表名模块直接的依赖程度高,那么一旦修改了该模块依赖的对象则没法使用该模块,必须也进行相应的修改才
能够继续使用。
低内聚的模块设计的坏处有:首先模块的功能不单一,模块的职责不明确,比较松散,更有甚者是完成不相关的功能。这样的设计每每是不可取的。能够经过重
构来完善。
下面咱们来讲下高内聚的简单解释:什么样的模块算是高内聚,而且可以在系统中很好的使用。
那么咱们在设计的过程当中如何去完成高内聚呢?
以上基本上讲述了高内聚的好处,而且阐述了如何实现高内聚的步骤和原则。下面咱们来讲说可能高内聚带来的坏处。
高内聚有时候也不是说全部的状况都采用这样的原则,固然高内聚仍是要适度的,下面来举例说明:例如内聚性要求强的话就像Windows32中系统提供的
API,里面的函数太多了,都放在一个Dll中,那么每一个函数完成一个功能。这样强大的功能,会比较复杂,因此并非彻底的高内聚越高越好,仍是要看实际的须要。
固然维护起来也不是特别的方便。
首先咱们来看看低耦合的定义:低耦合是用来度量模块与模块直接的依赖关系。耦合固然也能够这样简单的理解,我想懂电脑的应该都知道,CPU与主板之间的
关系,CPU若是是特殊的CPU必须使用特殊的主板来支持,那么若是说这个CPU不惟一依赖惟一主板,那么就认为这个CPU与主板的关系是低耦合的关系。
下面咱们来举例说明低耦合的设计与高耦合的设计:
这是一个简单的低耦合的设计,电器与插座之间是低耦合的关系,就算我替换了不一样的插座,电器依
然能够正常的工做。所以简单的描述以下,就是A模块与B模块存在依赖关系,那么当B发生改变时,A模块仍然能够正常工做,那么就认为A与B是低耦合的。
一、笔记本接音响能够正常的使用。
二、笔记本接专配耳机正常的使用。
对应通常的音响来讲,笔记本是通用的,音响和笔记本直接的关系是低耦合的,可是笔记本和耳机倒是高耦合的,只有专配的耳机才能和笔记本互联使用,而不
是通用的,因此说笔记本和专配耳机存在着较强的依赖关系。固然最简单的方式就是笔记本提供统一的耳机接口,能够知足通常性的需求。
下面咱们未来分析如何构建低耦合的设计。
上面咱们已经讲解了低耦合和高内聚的二个原则,经过这2个原则咱们知道,知足这2个原则是衡量一个架构设计好坏的一个参考标准。下面咱们未来讲解经过
功能分离的方式来知足上面的2个原则。
一、如何按功能进行模块化的分离。
咱们在将一个系统进行功能划分时,咱们通常以下来进行:
首先、咱们先把功能职责划分红独立的单元。
例如如今有个B2C系统,那么咱们按照B2C的需求,以下分析:
咱们这里简单的分析下B2C应该具备的功能模块,固然这些模块的划分中,有些模
块还能够继续的分离,固然我这里只是实例分析出来。
二、对分离出来的模块化进行抽象,例如咱们以支付为例。
这里经过支付接口向外提供服务。那么外界模块不关心支付系统模块的变化,只须要调用接口
便可,若是具体的支付方式,好比支付宝的方式发生改变,在调用支付服务的模块中也不须要作任何的修改就能够正常的提供服务。显然这样的方式是不错的实现方
式。
一般状况下咱们在系统分离式只是以接口的方式提供服务,供其余的模块进行使用。在模块内部有大量的信息是不要向外部暴露的,因此模块在设计时访问域的定
义就要划分好,防止由于访问域的定义而对模块的信息形成破坏。
下面咱们来看下功能分离在不一样的设计理念下都是什么样的表现:
上面只是实体性的分析了功能分离的好处及应用的广度,固然咱们在后续会结合实例来说解如何来实现这样的软件设计模式。固然这只是软件的架构设计,那么如
果细化到具体的实现呢?咱们如何去设计每一个功能点呢?这就是下章咱们要讲解的内容了,那么本文先列出二种常见的方式。
下篇咱们将针对设计原则中的实现方式,进行详细的剖析与具体实现进行举例讲解,但愿你们多提意见。
本章中主要简单的讲述了软件设计的二个基本的规范与原则:
一、高内聚:描述了模块内部的一系列功能的相关程度,对于功能之间相关度不高或者根本没有相关性的功能包含在模块中的作法是不可取的。
二、低耦合:描述了模块直接的依赖、感知程度,耦合的衡量标准是从低到高,通常来讲耦合度越低越好。
固然有些特殊状况下,可能这二个原则也有矛盾的地方,固然咱们仍是要根据项目的实际须要及状况进行抉择,固然这二个原则是为了设计提供更好的扩展性、
可读性、可维护性、极高的可复用性,因此要求咱们在设计时尽可能去知足这二个基本原则。而帮我去达到这二个准则的途径就是经过功能分离及细化来实现这样的准
则。下一篇咱们将深刻的分析与举例来讲明实现这二个原则的各类规范及准则。
六、系统架构师-基础到企业应用架构-系统设计规范与原则[上篇]
七、系统架构师-基础到企业应用架构-系统设计规范与原则[下篇]
八、系统架构师-基础到企业应用架构-设计模式[上篇]
九、系统架构师-基础到企业应用架构-设计模式[中篇]
十、系统架构师-基础到企业应用架构-设计模式[下篇]
十一、系统架构师-基础到企业应用架构-企业应用架构
十二、系统架构师-基础到企业应用架构-分层[上篇]
1三、系统架构师-基础到企业应用架构-分层[中篇]
1四、系统架构师-基础到企业应用架构-分层[下篇]
1五、系统架构师-基础到企业应用架构-表现层
1六、系统架构师-基础到企业应用架构-服务层
1七、系统架构师-基础到企业应用架构-业务逻辑层
1八、系统架构师-基础到企业应用架构-数据访问层
1九、系统架构师-基础到企业应用架构-组件服务
20、系统架构师-基础到企业应用架构-安全机制
2一、单机应用、客户端/服务器、多服务、企业数据总线全解析
2二、系统架构师-基础到企业应用架构-单机应用(实例及demo)
2三、系统架构师-基础到企业应用架构-客户端/服务器(实例及demo)
2四、系统架构师-基础到企业应用架构-多服务(实例及demo)
2五、系统架构师-基础到企业应用架构-企业数据总线(实例及demo)
2六、系统架构师-基础到企业应用架构-性能优化(架构瓶颈)
2七、系统架构师-基础到企业应用架构-完整的架构方案实例[上篇]
2八、系统架构师-基础到企业应用架构-完整的架构方案实例[中篇]
2九、系统架构师-基础到企业应用架构-完整的架构方案实例[下篇]
30、系统架构师-基础到企业应用架构-总结及后续
下一篇将会已咱们将深刻的讲解功能分离的设计准则及实现方式,如何在设计中使用设计模式来构建知足高内聚、低耦合的功能模块等等。将经过实例化的方式对
每种原则及实现模式进行分析和举例。若是你们有好的意见和建议能够及时反馈,谢谢您的宝贵意见。
但愿看完本章的朋友能够从本篇中学到相应的软件设计规范,懂的人能够温习下相应设计准则,本篇但愿可以抛砖引玉,但愿你们可以多提出宝贵意见。因为是本
人平时工做中的理解与总结,不足之处再所不免,还请你们批评指出!若是您有什么意见或建议,请多多提出!你们的支持就是个人最大动力!