Design Patterns

More documents

Recommendations

Info

194 CHAPTER 13 ■ THE FLYWEIGHT PATTERN It doesn’t require huge changes to your code to get these savings. Once you have created the manager, the factory, and the flyweight, the only change you must make to your code is to call a method of the manager object instead of instantiating the class directly. If you are creating the flyweight for other programmers to use as an API, they need only slightly alter the way they call it to get the benefits. This is where the pattern really shines; if you make this optimization to your API once, it will be much more efficient for everyone else who uses it. When using this optimization for a library that is used over an entire site, your users may well notice a huge improvement in speed. Drawbacks of the Flyweight Pattern This is only an optimization pattern. It does nothing other than improve the efficiency of your code under a strict set of conditions. It can’t, and shouldn’t, be used everywhere; it can actually make your code less efficient if used unnecessarily. In order to optimize your code, this pattern adds complexity, which makes it harder to debug and maintain. It’s harder to debug because there are now three places where an error could occur: the manager, the factory, and the flyweight. Before, there was only a single object to worry about. It is also very tricky to track down data problems because it isn’t always clear where a particular piece of data is coming from. If a tooltip is displaying the wrong text, is that because the wrong text was passed in, or because it is a shared resource and it forgot to clear out the text from its last use? These types of errors can be costly. Maintenance can also be more difficult because of this optimization. Instead of having a clean architecture of objects encapsulating data, you now have a fragmented mess with data being stored in at least two places. It is important to document why a particular piece of data is intrinsic or extrinsic, as such a distinction may be lost on those who maintain your code after you. These drawbacks are not deal breakers; they simply mean that this optimization should only be done when needed. Trade-offs must always be made between run-time efficiency and maintainability, but such trade-offs are the essence of engineering. In this case, if you are unsure whether a flyweight is needed, it probably isn’t. The flyweight pattern is for situations where system resources are almost entirely utilized, and where it is obvious that some sort of optimization must be done. It is then that the benefits outweigh the costs. Summary In this chapter we discussed the structure, usage, and benefits of the flyweight pattern. It is solely an optimization pattern, used to improve performance and make your code more efficient, especially in its use of memory. It is implemented by taking an existing class and stripping it of all data that can be stored externally. Each unique instance of this class then becomes a resource shared among many locations. A single flyweight object takes the place of many of the original objects. For the flyweight object to be shared like this, several new objects must be added. A factory object is needed to control how the class gets instantiated and to limit the number of instances created to the absolute minimum. It should also store previously created instances, to reuse them if a similar object is needed later. A manager object is needed to store the extrinsic data and pass it in to the flyweight’s methods. In this manner, the original function of the class can be preserved while greatly reducing the number of copies needed.
CHAPTER 13 ■ THE FLYWEIGHT PATTERN 195 When used properly, the flyweight pattern can improve performance and reduce needed resources significantly. When used improperly, however, it can make your code more complicated, harder to debug, and harder to maintain, with few performance benefits to make up for it. Before using this pattern, ensure that your program meets the required conditions and that the performance gains will outweigh the code complexity costs. This pattern is especially useful to JavaScript programmers because it can be used to reduce the number of memory-intensive DOM elements that you need to manipulate on a page. By using it in conjunction with organizational patterns, such as composites, it is possible to create complex, full-featured web applications that still run smoothly in any modern JavaScript environment.
Page 1:
The EXPERT’s VOIce ® in Web Deve
Page 4 and 5:
Pro JavaScript Design Patterns Cop
Page 7:
Contents at a Glance About the Auth
Page 10 and 11:
viii ■CONTENTS ■CHAPTER 3 Encap
Page 12 and 13:
x ■CONTENTS ■CHAPTER 8 The Brid
Page 14 and 15:
xii ■CONTENTS Example: Tooltip Ob
Page 17:
About the Authors ■ROSS HARMES is
Page 21:
Acknowledgments Thanks to our intre
Page 24 and 25:
xxii ■INTRODUCTION them. This typ
Page 26 and 27:
xxiv ■INTRODUCTION behaviors on m
Page 28 and 29:
xxvi ■INTRODUCTION • extend(sub
Page 31 and 32:
CHAPTER 1 ■ ■ ■ Expressive Ja
Page 33 and 34:
CHAPTER 1 ■ EXPRESSIVE JAVASCRIPT
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
CHAPTER 2 ■ ■ ■ Interfaces Th
Page 41 and 42:
CHAPTER 2 ■ INTERFACES 13 Java us
Page 43 and 44:
CHAPTER 2 ■ INTERFACES 15 /* inte
Page 45 and 46:
CHAPTER 2 ■ INTERFACES 17 } if(!i
Page 47 and 48:
CHAPTER 2 ■ INTERFACES 19 The Int
Page 49 and 50:
CHAPTER 2 ■ INTERFACES 21 1. Incl
Page 51:
CHAPTER 2 ■ INTERFACES 23 Pattern
Page 54 and 55:
26 CHAPTER 3 ■ ENCAPSULATION AND
Page 56 and 57:
Page 58 and 59:
Page 60 and 61:
Page 62 and 63:
Page 64 and 65:
Page 66 and 67:
Page 68 and 69:
Page 70 and 71:
42 CHAPTER 4 ■ INHERITANCE Classi
Page 72 and 73:
44 CHAPTER 4 ■ INHERITANCE having
Page 74 and 75:
46 CHAPTER 4 ■ INHERITANCE Instea
Page 76 and 77:
48 CHAPTER 4 ■ INHERITANCE var co
Page 78 and 79:
50 CHAPTER 4 ■ INHERITANCE It is
Page 80 and 81:
52 CHAPTER 4 ■ INHERITANCE Exampl
Page 82 and 83:
54 CHAPTER 4 ■ INHERITANCE To cre
Page 84 and 85:
56 CHAPTER 4 ■ INHERITANCE this.s
Page 86 and 87:
58 CHAPTER 4 ■ INHERITANCE this.f
Page 88 and 89:
Page 90 and 91:
Page 93 and 94:
CHAPTER 5 ■ ■ ■ The Singleton
Page 95 and 96:
CHAPTER 5 ■ THE SINGLETON PATTERN
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
CHAPTER 6 ■ ■ ■ Chaining In t
Page 113 and 114:
CHAPTER 6 ■ CHAINING 85 Since all
Page 115 and 116:
CHAPTER 6 ■ CHAINING 87 (function
Page 117 and 118:
CHAPTER 6 ■ CHAINING 89 Using Cal
Page 119:
PART 2 ■ ■ ■ Design Patterns
Page 122 and 123:
94 CHAPTER 7 ■ THE FACTORY PATTER
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
100 CHAPTER 7 ■ THE FACTORY PATTE
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
110 CHAPTER 8 ■ THE BRIDGE PATTER
Page 140 and 141:
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
Page 150 and 151:
Page 153 and 154:
CHAPTER 9 ■ ■ ■ The Composite
Page 155 and 156:
CHAPTER 9 ■ THE COMPOSITE PATTERN
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
CHAPTER 10 ■ ■ ■ The Facade P
Page 171 and 172: CHAPTER 10 ■ THE FACADE PATTERN 1
Page 177 and 178: CHAPTER 11 ■ ■ ■ The Adapter
Page 179 and 180: CHAPTER 11 ■ THE ADAPTER PATTERN
Page 181 and 182: asyncRequest: function() { function
Page 187 and 188: CHAPTER 12 ■ ■ ■ The Decorato
Page 189 and 190: CHAPTER 12 ■ THE DECORATOR PATTER
Page 205: CHAPTER 12 ■ THE DECORATOR PATTER
Page 208 and 209: 180 CHAPTER 13 ■ THE FLYWEIGHT PA
Page 225 and 226: CHAPTER 14 ■ ■ ■ The Proxy Pa
Page 227 and 228: CHAPTER 14 ■ THE PROXY PATTERN 19
Page 243 and 244: CHAPTER 15 ■ ■ ■ The Observer
Page 245 and 246: CHAPTER 15 ■ THE OBSERVER PATTERN
Page 251: CHAPTER 15 ■ THE OBSERVER PATTERN
Page 254 and 255: 226 CHAPTER 16 ■ THE COMMAND PATT
Page 272 and 273:
244 CHAPTER 16 ■ THE COMMAND PATT
Page 274 and 275:
246 CHAPTER 17 ■ THE CHAIN OF RES
Page 276 and 277:
Page 278 and 279:
Page 280 and 281:
Page 282 and 283:
Page 284 and 285:
Page 286 and 287:
Page 288 and 289:
Page 290 and 291:
Page 292 and 293:
264 ■INDEX classical inheritance,
Page 294 and 295:
266 ■INDEX as objects, 6-8, 37 pr
Page 296 and 297:
268 ■INDEX performance issues, 12
Page 298:
Offer valid through 06/08.
show all

Design Patterns

Create successful ePaper yourself

Delete template?

Save as template?