系统设计之万般皆组件思想

任何系统,都是服务于业务的,所有的业务最终都会被实现为组件,组件可以体现为一个类、一个代码模块、一个包等等。

首先我们要分清楚对象实例和类的关系:

1 对象

对象是和系统的线程模型等架构设计紧密相关的。在系统运行过程中,可能会有许许多多的线程,此外不同的系统的线程模型也不一样,比如有的系统采用单线程reactor模型,这种模型为了保证系统的高吞吐量,可能一个对象只会关联到一个线程来避免多线程访问同一对象导致的加锁等待;有的系统可能采用传统的线程池模型,这种模型即有可能一个对象关联一个线程,也有可能一个对象被多个线程访问(可能会导致线程加锁等待)。

2 类

类是和我们的业务逻辑紧密相关的,所有的我们的业务逻辑,最终都转换成我们程序员编码的一个个业务类。我们可以发现,不管在系统运行时期到底存在几个某类的对象,我们编写业务的时候始终只写了一份类。

好了,本文要讲述的中心思想来了:

1 任何系统设计的时候,对于我们的业务实现,都可以归结为组件化思想!

2 对于系统的线程模型设计,我们要和业务组件设计分离,来达到业务组件设计和系统线运行架构设计的解耦和分离!

业务组件设计和系统运行架构设计分离的好处是显而易见的:

# 理想的情况下,我们可以把我们实现的业务组件作为一个插件的形式放到任何线程模型的容器中运行!

# 我们可以单独设计系统线程模型层,这个层负责考虑使用单例的业务组件还是多例的业务组件,清晰的实现系统架构的分层解耦。

下面举个这种思想的例子:

spring工厂! 工厂中注册了许许多多的我们的业务组件,由工厂层面负责给上层业务调用层提供单例或者多例的业务组件对象!

这样,我们在编写业务的时候只需要按spring bean的规定方式提供相应的业务组件类就可以了,大大清晰了业务编程!

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值