从到
理解
上帝的游戏
让我们先忘记枯燥的UML图,来做一次上帝的游戏.
我们把创造一个人简化成4个维度,样貌,体型,内心和气运. 每个维度3种变化.
样貌: 中庸,阳刚,阴柔
体型: 高大,矮小,适中
内心: 善良,邪恶,混沌.
气运: 位面之子,衰王之王,被忽视者.
我们一共可以拥有多少种人呢,一个人可以是阳刚,高大,善良,位面之子(请让我了结他),也可以是其他的.
我们有4个维度,每个维度3种变化.一共可以有种人.
如果他们都继承自Person类,也就有个类,那么很不幸,世界爆炸了,兄弟你内存爆炸了.
人可不只是这么几个维度,每个维度更是千变万化.
拯救上帝
幸好我们有别的办法.我们为每个维度建立抽象类/接口以及具体实现类.
一共4个维度,每个维度3种变化,所以我们有3 * 4个类.
在创造一个人的时候,我们在Person抽象类/接口中包含不同维度接口的引用.
abstract class Person{
// 都是接口或者抽象类
Look look;
Body body;
Spirit spirit;
Luck luck;
}
这样我只需要3*4=12个类就可以创造人类了,只需要set某个维度的实现类就可以了.
这也对应开头的,我们从到
.
回归精练且枯燥
一个作为桥接的接口，使得实体类的功能独立于接口实现类。这两种类型的类可被结构化改变而互不影响。
实现系统可从多种维度分类，桥接模式将各维度抽象出来，各维度独立变化，之后可通过聚合，将各维度组合起来，减少了各维度间的耦合。
体现的设计原则
- 开闭原则
增加一个维度只需要增加这个维度的抽象和实现就可以. - 单一职责原则
按维度划分类,更内聚. - 依赖倒置原则
使用了抽象类和接口.方便注入 - 里氏替换原则
使用了抽象类和接口,不依赖具体,引用可以指向具体的不同的实现类 - 迪米特法则
最少知道原则,通过引入一个合理的第三者降低现有对象之间的耦合度,我根本不想关心你具体是怎么实现的. - 接口隔离原则
不要用大而全的接口,使用小而独立的接口.
