为了账号安全,请及时绑定邮箱和手机立即绑定

从面向对象到面向架构

标签:
架构

学习面向对象编程思想时我们知道面向对象有三大特征,五大基本原则,三大特征是判断一种语言是否只是遵守面向对象思想的依据,而五大基本原则是软件设计以及开发的基本准则。很多书上都有讲解五大基本原则,但对遵守五大原则的原因所述不详。但其实五大基本原则不止可以应用到面向对象软件的功能设计上,在做架构设计时,更是要思考架构是否和五大基本原则的思想相悖,无论是侧重于复杂业务功能的传统软件公司还是侧重于保证系统可用性以及并发性的互联网公司,其软件架构设计都不应轻易打破五大原则得设计原则。

1 面向对象

1.1 单一职责原则

单一职责原则(Single-Responseibility Principle),从面向对象的设计上思考,一个类的功能只有一个,即引起这个类变化的原因只有一个,对于架构设计来说,单个服务或者单个模块只负责处理一件事,将与此事相关的业务封装在此模块内部,在功能上高内聚,尽量减少和其他模块的耦合度。遵守单一职责原则的好处是能消除耦合,从软件设计上来看能减少因需求变更带来的代码维护增加的工作量,从架构设计上看能减少单个模块故障的波及范围。

1.2 开放封闭原则

开放封闭原则(Open-Closed Principle),对扩展开发,对修改关闭,也就是说设计时,应开放系统有可能出现的扩展点,而对不会变更的功能的修改关闭。开闭原则是面向对象可复用设计的基石,同样在架构时也需要考虑系统的扩展性。

1.3 里氏替换原则

里氏替换原则是基于面向对象的继承特征,遵循此原则能使软件更加灵活,也能降低因需求变更对系统的影响范围。从架构设计的角度来看,模块的版本迭代应兼容之前的版本。

1.4 依赖倒置原则

依赖倒置原则,高层模块不应依赖于底层模块,他们都应依赖于抽象。使用多个专一的接口比是用一个总的接口要好,对客户类来说对另一个类的依赖应当建立在最小接口上。遵循此原则不会强迫客户依赖他不使用的方法,能减少耦合度,增加系统灵活度。

1.5 接口隔离原则

接口隔离原则要求,各个模块依赖与抽象,而不依赖与实现,面向接口编程而不是面向实现编程,好处是能降低耦合度。

综上,五大原则的目的都是为了降低系统耦合度,增强系统扩展性,模块内部高内聚,模块之间低耦合,同样架构设计时需要遵守的原则也是降低模块之间耦合度,增强扩展性,低耦合、高内聚能降低系统否则度,降低开发时沟通成本,降低上线后的网络成本。

2 面向架构

2.1 面向架构设计的“5+1”模型

webp

“5+1”架构视图

  • 用例视图(应用场景角度)

  • 逻辑架构视图(功能需求角度)

  • 开发架构视图(开发角度)

  • 运行架构视图(运行时)

  • 物理架构视图(运维)

  • 数据架构视图(持久化)

软件架构设计应是从多个角度的思考,但各个角度都应围绕着应用场景和功能需求,即围绕用户来展开。用户视图的的缺失会导致开发的软件与需求不相符,无法满足用户使用;开发视图的缺失会导致开发之间无休止的沟通,会不断的重复造轮子,使得越开发系统越复杂,最后很可能导致开发失败。运行架构的缺失会导致系统频繁故障,无法保证可用性。物理架构缺失会导致系统上线、下线困难,bug难以定位,故障排查困难。数据架构缺失会导致系统数据丢失,或数据出错,影响数据完整性,更严重的可能会造成重要数据丢失,难以恢复,造成难以估量的损失。

3 常见的几种软件架构模式

3.31分层架构

  1. 灵活性较低

  2. 易于部署

  3. 可测试性高

  4. 性能低(相对来说)

  5. 伸缩性低

  6. 易于开发

分层架构是的主要目的还是在于层内部的高内聚,层之间的低耦合,降低开发的服务度。

3.2 SOA架构

SOA架构是一种开发视图架构,SOA架构的原则:

  1. 服务封装

  2. 服务松耦合

  3. 服务契约

  4. 服务抽象

  5. 服务的可重用性

  6. 服务的可组合性

  7. 服务自治

  8. 服务无状态

  9. 服务的可被发现性

SOA侧重于服务的封装以及可重用,更像是对系统的一种水平拆分产生的架构模型,就像是分层架构下将某个层或者某个层的某一块作为一个单独的服务,是高内聚思想的一种体现。

3.3 微服务架构

  1. 扩展性好,各个服务之间低耦合

  2. 容易部署,软件从单一可部署单元,被拆成了多个服务,每个服务都是可部署单元

  3. 容易开发,每个组件都可以进行持续集成式的开发,可以做到实时部署,不间断地升级

  4. 易于测试,可以单独测试每一个服务

相比于SOA,微服务是一种用户视图架构,微服务是对系统的一种垂直拆分的架构模型,是一种低耦合思想的体现,微服务侧重于版本的快速迭代,微服务的另一个好处是单个业务模块的故障不会波及整个系统,降低了故障的影响范围,从这方面将它也是一种运行视图架构。微服务不是把服务做小了就是微服务,微服务的核心是从业务的角度降低个模块之间的耦合度。对于中小企业来说微服务架构的成本较高,设计难度较大。

总结

另外还有微内核架构、事件驱动架构,有兴趣可阅读《Software Architecture Patterns》一书。关于面向对象五大原则的理解讲的不是很清楚,但这个确实比较难以言传,如果身边有写代码的架构师,可以多阅读他们的代码,或者可以阅读一些开源组件的源码,对理解设计思想会有好处。



作者:梦想天空分为蓝
链接:https://www.jianshu.com/p/77e54bf5b1f1


点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
JAVA开发工程师
手记
粉丝
50
获赞与收藏
175

关注作者,订阅最新文章

阅读免费教程

  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消