浅谈架构之路

最新推荐文章于 2024-03-04 15:29:01 发布

weixin_49139548

最新推荐文章于 2024-03-04 15:29:01 发布

阅读量159

点赞数

文章标签：架构

本文链接：https://blog.csdn.net/weixin_49139548/article/details/121002458

版权

相信很多码农都想过自己有一天也能成为一名牛逼的架构师，我也是其中之一。以前觉得能手撸几个几个框架，搭个能跑起来的项目就算架构师了，但听完一堂孤尽老师讲的架构设计课，觉得之前的自己太过肤浅，架构师不是一个职位，而是一种能力，那么架构师需要怎样的能力呢？起码具备下面的几个技能才及格吧。

1.设计的架构具有可扩展性，可维护性。这就不得不说七大设计原则和23种设计模式了

单一功能原则

Single Responsibility Principle, SRP
核心思想：解耦和增强内聚性（高内聚，低耦合）
最简单也是最难做到的，人总有惰性，很多时候为了省事就把做不同事情的代码写到一块了，伪代码

public interface PhoneMessageServiceImpl implements IMessageService {

    /**
     * 发送短信
     * */
    public void sendMessage(String msg){
        System.out.println("发送短信");
    }

    /**
     * 发送Email
     * */
    public void sendEmail(String msg){
        System.out.println("发送Email");
    }
}

开闭原则

Open-Closed Principle, OCP
核心思想：对扩展开放，对修改关闭
扩展开放：模块添加新功能，不改变原有的代码，扩展京东支付，银联支付只需实现支付接口即可
修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的，伪代码

public interface Ipay {
    /**
     * 支付接口
     * */
    void pay(); 
}

public class WXPayImpl implements IPay{

    @Override
    public void pay() {
        System.out.println("微信支付");
    }
}


public class AliPayImpl implements IPay {

    @Override
    public void pay() {
        System.out.println("支付宝支付");
    }
}

public class Pay{

   public void toPay(IPay iPay){
       iPay.pay();
   }

    public static void main(String[] args) {
        Pay pay = new Pay();
        pay.toPay(new AliPayImpl());
//        pay.toPay(new WXPayImpl());
    }
}

里氏替换原则

Liskov Substitution Principle, LSP
核心思想：任何父类出现的地方，子类都可以替代出现，用父类去替换，一般都会出现问题
反例伪代码：


public class TrainNumber {

    /**
     * 车次
     * */
    public String trainNumber;

    /**
     * 始发站
     * */
    public String startStation;
    /**
     * 终点站
     * */
    public String endStation;

    /**
     * 途径站
     * */
    public List<Stop> stopStation;
}

public Ticket extands TrainNumber {

    /**
    * 座位类型
    */
    SeatType seatType ;

    /**
    * 座位号
    */
    String seatNo ;
    
}

依赖倒转原则
- Dependence Inversion Principle, DIP
- 核心思想：要依赖于抽象，不要依赖于具体的实现
接口分离原则
- Interface Segregation Principle, ISP
- 核心思想：不应该强迫客户程序依赖他们不需要使用的方法
- 一个接口不需要提供太多的行为，一个接口应该只提供一种对外的功能，不应该把所有的操作都封装到一个接口当中，反例伪代码
- ```
public interface InterfaceDemo{

    /**
     * 支付接口
     * */
    void pay();

    /**
     * 退款接口
     * */
    void refund();

    /**
     * 同意退款接口
     * */
    void agreeRefund();
}
```

合成复用原则

Composite Reuse Principle, CRP
核心思想：尽量使用对象组合，而不是继承来达到复用的目的
继承关系是强耦合，组合关系是低耦合，正例伪代码

public class PayServiceImpl{

    /**
     * 以组合方式引入订单服务
     * */
    @Autowired
    OrderService orderService;

    /**
     * 以组合方式引入车票服务
     * */
    @Autowired
    TicketService ticketService;
}

迪米特原则
- Law of Demeter, LoD
- 核心思想：一个对象应当对其他对象有尽可能少的了解,不和陌生人说话
- 降低各个对象之间的耦合，提高系统的可维护性

23种设计模式也是符合七大设计原则的，内容太多，这里就不赘述了

2.设计架构图，那么如何画好架构图呢？（后续补充）

        第一，搞清楚要画的架构图的类型
        第二，确认架构图中的关键要素（比如产品、技术、服务）
        第三，梳理关键要素之间的关联：包含、支撑、同级并列等
        第四，输出关联关系清晰的架构图

3.设计类图，时序图（后续补充）

在设计类图之前必须先弄清楚类的关系

泛化关系：即继承关系
        实现关系：实现接口
        聚合关系：业务上整体与部分可以分开，是关联关系的特例
        组合关系：业务上整体与部分不可以分开，同样是是关联关系的特例
        依赖关系：只要在类中用到了对方，就存在依赖关系
        关联关系：体现的是业务逻辑的关系，是依赖关系的特例，具有导航性&多重性

weixin_49139548

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
浅谈架构之路

相信很多码农都想过自己有一天也能成为一名牛逼的架构师，我也是其中之一。以前觉得能手撸几个几个框架，搭个能跑起来的项目就算架构师了，但听完一堂孤尽老师讲的架构设计课，觉得之前的自己太过肤浅，架构师不是一个职位，而是一种能力，那么架构师需要怎样的能力呢？起码具备下面的几个技能才及格吧。1.设计的架构具有可扩展性，可维护性。这就不得不说七大设计原则和23种设计模式了单一功能原则 Single Responsibility Principle, SRP 核心思想：解耦和增强内聚
复制链接

扫一扫