实现自己架构的主要手段

发布于: 2020 年 06 月 17 日
实现自己架构的主要手段

软件设计的目的使软件到达“强内聚、松耦合”,也就是说软件中的模块不会互相依赖导致一个对象or 模块的修改导致其他对象or模块的修改,这样软件可维护性、可扩展性就很差。好的软件设计应该是强内聚松耦合,从而是软件到达以下几点:

  • 易扩展

  • 更强壮

  • 可移植

  • 更简单

易扩展就是说容易增加新的功能,而不会影响到现有的功能和模块;

更强壮就是不容易被错误的操作、程序员的错误修改等给破坏;

可移植就是说可以在多种环境下运行;类似于Linux、Mac和windows下同时正常运行;

更简单就是说系统更容易被理解和维护;比如Netty框架的目录结构一般不超过3层,功能划分很明确好理解,同时组件和模块设计合理,维护性高。

相对的,不好的软件设计会发出如下"臭味":

  • 僵硬 不易改变

  • 脆弱 互相影响,改了一个另外一个就会受影响

  • 不可移植 不可适应环境变化

  • 导致无用的陷阱

  • 晦涩 代码难懂

  • 过度设计、copy-paste代码

  • 牢固性:设计中包含其他系统的有用部分,而把这些部分分离出来所要付出的努力是巨大的。

  • 粘滞性: 做正确的事情比做错误的事情更困难。

软件设计原则

OOD原则-:开闭原则(OCP)

  • 对于扩展是开放的

  • 对与更改是封闭的

不用修改软件实体就可以实现软件功能的扩展;

如上图,当我们有类似不同业务需求的时候,可以实现多个类来处理,避免在业务逻辑里面出现很if..else...修改业务逻辑,可以通过传递不同的WirelessInput 子类 or NetworkInput的不同实现,这样在input方法的参数里面可以使用接口类型,方便了业务的扩展, 同时不需要修改业务逻辑的具体代码。

方法一:策略模式

在button中抽象一个接口,然后在具体的实现类里面按需要实现具体的接口,这样在具体的逻辑里面调用各自的方法就可以完成不同的任务。

策略模式的处理可通过接口和继承就可以做到。

方法二:适配器模式

适配器模式就是在调用其他相同模块的相同功能时候,将被调用模块的功能进行包装,实现不同的处理逻辑,来满足具体业务需求,而具体的实现是不同的包装器类,具体在对Dailer的调用时就可以替换为具体的Adapter类实现就可以。

方法三:观察者模式

观察者模式解决的问题就是一些类依赖于另一个类的变化而变化,当被依赖的类发生状态变化时可以依次通知所有的观察者,通知对方我已经发生的某种变化,所有观察者也进行相应的操作。观察者应该是依赖反转的,就是依赖于接口和抽象,而不是具体的实现,这样可以扩展依赖的实际功能。

OOD原则二:依赖倒置原则(DIP)

  • 高层模块不能依赖低层模块,而是大家都依赖抽象

  • 抽象不能依赖实现,而是实现依赖抽象

依赖倒置倒置了什么?

  • 模块或包的依赖关系

  • 开发顺序和职责

框架的核心

好莱坞规则:

Don't call me, I'll call you.

如果要在软件设计中要求开发人员的编码规范就要定义框架结构,让开发人员按照框架结构来开发,从而是软件按照规范来开发和运行。

OOD原则三:Liskov替换原则(LSP)

重点说明了面向对象设计的重点继承,任何基类可以出现的地方,子类一定可以出现。

从Java语法的角度看,

  • 子类一定得拥有积累的整个接口

  • 子类的访问控制不能比基类更严格

OOD原则四:单一职责原则(SRP)

SRP - single responsibility principle

  • 内聚性原则

  • 一个模块的组成元素之间功能相关性

  • 将它与引起一个模块改变的作用力相连

  • 一个类只能有一个引起它变化的原因

OOD原则五:接口分离原则(ISP)

ISP - Interface Segregation Principle

  • 不应该强迫客户程序依赖他们不需要的方法

ISP和SRP的关系

  • ISP和SRP的相关性,都和内聚性有关

  • SRP指出应该如何设计一个类 -- 只有一个原因才能促使类发生改变

  • ISP指出应该如何设计一个接口--从客户的需求出发,强调不要让客户看到他们不需要的方法

用户头像

zyong

关注

还未添加个人签名 2018.09.26 加入

还未添加个人简介

评论

发布
暂无评论
实现自己架构的主要手段