File tree 1 file changed +5
-5
lines changed
1 file changed +5
-5
lines changed Original file line number Diff line number Diff line change 47
47
48
48
> 近来,你发现人们对面向对象语言的继承进行批判。继承是有问题的 -- 在代码基中没有比基类与子类之间更深的耦合了 -- 但是我发现宽的继承树比深的要表现的更好。
49
49
50
- #模式
50
+ # (沙盒) 模式
51
51
一个__ 基类__ 定义了一个抽象的__ 沙盒方法__ 和一些__ 提供的操作__ 。通过设置他们为保护状态能够明确他们是被子类使用。每个继承的__ 沙盒子类__ 通过提供的操作来实现沙盒函数。
52
52
53
- #什么时候使用
53
+ # 使用情境
54
54
沙盒模式是一种运用在大量代码基里甚至游戏之外的非常简单通用的模式。如果你有一个非虚拟的保护函数,那么你很有可能正在使用类似该模式的东西。沙盒模式在以下情况比较适用:
55
55
56
56
- 你有一个带有大量子类的基类。
61
61
62
62
- 你想使这些继承类与程序的其他代码之间的耦合最小化。
63
63
64
- #记住
64
+ #使用须知
65
65
“继承”一词最近在一些程序圈子里被视为诟病,其中一个原因是基类会滋生越来越多的代码。这个模式尤其受这个因素的影响。
66
66
67
67
由于子类是通过它们的基类来实现剩下的游戏,基类最终会与所有子类需要交互的系统产生耦合。当然,这些子类也与他们的基类绑定。这个蜘蛛网式的耦合使得在不破坏什么的情况下改变基类是很困难的 -- 你遇到了[ 脆弱的基类问题] ( http://en.wikipedia.org/wiki/Fragile_base_class ) 。
70
70
71
71
如果你仍然发现这个模式正把你的基类推向一碗巨大的代码汤里的话,请考虑把一些提供的操作提取到一个基类能够管理的独立的类中。这里[ 组件模式] ( ./05.1-Component.md ) 能够有所帮助。
72
72
73
- #示例代码
73
+ #示例
74
74
由于这是一个如此简单的设计模式,并没有多少的示例代码。这不意味着这没有用 -- 这个模式的实现关乎的是其意义而不是其复杂度。
75
75
76
76
我们将从我们得Superpower基类开始:
@@ -396,7 +396,7 @@ protected:
396
396
```
397
397
这里,spawnParticles()需要一个粒子系统。它从服务定位器获取了一个,而不是通过外部代码获取。
398
398
399
- #也看看
399
+ #参考
400
400
- 当你使用[ 更新函数] (./03.3-Update Method.md)模式的时候,你的更新函数通常也是一个沙盒函数。
401
401
402
402
- 这个模式一个[ 模板函数] ( http://en.wikipedia.org/wiki/Template_method_pattern ) 模式的一个反面角色。在这两个模式中,你使用一些列原始操作实现一个函数。通过子类沙盒模式,函数在继承类中,原始操作则在基类中。通过模板函数,基类有函数,原始操作被继承类实现。
You can’t perform that action at this time.
0 commit comments