思考:如何使用技术框架?

  1. 境界一:直接用
  2. 境界二:简单封装后用
  3. 境界三:深度封装后用
  4. 境界四:可插拔的技术实现方案

2021年7月20日21:53:47 今天回过来看这些文字,发现自己写的很不成熟


昨天和同事沟通了某业务技术升级的工作思路,过去做的不好的地方,做如下思考。

某业务软件需要引用某技术框架,我们应该怎么做才好?

程序员技术良莠不齐做法各不相同,我大致对其分四个境界:

  • 境界一:直接用
  • 境界二:简单封装后用
  • 境界三:深度封装后用
  • 境界四:可插拔的技术实现方案

怎么理解以上四个境界?以 Java 项目引入 Redis 为例解释吧

境界一:直接用

大多数入门者的现状。

技术框架本身的代码开发已经让他喘不过气,能让业务系统正常运行已经很走运了,怎么还会去封装呢?

微弱的能力让他们不敢想,即使想了也做不好。

境界二:简单封装后用

有一定的开发经验,工作中用过一两三个技术框架的人通常都会如此。

即对 技术框架 本身做封装。

知道软件开发要解耦,于是基于功能点做简单封装后再用。

如项目中需要使用 redis,通常会定义包 com.xxxxx.redis,以 Redis 作为命名前缀,例如 RedisService、RedisUtil、RedisConfig。

然后在业务代码中使用 redisUtil.get(userId) ~

这种做法开发上比较简单,也很好理解。正因如此,即使是大型项目中也会出现这种不高级的写法。

境界三:深度封装后用

考虑到日后替换为更好的技术框架,在 境界二 的基础上封装后再用。

即对 业务系统技术框架 做桥梁。

怎么做到呢?

首先明确我们为什么要引入这个技术框架,找到它的存在意义,然后以 技术框架的存在意义 作为命名依据。

如业务系统引入 redis 的目的是数据缓存,那么这一层的命名关键词应该是 cache。

定义包 com.xxxxx.cache,以 Cache 作为命名前缀,例如 CacheService、CacheUtil、CacheConfig。

境界四:可插拔的技术实现方案

境界三和境界四的关系,就好比是 extend 和 implement 。

怎么做到呢?

考虑到日后替换为更好的技术框架,定义己方需要的接口,基于技术框架来实现接口,做到可插拔。

好的设计就该是可插拔的。


转载请注明来源。 欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。 可以在下面评论区评论,也可以邮件至 sharlot2050@foxmail.com。

文章标题:思考:如何使用技术框架?

字数:637

本文作者:夏来风

发布时间:2020-12-19, 13:03:10

原始链接:http://www.demo1024.com/blog/read-sikao-package-framework/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。