超硬核!!每个华为架构师不愿意透露的10个设计原则。

目录

做软件开发多年,CRUD仿佛已经形成一种惯性,深入骨髓,按照常规的结构拆分:表现层、业务逻辑层、数据持久层,一个功能只需要个把小时代码就撸完了。

再结合CTRL+C和CTRL+V 绝世秘籍,一个个功能点便如同雨后春笋般被快速克隆实现。 是不是有种雄霸天下的感觉,管他什么业务场景,大爷我一梭到底,天下无敌!!!

可现实真的是这样?

答案不言而喻!!!

初入软件行业,很多人都会经历这个阶段。时间久了,很多人便产生困惑,能力并没有随着工作年限得到同比提升,焦虑失眠,如何改变现状?

悟性高的人,很快能从一堆乱麻中找到线索,并不断的提升自己的能力。 什么能力?

当然是软件架构能力,一名优秀的软件架构师,要具备复杂的业务系统的吞吐设计能力、抽象能力、扩展能力、稳定性。

如何培养这样能力?

image.png

我将常用的软件架构原则,做了汇总,目录如下:

image.png

当然这些原则有些是相互辅助,有些是相互矛盾的。实际项目开发中,要根据具体业务场景,灵活应对。千万不能教条主义,生搬硬套。

单一职责

我们在编码的时候,为了省事,总是喜欢在一个类中添加各种各样的功能。未来业务迭代时,再不断的修改这个类,导致后续的维护成本很高,耦合性大。牵一发而动全身。为了解决这个问题,我们在架构设计时通常会考虑单一职责

定义:

单一职责(SRP:Single Responsibility Principle),面向对象五个基本原则(SOLID)之一。每个功能只有一个职责,这样发生变化的原因也会只有一个。通过缩小职责范围,尽量减少错误的发生。

单一职责原则和一个类只干一件事之间,最大的差别就是,将变化纳入了考量。

代码要求:

一个接口、类、方法只负责一项职责,简单清晰。

优点

降低了类的复杂度,提高类的可读性、可维护性。进而提升系统的可维护性,降低变更引起的风险。

示例:

有一个用户服务接口UserService,提供了用户注册、登录、查询个人信息的方法,主要还是围绕用户相关的服务,看似合理。

public interface UserService
{
   
    // 注册接口
    Object register(Object param);
    // 登录接口
    Object login(Object param);
    // 查询用户信息
    Object queryUserInfoById(Long uid);
} 

过了几天,业务方提了一个需求,用户可以参加项目。简单的做法是在UserService类中增加一个 joinProject()方法 又过了几天,业务方又提了一个需求,统计一个用户参加过多少个项目,我们是不是又在UserService类中增加一个 countProject()方法

这样导致的后果是, UserService类 的职责越来越重,类会不断膨胀,内部的实现会越来越复杂。既要负责用户相关还有负责项目相关,后续任何一块业务变动,都会导致这个类的修改。

两类不同的需求,都改到同一个类。正确做法是,把不同的需求引起的变动拆分开,单独构建一个ProjectService类,专门负责项目相关的功能。

public interface ProjectService
{
   
    // 加入一个项目
    void addProject (Object param);
    // 统计一个用户参加过多少个项目
    void countProject(Object param);
}

这样带来的好处是,用户相关的需求只要改动 UserService。 如果是项目管理的需求,只需要改动 ProjectService。 二者各自变动的理由就少了很多。

开闭原则

开闭原则(OCP:Open-Closed Principle), 主要指一个类、方法、模块 等 对扩展开放,对修改关闭。简单来讲,一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。

个人感觉,开闭原则在所有的原则中最重要,像我们耳熟能详的23种设计模式,大部分都是遵循开闭原则,来解决代码的扩展性问题。

实现思路

采用抽象构建框架主体,用实现扩展细节。不同的业务采用不用的子类,尽量避免修改已有代码。

优点

  • 可复用性好。在软件完成以后,仍然可以对软件进行扩展,加入新的功能,非常灵活。因此,这个软件系统就可以通过不断地增加新的组件,来满足不断变化的需求。

  • 可维护性好。它的底层抽象相对固定,不用担心软件系统中原有组件的稳定性,这就使变化中的软件系统有一定的稳定性和延续性。

示例

比如有这样一个业务场景,我们的电商支付平台,需要接入一些支付渠道,项目刚启动时由于时间紧张,我们只接入微信支付,那么我们的代码这样写:

class WeixinPay
 {
   
    public Object pay(Object requestParam) 
    {
   
        // 请求微信完成支付
        // 省略。。。。
        
  • 22
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 20
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

牛战士从不脱下面具

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值