forked from munificent/game-programming-patterns
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathtype-object.html
More file actions
851 lines (778 loc) · 51.4 KB
/
Copy pathtype-object.html
File metadata and controls
851 lines (778 loc) · 51.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
<title>Type Object · Behavioral Patterns · Game Programming Patterns</title>
<!-- Tell mobile browsers we're optimized for them and they don't need to crop
the viewport. -->
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<link rel="stylesheet" type="text/css" href="style.css" />
<link href="http://fonts.googleapis.com/css?family=Merriweather:400,400italic,700,700italic|Source+Code+Pro|Source+Sans+Pro:200,300,400,600,400italic,600italic|Rock+Salt" rel="stylesheet" type="text/css">
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-42804721-1', 'gameprogrammingpatterns.com');
ga('send', 'pageview');
</script>
<script src="jquery-1.10.1.min.js"></script>
<script src="script.js"></script>
</head>
<body id="top">
<div class="page sidebar">
<div class="content">
<nav class="top">
<span class="prev">← <a href="subclass-sandbox.html">Previous Chapter</a></span>
<span class="next"><a href="decoupling-patterns.html">Next Chapter</a> →</span>
<span class="toc">≡ <a href="/">The Book</a></span>
</nav>
<h1>Type Object</h1>
<h1 class="book"><a href="/">Game Programming Patterns</a><span class="section"><a href="behavioral-patterns.html">Behavioral Patterns</a></span></h1>
<h2><a href="#intent" name="intent">Intent</a></h2>
<p><em>Allow the flexible creation of new “classes” by creating a single class, each
instance of which represents a different type of object.</em></p>
<h2><a href="#motivation" name="motivation">Motivation</a></h2>
<p>Imagine we’re working on a fantasy role-playing game. Our task is to write the
code for the hordes of vicious monsters that seek to slay our brave hero.
Monsters have a bunch of different attributes: health, attacks, graphics,
sounds, etc., but for example purposes we’ll just worry about the first two.</p>
<p>Each monster in the game has a value for its current health. It starts out full,
and each time the monster is wounded, it diminishes. Monsters also have an
attack string. When the monster attacks our hero, that text will be shown to the
user somehow. (We don’t care how here.)</p>
<p>The designers tell us that monsters come in a variety of different <em>breeds</em>,
like “dragon” or “troll”. Each breed describes a <em>kind</em> of monster that exists
in the game, and there can be multiple monsters of the same breed running around
in the dungeon at the same time.</p>
<p>The breed determines a monster’s starting health — dragons start off with more
than trolls, making them harder to kill. It also determines the attack string —
all monsters of the same breed attack the same way.</p>
<h3><a href="#the-typical-oop-answer" name="the-typical-oop-answer">The typical OOP answer</a></h3>
<p>With that game design in mind, we fire up our text editor and start coding. According
to the design, a dragon <span name="isa">is a</span> kind of monster, a troll is
another kind, and so on with the other breeds. Thinking object-oriented, that
leads us to a <code>Monster</code> base class:</p>
<aside name="isa">
<p>This is the so-called “is-a” relationship. In conventional OOP thinking, since a
dragon “is-a” monster, we model that by making <code>Dragon</code> a subclass of <code>Monster</code>. As
we’ll see, subclassing is only one way of enshrining a conceptual relation like
that into code.</p>
</aside>
<div class="codehilite"><pre><span class="k">class</span> <span class="nc">Monster</span>
<span class="p">{</span>
<span class="nl">public:</span>
<span class="k">virtual</span> <span class="o">~</span><span class="n">Monster</span><span class="p">()</span> <span class="p">{}</span>
<span class="k">virtual</span> <span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">getAttack</span><span class="p">()</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
<span class="nl">protected:</span>
<span class="n">Monster</span><span class="p">(</span><span class="kt">int</span> <span class="n">startingHealth</span><span class="p">)</span>
<span class="o">:</span> <span class="n">health_</span><span class="p">(</span><span class="n">startingHealth</span><span class="p">)</span>
<span class="p">{}</span>
<span class="nl">private:</span>
<span class="kt">int</span> <span class="n">health_</span><span class="p">;</span> <span class="c1">// Current health.</span>
<span class="p">};</span>
</pre></div>
<p>The public <code>getAttack()</code> function lets the combat code get the string that
should be displayed when the monster attacks the hero. Each derived breed class
will override this to provide a different message.</p>
<p>The constructor is protected and takes the starting health for the monster.
We’ll have derived classes for each breed that provide their own public
constructors that call this one, passing in the starting health that is
appropriate for that breed.</p>
<p>Now let’s see a couple of breed subclasses:</p>
<p><span name="exclaim"></span></p>
<div class="codehilite"><pre><span class="k">class</span> <span class="nc">Dragon</span> <span class="o">:</span> <span class="k">public</span> <span class="n">Monster</span>
<span class="p">{</span>
<span class="nl">public:</span>
<span class="n">Dragon</span><span class="p">()</span> <span class="o">:</span> <span class="n">Monster</span><span class="p">(</span><span class="mi">230</span><span class="p">)</span> <span class="p">{}</span>
<span class="k">virtual</span> <span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">getAttack</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">return</span> <span class="s">"The dragon breathes fire!"</span><span class="p">;</span>
<span class="p">}</span>
<span class="p">};</span>
<span class="k">class</span> <span class="nc">Troll</span> <span class="o">:</span> <span class="k">public</span> <span class="n">Monster</span>
<span class="p">{</span>
<span class="nl">public:</span>
<span class="n">Troll</span><span class="p">()</span> <span class="o">:</span> <span class="n">Monster</span><span class="p">(</span><span class="mi">48</span><span class="p">)</span> <span class="p">{}</span>
<span class="k">virtual</span> <span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">getAttack</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">return</span> <span class="s">"The troll clubs you!"</span><span class="p">;</span>
<span class="p">}</span>
<span class="p">};</span>
</pre></div>
<aside name="exclaim">
<p>Exclamation points make everything more exciting!</p>
</aside>
<p>Each class derived from <code>Monster</code> passes in the starting health and overrides
<code>getAttack()</code> to return the attack string for that breed. Everything works as
expected, and before long, we’ve got our hero running around slaying a variety of
beasties. We keep slinging code, and before we know it, we’ve got dozens of
monster subclasses, from acidic slimes to zombie goats.</p>
<p>Then, strangely, things start to bog down. Our designers ultimately want to have
<em>hundreds</em> of breeds, and we find ourselves spending all of our time writing
these little seven-line subclasses and recompiling. It gets worse — the designers
want to start tuning the breeds we’ve already coded. Our formerly productive
workday degenerates to:</p>
<ol>
<li>
<p>Get email from designer asking to change health of troll from
48 to 52.</p>
</li>
<li>
<p>Check out and change <code>Troll.h</code>.</p>
</li>
<li>
<p>Recompile game.</p>
</li>
<li>
<p>Check in change.</p>
</li>
<li>
<p>Reply to email.</p>
</li>
<li>
<p>Repeat.</p>
</li>
</ol>
<p>We spend the day frustrated because we’ve turned into data monkeys. Our
designers are frustrated because it takes them forever to get a simple
number tuned. What we need is the ability to change breed stats without having
to recompile the whole game every time. Even better, we’d like designers to be
able to create and tune breeds without <em>any</em> programmer intervention at all.</p>
<h3><a href="#a-class-for-a-class" name="a-class-for-a-class">A class for a class</a></h3>
<p>At a very high level, the problem we’re trying to solve is pretty simple. We
have a bunch of different monsters in the game, and we want to share certain
attributes between them. A horde of monsters are beating on the hero, and we
want some of them to use the same text for their attack. We define that by
saying that all of those monsters are the same “breed”, and that the breed
determines the attack string.</p>
<p>We decided to implement this concept using inheritance since it lines up with
our intuition of classes. A dragon is a monster, and each dragon in the game is
an instance of this dragon “class”. Defining each breed as a subclass of an
abstract base <code>Monster</code> class, and having each monster in the game be an
instance of that derived breed class mirrors that. We end up with a class
hierarchy like this:</p>
<p><span name="inherits-arrow"></span></p>
<p><img src="images/type-object-subclasses.png" alt="A Monster base class with derived classes for Dragon, Troll, etc." /></p>
<aside name="inherits-arrow">
<p>Here, the <img src="images/arrow-inherits.png" class="arrow" alt="A UML arrow representing inheritance." /> means “inherits
from”.</p>
</aside>
<p>Each instance of a monster in the game will be of one of the derived monster
types. The more breeds we have, the bigger the class hierarchy. That’s the
problem of course: adding new breeds means adding new code, and each breed has
to be compiled in as its own type.</p>
<p>This works, but it isn’t the only option. We could also architect our code so
that each monster <em>has</em> a breed. Instead of subclassing <code>Monster</code> for each
breed, we have a single <code>Monster</code> class and a single <code>Breed</code> class:</p>
<p><span name="references-arrow"></span></p>
<p><img src="images/type-object-breed.png" alt="A Monster object has a reference to a Breed object." /></p>
<aside name="references-arrow">
<p>Here, the <img src="images/arrow-references.png" class="arrow" alt="A UML arrow for an object reference." /> means “is
referenced by”.</p>
</aside>
<p>That’s it. Two classes. Notice that there’s no inheritance at all. With this
system, each monster in the game is simply an instance of class <code>Monster</code>. The
<code>Breed</code> class contains the information that’s shared between all monsters of the
same breed: starting health and the attack string.</p>
<p>To associate monsters with breeds, we give each <code>Monster</code> instance a reference
to a <code>Breed</code> object containing the information for that breed. To get the attack
string, a monster just calls a method on its breed. The <code>Breed</code> class
essentially defines a monster’s “type”. Each breed instance is an <em>object</em> that
represents a different conceptual <em>type</em>, hence the name of the pattern: Type
Object.</p>
<p>What’s especially powerful about this pattern is that now we can define new
<em>types</em> of things without complicating the codebase at all. We’ve essentially
lifted a portion of the type system out of the hard-coded class hierarchy into
data we can define at runtime.</p>
<p>We can create hundreds of different breeds by instantiating more instances
of <code>Breed</code> with different values. If we create breeds by initializing them from
data read from some configuration file, we have the ability to define new types
of monsters completely in data. So easy, a designer could do it!</p>
<h2><a href="#the-pattern" name="the-pattern">The Pattern</a></h2>
<p>Define a <strong>type object</strong> class and a <strong>typed object</strong> class. Each type object
instance represents a different logical type. Each typed object stores a
<strong>reference to the type object that describes its type</strong>.</p>
<p>Instance-specific data is stored in the typed object instance, and data or
behavior that should be shared across all instances of the same conceptual type
is stored in the type object. Objects referencing the same type object will
function as if they were the same type. This lets us share data and behavior
across a set of similar objects, much like subclassing lets us do, but without
having a fixed set of hard-coded subclasses.</p>
<h2><a href="#when-to-use-it" name="when-to-use-it">When to Use It</a></h2>
<p>This pattern is useful anytime you need to define a variety of different “kinds”
of things, but baking the kinds into your language’s type system is too rigid.
In particular, it’s useful when either of these is true:</p>
<ul>
<li>
<p>You don’t know what types you will need up front. (For example, what if our
game needed to support downloading content that contained new breeds of
monsters?)</p>
</li>
<li>
<p>You want to be able to modify or add new types without having to recompile
or change code.</p>
</li>
</ul>
<h2><a href="#keep-in-mind" name="keep-in-mind">Keep in Mind</a></h2>
<p>This pattern is about moving the definition of a “type” from the imperative but
rigid language of code into the more flexible but less behavioral world of
objects in memory. The flexibility is good, but you lose some things by hoisting
your types into data.</p>
<h3><a href="#the-type-objects-have-to-be-tracked-manually" name="the-type-objects-have-to-be-tracked-manually">The type objects have to be tracked manually</a></h3>
<p>One advantage of using something like <span name="vtable">C++’s</span> type
system is that the compiler handles all of the bookkeeping for the classes
automatically. The data that defines each class is automatically compiled into
the static memory segment of the executable and just works.</p>
<p>With the Type Object pattern, we are now responsible for managing not only our
monsters in memory, but also their <em>types</em> — we have to make sure all of the
breed objects are instantiated and kept in memory as long as our monsters need
them. Whenever we create a new monster, it’s up to us to ensure that it’s
correctly initialized with a reference to a valid breed.</p>
<p>We’ve freed ourselves from some of the limitations of the compiler, but the cost
is that we have to re-implement some of what it used to be doing for us.</p>
<aside name="vtable">
<p>Under the hood, C++ virtual methods are implemented using something called a
“virtual function table”, or just “vtable”. A vtable is a simple <code>struct</code>
containing a set of function pointers, one for each virtual method in a class.
There is one vtable in memory for each class. Each instance of a class has a
pointer to the vtable for its class.</p>
<p>When you call a virtual function, the code first looks up the vtable for the
object, then it calls the function stored in the appropriate function pointer in
the table.</p>
<p>Sound familiar? The vtable is our breed object, and the pointer to the vtable is
the reference the monster holds to its breed. C++ classes are the Type Object
pattern applied to C, handled automatically by the compiler.</p>
</aside>
<h3><a href="#it's-harder-to-define-*behavior*-for-each-type" name="it's-harder-to-define-*behavior*-for-each-type">It’s harder to define <em>behavior</em> for each type</a></h3>
<p>With subclassing, you can override a method and do whatever you want to —
calculate values procedurally, call other code, etc. The sky is the limit. We
could define a monster subclass whose attack string changed based on the phase
of the moon if we wanted to. (Handy for werewolves, I suppose.)</p>
<p>When we use the Type Object pattern instead, we replace an overridden method
with a member variable. Instead of having monster subclasses that override a
method to <em>calculate</em> an attack string using different <em>code</em>, we have a breed
object that <em>stores</em> an attack string in a different <em>variable</em>.</p>
<p>This makes it very easy to use type objects to define type-specific <em>data</em>, but
hard to define type-specific <em>behavior</em>. If, for example, different breeds of
monster needed to use different AI algorithms, using this pattern becomes more
challenging.</p>
<p>There are a couple of ways we can get around this limitation. A simple solution
is to have a fixed set of pre-defined behaviors and then use data in the type
object to simply <em>select</em> one of them. For example, let’s say our monster AI
will always be either “stand still”, “chase hero”, or “whimper and cower in
fear” (hey, they can’t all be mighty dragons). We can define <span
name="fn">functions</span> to implement each of those behaviors. Then, we can
associate an AI algorithm with a breed by having it store a pointer to
the appropriate function.</p>
<aside name="fn">
<p>Sound familiar again? Now we’re back to really implementing vtables in <em>our</em>
type objects.</p>
</aside>
<p>Another more powerful solution is to actually support defining behavior
completely in <span name="data">data</span>. The <a class="gof-pattern"
href="http://c2.com/cgi-bin/wiki?InterpreterPattern">Interpreter</a> and <a
class="pattern" href="bytecode.html">Bytecode</a> patterns both let us build
objects that represent behavior. If we read in a data file and use that to
create a data structure for one of these patterns, we’ve moved the behavior’s
definition completely out of code and into content.</p>
<aside name="data">
<p>Over time, games are getting more data-driven. Hardware gets more powerful, and
we find ourselves limited more by how much content we can author than how hard
we can push the hardware. With a 64K cartridge, the challenge was <em>cramming</em> the
gameplay into it. With a double-sided DVD, the challenge is <em>filling</em> it with
gameplay.</p>
<p>Scripting languages and other higher-level ways of defining game behavior can
give us a much needed productivity boost, at the expense of less optimal runtime
performance. Since hardware keeps getting better but our brainpower doesn’t,
that trade-off starts to make more and more sense.</p>
</aside>
<h2><a href="#sample-code" name="sample-code">Sample Code</a></h2>
<p>For our first pass at an implementation, let’s start simple and build the basic
system described in the motivation section. We’ll start with the <code>Breed</code>
class:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="nc">Breed</span>
<span class="p">{</span>
<span class="nl">public:</span>
<span class="n">Breed</span><span class="p">(</span><span class="kt">int</span> <span class="n">health</span><span class="p">,</span> <span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">attack</span><span class="p">)</span>
<span class="o">:</span> <span class="n">health_</span><span class="p">(</span><span class="n">health</span><span class="p">),</span>
<span class="n">attack_</span><span class="p">(</span><span class="n">attack</span><span class="p">)</span>
<span class="p">{}</span>
<span class="kt">int</span> <span class="n">getHealth</span><span class="p">()</span> <span class="p">{</span> <span class="k">return</span> <span class="n">health_</span><span class="p">;</span> <span class="p">}</span>
<span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">getAttack</span><span class="p">()</span> <span class="p">{</span> <span class="k">return</span> <span class="n">attack_</span><span class="p">;</span> <span class="p">}</span>
<span class="nl">private:</span>
<span class="kt">int</span> <span class="n">health_</span><span class="p">;</span> <span class="c1">// Starting health.</span>
<span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">attack_</span><span class="p">;</span>
<span class="p">};</span>
</pre></div>
<p>Very simple. It’s basically just a container for two data fields: the starting
health and the attack string. Let’s see how monsters use it:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="nc">Monster</span>
<span class="p">{</span>
<span class="nl">public:</span>
<span class="n">Monster</span><span class="p">(</span><span class="n">Breed</span><span class="o">&</span> <span class="n">breed</span><span class="p">)</span>
<span class="o">:</span> <span class="n">health_</span><span class="p">(</span><span class="n">breed</span><span class="p">.</span><span class="n">getHealth</span><span class="p">()),</span>
<span class="n">breed_</span><span class="p">(</span><span class="n">breed</span><span class="p">)</span>
<span class="p">{}</span>
<span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">getAttack</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">return</span> <span class="n">breed_</span><span class="p">.</span><span class="n">getAttack</span><span class="p">();</span>
<span class="p">}</span>
<span class="nl">private:</span>
<span class="kt">int</span> <span class="n">health_</span><span class="p">;</span> <span class="c1">// Current health.</span>
<span class="n">Breed</span><span class="o">&</span> <span class="n">breed_</span><span class="p">;</span>
<span class="p">};</span>
</pre></div>
<p>When we construct a monster, we give it a reference to a breed object. This
defines the monster’s breed instead of the subclasses we were previously using.
In the constructor, <code>Monster</code> uses the breed to determine its starting health.
To get the attack string, the monster simply forwards the call to its breed.</p>
<p>This very simple chunk of code is the core idea of the pattern. Everything from
here on out is bonus.</p>
<h3><a href="#making-type-objects-more-like-types-constructors" name="making-type-objects-more-like-types-constructors">Making type objects more like types: constructors</a></h3>
<p>With what we have now, we construct a monster directly and are responsible for
passing in its breed. This is a bit backwards from how regular objects are
instantiated in most OOP languages — we don’t usually allocate a blank chunk of
memory and then <em>give</em> it its class. Instead, we call a constructor function on
the class itself, and it’s responsible for giving us a new instance.</p>
<p>We can apply this same <span name="pattern">pattern</span> to our type objects:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="nc">Breed</span>
<span class="p">{</span>
<span class="nl">public:</span>
<span class="n">Monster</span><span class="o">*</span> <span class="n">newMonster</span><span class="p">()</span> <span class="p">{</span> <span class="k">return</span> <span class="k">new</span> <span class="n">Monster</span><span class="p">(</span><span class="o">*</span><span class="k">this</span><span class="p">);</span> <span class="p">}</span>
<span class="c1">// Previous Breed code...</span>
<span class="p">};</span>
</pre></div>
<aside name="pattern">
<p>“Pattern” is the right word here. What we’re talking about is one of the classic
patterns from Design Patterns: <a class="gof-pattern"
href="http://c2.com/cgi/wiki?FactoryMethodPattern">Factory Method</a>.</p>
<p>In some languages, this pattern is applied for constructing <em>all</em> objects. In
Ruby, Smalltalk, Objective-C, and other languages where classes are objects, you
construct new instances by calling a method on the class object itself.</p>
</aside>
<p>And the class that uses them:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="nc">Monster</span>
<span class="p">{</span>
<span class="k">friend</span> <span class="k">class</span> <span class="nc">Breed</span><span class="p">;</span>
<span class="nl">public:</span>
<span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="nf">getAttack</span><span class="p">()</span> <span class="p">{</span> <span class="k">return</span> <span class="n">breed_</span><span class="p">.</span><span class="n">getAttack</span><span class="p">();</span> <span class="p">}</span>
<span class="nl">private:</span>
<span class="n">Monster</span><span class="p">(</span><span class="n">Breed</span><span class="o">&</span> <span class="n">breed</span><span class="p">)</span>
<span class="o">:</span> <span class="n">health_</span><span class="p">(</span><span class="n">breed</span><span class="p">.</span><span class="n">getHealth</span><span class="p">()),</span>
<span class="n">breed_</span><span class="p">(</span><span class="n">breed</span><span class="p">)</span>
<span class="p">{}</span>
<span class="kt">int</span> <span class="n">health_</span><span class="p">;</span> <span class="c1">// Current health.</span>
<span class="n">Breed</span><span class="o">&</span> <span class="n">breed_</span><span class="p">;</span>
<span class="p">};</span>
</pre></div>
<p>The key <span name="friend">difference</span> is the <code>newMonster()</code> function in
<code>Breed</code>. That’s our “constructor” factory method. With our original
implementation, creating a monster looked like:</p>
<aside name="friend">
<p>There’s another minor difference here. Because the sample code is in C++, we can
use a handy little feature: <em>friend classes.</em></p>
<p>We’ve made <code>Monster</code>’s constructor private, which prevents anyone from
calling it directly. Friend classes sidestep that restriction so <code>Breed</code> can
still access it. This means the <em>only</em> way to create monsters is by going
through <code>newMonster()</code>.</p>
</aside>
<div class="codehilite"><pre><span class="n">Monster</span><span class="o">*</span> <span class="n">monster</span> <span class="o">=</span> <span class="k">new</span> <span class="n">Monster</span><span class="p">(</span><span class="n">someBreed</span><span class="p">);</span>
</pre></div>
<p>After our changes, it’s like this:</p>
<div class="codehilite"><pre><span class="n">Monster</span><span class="o">*</span> <span class="n">monster</span> <span class="o">=</span> <span class="n">someBreed</span><span class="p">.</span><span class="n">newMonster</span><span class="p">();</span>
</pre></div>
<p>So, why do this? There are two steps to creating an object: allocation and
initialization. <code>Monster</code>’s constructor lets us do all of the
initialization we need. In our example, that’s only storing the breed, but a
full game would be loading graphics, initializing the monster’s AI, and doing
other set-up work.</p>
<p>However, that all happens <em>after</em> allocation. We’ve already got a chunk of
memory to put our monster into before its constructor is called. In games, we
often want to control that aspect of object creation too: we’ll typically use
things like custom allocators or the <a class="pattern"
href="object-pool.html">Object Pool</a> pattern to control where in memory our
objects end up.</p>
<p>Defining a “constructor” function in <code>Breed</code> gives us a place to put that logic.
Instead of simply calling <code>new</code>, the <code>newMonster()</code> function can pull the memory
from a pool or custom heap before passing control off to <code>Monster</code> for
initialization. By putting this logic inside <code>Breed</code>, in the <em>only</em> function
that has the ability to create monsters, we ensure that all monsters go through
the memory management scheme we want.</p>
<h3><a href="#sharing-data-through-inheritance" name="sharing-data-through-inheritance">Sharing data through inheritance</a></h3>
<p>What we have so far is a perfectly serviceable type object system, but it’s
pretty basic. Our game will eventually have <em>hundreds</em> of different breeds, each
with dozens of attributes. If a designer wants to tune all of the thirty
different breeds of troll to make them a little stronger, she’s got a lot of
tedious data entry ahead of her.</p>
<p>What would help is the ability to share attributes across multiple <em>breeds</em> in
the same way that breeds let us share attributes across multiple <em>monsters</em>.
Just like we did with our original OOP solution, we can solve this using
inheritance. Only, this time, instead of using our language’s inheritance
mechanism, we’ll implement it ourselves within our type objects.</p>
<p>To keep things simple, we’ll only support single inheritance. In the same way
that a class can have a parent base class, we’ll allow a breed to have a parent
breed:</p>
<div class="codehilite"><pre><span class="k">class</span> <span class="nc">Breed</span>
<span class="p">{</span>
<span class="nl">public:</span>
<span class="n">Breed</span><span class="p">(</span><span class="n">Breed</span><span class="o">*</span> <span class="n">parent</span><span class="p">,</span> <span class="kt">int</span> <span class="n">health</span><span class="p">,</span> <span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">attack</span><span class="p">)</span>
<span class="o">:</span> <span class="n">parent_</span><span class="p">(</span><span class="n">parent</span><span class="p">),</span>
<span class="n">health_</span><span class="p">(</span><span class="n">health</span><span class="p">),</span>
<span class="n">attack_</span><span class="p">(</span><span class="n">attack</span><span class="p">)</span>
<span class="p">{}</span>
<span class="kt">int</span> <span class="n">getHealth</span><span class="p">();</span>
<span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="nf">getAttack</span><span class="p">();</span>
<span class="nl">private:</span>
<span class="n">Breed</span><span class="o">*</span> <span class="n">parent_</span><span class="p">;</span>
<span class="kt">int</span> <span class="n">health_</span><span class="p">;</span> <span class="c1">// Starting health.</span>
<span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">attack_</span><span class="p">;</span>
<span class="p">};</span>
</pre></div>
<p>When we construct a breed, we give it a parent that it inherits from. We can
pass in <code>NULL</code> for a base breed that has no ancestors.</p>
<p>To make this useful, a child breed needs to control which attributes are
inherited from its parent and which attributes it overrides and specifies itself. For our
example system, we’ll say that a breed overrides the monster’s health by having
a non-zero value and overrides the attack by having a non-<code>NULL</code> string.
Otherwise, the attribute will be inherited from its parent.</p>
<p>There are two ways we can implement this. One is to handle the delegation
dynamically every time the attribute is requested, like this:</p>
<div class="codehilite"><pre><span class="kt">int</span> <span class="n">Breed</span><span class="o">::</span><span class="n">getHealth</span><span class="p">()</span>
<span class="p">{</span>
<span class="c1">// Override.</span>
<span class="k">if</span> <span class="p">(</span><span class="n">health_</span> <span class="o">!=</span> <span class="mi">0</span> <span class="o">||</span> <span class="n">parent_</span> <span class="o">==</span> <span class="nb">NULL</span><span class="p">)</span> <span class="k">return</span> <span class="n">health_</span><span class="p">;</span>
<span class="c1">// Inherit.</span>
<span class="k">return</span> <span class="n">parent_</span><span class="o">-></span><span class="n">getHealth</span><span class="p">();</span>
<span class="p">}</span>
<span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">Breed</span><span class="o">::</span><span class="n">getAttack</span><span class="p">()</span>
<span class="p">{</span>
<span class="c1">// Override.</span>
<span class="k">if</span> <span class="p">(</span><span class="n">attack_</span> <span class="o">!=</span> <span class="nb">NULL</span> <span class="o">||</span> <span class="n">parent_</span> <span class="o">==</span> <span class="nb">NULL</span><span class="p">)</span> <span class="k">return</span> <span class="n">attack_</span><span class="p">;</span>
<span class="c1">// Inherit.</span>
<span class="k">return</span> <span class="n">parent_</span><span class="o">-></span><span class="n">getAttack</span><span class="p">();</span>
<span class="p">}</span>
</pre></div>
<p>This has the advantage of doing the right thing if a breed is modified at
runtime to no longer override, or no longer inherit some attribute. On the other
hand, it takes a bit more memory (it has to retain a pointer to its parent), and
it’s slower. It has to walk the inheritance chain each time you look up an
attribute.</p>
<p>If we can rely on a breed’s attributes not changing, a faster solution is to
apply the inheritance at <em>construction time</em>. This is called “copy-down”
delegation because we <em>copy</em> inherited attributes <em>down</em> into the derived type
when it’s created. It looks like this:</p>
<div class="codehilite"><pre><span class="n">Breed</span><span class="p">(</span><span class="n">Breed</span><span class="o">*</span> <span class="n">parent</span><span class="p">,</span> <span class="kt">int</span> <span class="n">health</span><span class="p">,</span> <span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">attack</span><span class="p">)</span>
<span class="o">:</span> <span class="n">health_</span><span class="p">(</span><span class="n">health</span><span class="p">),</span>
<span class="n">attack_</span><span class="p">(</span><span class="n">attack</span><span class="p">)</span>
<span class="p">{</span>
<span class="c1">// Inherit non-overridden attributes.</span>
<span class="k">if</span> <span class="p">(</span><span class="n">parent</span> <span class="o">!=</span> <span class="nb">NULL</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">health</span> <span class="o">==</span> <span class="mi">0</span><span class="p">)</span> <span class="n">health_</span> <span class="o">=</span> <span class="n">parent</span><span class="o">-></span><span class="n">getHealth</span><span class="p">();</span>
<span class="k">if</span> <span class="p">(</span><span class="n">attack</span> <span class="o">==</span> <span class="nb">NULL</span><span class="p">)</span> <span class="n">attack_</span> <span class="o">=</span> <span class="n">parent</span><span class="o">-></span><span class="n">getAttack</span><span class="p">();</span>
<span class="p">}</span>
<span class="p">}</span>
</pre></div>
<p>Note that we no longer need a field for the parent breed. Once the constructor
is done, we can forget the parent since we’ve already copied all of its
attributes in. To access a breed’s attribute, now we just return the field:</p>
<div class="codehilite"><pre><span class="kt">int</span> <span class="nf">getHealth</span><span class="p">()</span> <span class="p">{</span> <span class="k">return</span> <span class="n">health_</span><span class="p">;</span> <span class="p">}</span>
<span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="nf">getAttack</span><span class="p">()</span> <span class="p">{</span> <span class="k">return</span> <span class="n">attack_</span><span class="p">;</span> <span class="p">}</span>
</pre></div>
<p>Nice and fast!</p>
<p>Let’s say our game engine is set up to create the breeds by loading a JSON file
that defines them. It could look like:</p>
<div class="codehilite"><pre><span class="p">{</span>
<span class="nt">"Troll"</span><span class="p">:</span> <span class="p">{</span>
<span class="nt">"health"</span><span class="p">:</span> <span class="mi">25</span><span class="p">,</span>
<span class="nt">"attack"</span><span class="p">:</span> <span class="s2">"The troll hits you!"</span>
<span class="p">},</span>
<span class="nt">"Troll Archer"</span><span class="p">:</span> <span class="p">{</span>
<span class="nt">"parent"</span><span class="p">:</span> <span class="s2">"Troll"</span><span class="p">,</span>
<span class="nt">"health"</span><span class="p">:</span> <span class="mi">0</span><span class="p">,</span>
<span class="nt">"attack"</span><span class="p">:</span> <span class="s2">"The troll archer fires an arrow!"</span>
<span class="p">},</span>
<span class="nt">"Troll Wizard"</span><span class="p">:</span> <span class="p">{</span>
<span class="nt">"parent"</span><span class="p">:</span> <span class="s2">"Troll"</span><span class="p">,</span>
<span class="nt">"health"</span><span class="p">:</span> <span class="mi">0</span><span class="p">,</span>
<span class="nt">"attack"</span><span class="p">:</span> <span class="s2">"The troll wizard casts a spell on you!"</span>
<span class="p">}</span>
<span class="p">}</span>
</pre></div>
<p>We’d have a chunk of code that reads each breed entry and instantiates a new
breed instance with its data. As you can see from the <code>"parent": "Troll"</code>
fields, the <code>Troll Archer</code> and <code>Troll Wizard</code> breeds inherit from the base
<code>Troll</code> breed.</p>
<p>Since both of them have zero for their health, they’ll inherit it from the base
<code>Troll</code> breed instead. This means now our designer can tune the health in
<code>Troll</code> and all three breeds will be updated. As the number of breeds and the
number of different attributes each breed has increase, this can be a big
time-saver. Now, with a pretty small chunk of code, we have an open-ended system
that puts control in our designers’ hands and makes the best use of their time.
Meanwhile, we can get back to coding other features.</p>
<h2><a href="#design-decisions" name="design-decisions">Design Decisions</a></h2>
<p>The Type Object pattern lets us build a type system as if we were designing our
own programming language. The design space is wide open, and we can do all sorts
of interesting stuff.</p>
<p>In practice, a few things curtail our fancy. Time and maintainability will
discourage us from anything particularly complicated. More importantly, whatever
type object system we design, our users (often non-programmers) will need to be
able to easily understand it. The simpler we can make it, the more usable it
will be. So what we’ll cover here is the well-trodden design space, and we’ll
leave the far reaches for the academics and explorers.</p>
<h3><a href="#is-the-type-object-encapsulated-or-exposed" name="is-the-type-object-encapsulated-or-exposed">Is the type object encapsulated or exposed?</a></h3>
<p>In our sample implementation, <code>Monster</code> has a reference to a breed, but it
doesn’t publicly expose it. Outside code can’t get directly at the monster’s
breed. From the codebase’s perspective, monsters are essentially typeless, and
the fact that they have breeds is an implementation detail.</p>
<p>We can easily change this and allow <code>Monster</code> to return its <code>Breed</code>:</p>
<p><span name="null"></span></p>
<div class="codehilite"><pre><span class="k">class</span> <span class="nc">Monster</span>
<span class="p">{</span>
<span class="nl">public:</span>
<span class="n">Breed</span><span class="o">&</span> <span class="n">getBreed</span><span class="p">()</span> <span class="p">{</span> <span class="k">return</span> <span class="n">breed_</span><span class="p">;</span> <span class="p">}</span>
<span class="c1">// Existing code...</span>
<span class="p">};</span>
</pre></div>
<aside name="null">
<p>As in other examples in this book, we’re following a convention where we return
objects by reference instead of pointer to indicate to users that <code>NULL</code> will
never be returned.</p>
</aside>
<p>Doing this changes the design of <code>Monster</code>. The fact that all monsters have
breeds is now a publicly visible part of its API. There are benefits with either
choice.</p>
<ul>
<li>
<p><strong>If the type object is encapsulated:</strong></p>
<ul>
<li>
<p><em>The complexity of the Type Object pattern is hidden from the rest of
the codebase.</em> It becomes an implementation detail that only the typed
object has to worry about.</p>
</li>
<li>
<p><em>The typed object can selectively override behavior from the type
object</em>. Let’s say we wanted to change the monster’s attack string when
it’s near death. Since the attack string is always accessed through
<code>Monster</code>, we have a convenient place to put that code:</p>
<div class="codehilite"><pre><span class="k">const</span> <span class="kt">char</span><span class="o">*</span> <span class="n">Monster</span><span class="o">::</span><span class="n">getAttack</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">health_</span> <span class="o"><</span> <span class="n">LOW_HEALTH</span><span class="p">)</span>
<span class="p">{</span>
<span class="k">return</span> <span class="s">"The monster flails weakly."</span><span class="p">;</span>
<span class="p">}</span>
<span class="k">return</span> <span class="n">breed_</span><span class="p">.</span><span class="n">getAttack</span><span class="p">();</span>
<span class="p">}</span>
</pre></div>
<p>If outside code was calling <code>getAttack()</code> directly on the breed, we
wouldn’t have the opportunity to insert that logic.</p>
</li>
<li>
<p><em>We have to write forwarding methods for everything the type object
exposes.</em> This is the tedious part of this design. If our type object
class has a large number of methods, the object class will have to have
its own methods for each of the ones that we want to be publicly
visible.</p>
</li>
</ul>
</li>
<li>
<p><strong>If the type object is exposed:</strong></p>
<ul>
<li>
<p><em>Outside code can interact with type objects without having an instance
of the typed class.</em> If the type object is encapsulated, there’s no way
to use it without also having a typed object that wraps it. This
prevents us, for example, from using our constructor pattern where new
monsters are created by calling a method on the breed. If users can’t
get to breeds directly, they wouldn’t be able to call it.</p>
</li>
<li>
<p><em>The type object is now part of the object’s public API.</em> In general,
narrow interfaces are easier to maintain than wide ones — the less you
expose to the rest of the codebase, the less complexity and maintenance
you have to deal with. By exposing the type object, we widen the
object’s API to include everything the type object provides.</p>
</li>
</ul>
</li>
</ul>
<h3><a href="#how-are-typed-objects-created" name="how-are-typed-objects-created">How are typed objects created?</a></h3>
<p>With this pattern, each “object” is now a pair of objects: the main object and
the type object it uses. So how do we create and bind the two together?</p>
<ul>
<li>
<p><strong>Construct the object and pass in its type object:</strong></p>
<ul>
<li><em>Outside code can control allocation.</em> Since the calling code is
constructing both objects itself, it can control where in memory that
occurs. If we want our objects to be usable in a variety of different
memory scenarios (different allocators, on the stack, etc.) this gives
us the flexibility to do that.</li>
</ul>
</li>
<li>
<p><strong>Call a “constructor” function on the type object:</strong></p>
<ul>
<li><em>The type object controls memory allocation.</em> This is the other side of
the coin. If we <em>don’t</em> want users to choose where in memory our objects
are created, requiring them to go through a factory method on the type
object gives us control over that. This can be useful if we want to
ensure all of our objects come from a certain <a class="pattern"
href="object-pool.html">Object Pool</a> or other memory allocator.</li>
</ul>
</li>
</ul>
<h3><a href="#can-the-type-change" name="can-the-type-change">Can the type change?</a></h3>
<p>So far, we’ve presumed that once an object is created and bound to its type
object that that binding will never change. The type an object is created with
is the type it dies with. This isn’t strictly necessary. We <em>could</em> allow an
object to change its type over time.</p>
<p>Let’s look back at our example. When a monster dies, the designers tell us
sometimes they want its corpse to become a reanimated zombie. We could implement
this by spawning a new monster with a zombie breed when a monster dies, but
another option is to simply get the existing monster and change its breed to a
zombie one.</p>
<ul>
<li>
<p><strong>If the type doesn’t change:</strong></p>
<ul>
<li>
<p><em>It’s simpler both to code and to understand.</em> At a conceptual level,
“type” is something most people probably will not expect to change. This
codifies that assumption.</p>
</li>
<li>
<p><em>It’s easier to debug.</em> If we’re trying to track down a bug where a
monster gets into some weird state, it simplifies our job if we can take
for granted that the breed we’re looking at <em>now</em> is the breed the
monster has always had.</p>
</li>
</ul>
</li>
<li>
<p><strong>If the type can change:</strong></p>
<ul>
<li>
<p><em>There’s less object creation.</em> In our example, if the type can’t
change, we’ll be forced to burn CPU cycles creating a new zombie
monster, copying over any attributes from the original monster that need
to be preserved, and then deleting it. If we can change the type,
all that work gets replaced by a simple assignment.</p>
</li>
<li>
<p><em>We need to be careful that assumptions are met.</em> There’s a fairly tight
coupling between an object and its type. For example, a breed might
assume that a monster’s <em>current</em> health is never above the starting
health that comes from the breed.</p>
<p>If we allow the breed to change, we need to make sure that the new
type’s requirements are met by the existing object. When we change the
type, we will probably need to execute some validation code to make sure
the object is now in a state that makes sense for the new type.</p>
</li>
</ul>
</li>
</ul>
<h3><a href="#what-kind-of-inheritance-is-supported" name="what-kind-of-inheritance-is-supported">What kind of inheritance is supported?</a></h3>
<ul>
<li>
<p><strong>No inheritance:</strong></p>
<ul>
<li>
<p><em>It’s simple.</em> Simplest is often best. If you don’t have a ton of data
that needs sharing between your type objects, why make things hard on
yourself?</p>
</li>
<li>
<p><em>It can lead to duplicated effort.</em> I’ve yet to see an authoring system
where designers <em>didn’t</em> want some kind of inheritance. When you’ve got
fifty different kinds of elves, having to tune their health by changing
the same number in fifty different places <em>sucks</em>.</p>
</li>
</ul>
</li>
<li>
<p><strong>Single inheritance:</strong></p>
<ul>
<li>
<p><em>It’s still relatively simple.</em> It’s easy to implement, but, more
importantly, it’s also pretty easy to understand. If non-technical users
are going to be working with the system, the fewer moving parts, the
better. There’s a reason a lot of programming languages only support
single inheritance. It seems to be a sweet spot between power and
simplicity.</p>
</li>
<li>
<p><em>Looking up attributes is slower.</em> To get a given piece of data from a
type object, we might need to walk up the inheritance chain to find
the type that ultimately decides the value. If we’re in
performance-critical code, we may not want to spend time on this.</p>
</li>
</ul>
</li>
<li>
<p><strong>Multiple inheritance:</strong></p>
<ul>
<li>
<p><em>Almost all data duplication can be avoided.</em> With a good multiple
inheritance system, users can build a hierarchy for their type objects
that has almost no redundancy. When it comes time to tune numbers, we
can avoid a lot of copy and paste.</p>
</li>
<li>
<p><em>It’s complex.</em> Unfortunately, the benefits for this seem to be more
theoretical than practical. Multiple inheritance is hard to understand
and reason about.</p>
<p>If our Zombie Dragon type inherits both from Zombie and Dragon, which
attributes come from Zombie and which come from Dragon? In order to use
the system, users will need to understand how the inheritance graph is
traversed and have the foresight to design an intelligent hierarchy.</p>
<p>Most C++ coding standards I see today tend to ban multiple inheritance,
and Java and C# lack it completely. That’s an acknowledgement of a sad
fact: it’s so hard to get it right that it’s often best to not use it at
all. While it’s worth thinking about, it’s rare that you’ll want to use
multiple inheritance for the type objects in your games. As always,
simpler is better.</p>
</li>
</ul>
</li>
</ul>
<h2><a href="#see-also" name="see-also">See Also</a></h2>
<ul>
<li>
<p>The high-level problem this pattern addresses is sharing data and behavior
between several objects. Another pattern that addresses the same problem in
a different way is <a class="gof-pattern"
href="prototype.html">Prototype</a>.</p>
</li>
<li>
<p>Type Object is a close cousin to <a class="gof-pattern"
href="flyweight.html">Flyweight</a>. Both let you share data across
instances. With Flyweight, the intent is on saving memory, and the shared
data may not represent any conceptual “type” of object. With the Type Object
pattern, the focus is on organization and flexibility.</p>
</li>
<li>
<p>There’s a lot of similarity between this pattern and the <a
class="gof-pattern" href="state.html">State</a> pattern. Both patterns let
an object delegate part of what defines itself to another object. With a
type object, we’re usually delegating what the object <em>is</em>: invariant data
that broadly describes the object. With State, we delegate what an object
<em>is right now</em>: temporal data that describes an object’s current
configuration.</p>
<p>When we discussed having an object change its type, you can look at that as
having our Type Object serve double duty as a State too.</p>
</li>
</ul>
<nav>
<span class="prev">← <a href="subclass-sandbox.html">Previous Chapter</a></span>
<span class="next"><a href="decoupling-patterns.html">Next Chapter</a> →</span>
<span class="toc">≡ <a href="/">The Book</a></span>
</nav>
</div>
</div>
<footer>© 2009-2014 Robert Nystrom</footer>
</body>
</html>