实现自己架构的主要手段

软件设计的目的使软件到达“强内聚、松耦合”，也就是说软件中的模块不会互相依赖导致一个对象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指出应该如何设计一个接口--从客户的需求出发，强调不要让客户看到他们不需要的方法