Skip to content
This repository

bug fix for Safari #15

wants to merge 3 commits into from

2 participants

Art Pai Addy Osmani
Art Pai

removed all empty p tag, this will make SyntaxHighlighter work on Safari, both Mac and iPad.

Addy Osmani addyosmani closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Showing 3 unique commits by 1 author.

Mar 04, 2012
Art Pai minipai make SyntaxHighlighter work on Safari
removed all <p>&nbsp;</p>,  this will make SyntaxHighlighter work on
Safari, both Mac and iPad.
Art Pai minipai change tags in head to modern html5 style e5a659d
Art Pai minipai Merge branch 'master' of… 63adc09
This page is out of date. Refresh to see the latest.

Showing 1 changed file with 126 additions and 126 deletions. Show diff stats Hide diff stats

  1. +126 126 book/index.html
252 book/index.html
... ... @@ -1,11 +1,11 @@
2 2 <html>
3 3 <head>
4   -<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  4 +<meta charset="utf-8">
5 5 <title>Essential JavaScript Design Patterns For Beginners</title>
6   -<link href="css/style.css" rel="stylesheet" type="text/css">
7   -<link rel="stylesheet" type="text/css" href="css/shCore.css">
8   -<link rel="stylesheet" type="text/css" href="css/shThemeRDark.css">
  6 +<link rel="stylesheet" href="css/style.css">
  7 +<link rel="stylesheet" href="css/shCore.css">
  8 +<link rel="stylesheet" href="css/shThemeRDark.css">
9 9 </head>
10 10
11 11 <body>
@@ -17,7 +17,7 @@ <h2 class="booktitle">Volume 1.5</h2>
17 17 <p class="booktitle"><a href="" class="twitter-share-button" data-url="" data-count="horizontal" data-via="addyosmani">Tweet</a><script type="text/javascript" src=""></script></p>
18 18 <p class="bookauthor">A book by <a href="">Addy Osmani</a></p>
19 19
20   - <p>&nbsp;</p>
  20 +
21 21 <p class="copyright">
22 22 Copyright © Addy Osmani. Last edited: February 19th, 2012.
23 23 </p>
@@ -30,7 +30,7 @@ <h2 class="booktitle">Volume 1.5</h2>
30 30 <p>Before we get started, I would like to thank <a href="">Rebecca Murphey</a> for inspiring me to write the original version of this online book and more importantly, open-source it. I believe educational material should be freely available for anyone to use, access and improve where possible and hope that efforts such as this inspire other authors. I would also like to extend my thanks to the always brilliant <a href="">Alex Sexton</a> who was kind enough to be the technical reviewer for the first edition of this work.</p>
31 31 <p>Finally, I would like to thank my wonderful wife Elle for putting up with my obsession for technical writing over the years. My hope is that I haven't abused the English language too badly.</p>
32 32
33   - <p>&nbsp;</p>
  33 +
34 34 <h1><em>Contents</em></h1>
35 35 <div id="contents-list">
36 36 <ul>
@@ -98,8 +98,8 @@ <h1 id="introduction"><strong>Introduction</strong></h1>
98 98 <p>One of the first and arguably most iconic formal works published on design patterns in software engineering was a book in 1995 called <em>'Design Patterns: Elements Of Reusable Object-Oriented Software</em>'. This was written by <a href="">Erich Gamma</a>,<a href=""> Richard Helm</a>,<a href=""> Ralph Johnson</a> and<a href=""> John Vlissides</a> - a group that became known as the Gang of Four (or GoF for short). </p>
99 99 <p>The GoF's publication is considered quite instrumental to pushing the concept of design patterns further in our field as it describes a number of development techniques and pitfalls as well as providing twenty-three core Object-Oriented design patterns frequently used around the world today. We will be covering these patterns in more detail in the section &lsquo;Categories of Design Patterns&rsquo;.</p>
100 100 <p>In this book, we will take a look at a number of popular JavaScript design patterns and explore why certain patterns may be more suitable for your projects than others. Remember that patterns can be applied not just to vanilla JavaScript, but also to abstracted libraries such as jQuery or Dojo as well. Before we begin, let&rsquo;s look at the exact definition of a &lsquo;pattern&rsquo; in software design.</p>
101   - <p>&nbsp;</p>
102   - <p>&nbsp;</p>
  101 +
  102 +
103 103 <h1 id="whatisapattern">What is a Pattern?</h1>
104 104 <p>A pattern is a reusable solution that can be applied to commonly occurring problems in software design - in our case - in writing JavaScript applications. Another way of looking at patterns are as templates for how you solve problems - ones which can be used in quite a few different situations.</p>
105 105 <p>To consider how useful a pattern may be, let us consider that if you were to write a script where you said &lsquo;for each item, sound an alert&rsquo;, if sounding an alert was complex in nature, it would always result in more maintainable code doing the above over saying &lsquo;do this for item 1&rsquo;, &lsquo;do this for item 2&rsquo;, &lsquo;do the same again for item 3&rsquo;, i.e. If the code performing the bulk of the work exists in fewer places it becomes significantly easier to maintain. </p>
@@ -113,7 +113,7 @@ <h1 id="whatisapattern">What is a Pattern?</h1>
113 113 </ol>
114 114 </ol>
115 115 </ol>
116   - <p>&nbsp;</p>
  116 +
117 117 <p>Patterns are <strong>not</strong> an exact solution. It&rsquo;s important that we remember the role of a pattern is merely to provide us with a solution scheme. Patterns don&rsquo;t solve all design problems nor do they replace good software designers, however, they <strong>do</strong> support them. Next we&rsquo;ll take a look at some of the other advantages patterns can offer us. </p>
118 118 <ul>
119 119 <li><strong>Reusing patterns assists in preventing minor issues that can cause major problems in the application development process. </strong>What this means is that when your code relies more on proven patterns, you can afford to spend less time worrying about your code architecture and more time focusing on the quality of your overall solution. This is because patterns can encourage you to code in a more structured and organized fashion so the need to refactor it for cleanliness purposes in the future can be significantly decreased.</li>
@@ -123,8 +123,8 @@ <h1 id="whatisapattern">What is a Pattern?</h1>
123 123 <li><strong>Certain patterns can actually decrease the overall file-size footprint of your code by avoiding repetition. </strong>By encouraging developers to look more closely at their solutions for areas where instant reductions in <span id="internal-source-marker_0.982673292361492">repetition</span> can be made, e.g. reducing the number of functions performing similar processes in favor of a single generalized function, the overall size of your codebase can be decreased. </li>
124 124 <li><strong>Patterns that are frequently </strong>used can be improved over time by harnessing the collective experiences other developers using those patterns contribute back to the design pattern community. In some cases this leads to the creation of entirely new design patterns whilst in others it can lead to the provision of improved guidelines on how specific patterns can be best used. This can ensure that pattern-based solutions continue to become more robust than ad-hoc solutions may be.</li>
125 125 </ul>
126   -<p>&nbsp;</p>
127   -<p>&nbsp;</p>
  126 +
  127 +
128 128 <h1 id="patternity">'Pattern'-ity Testing, Proto-Patterns &amp; The Rule Of Three</h1>
129 129 <p>
130 130 Remember that not every algorithm, best practice or solution represents what might be considered a complete pattern. There may be a few key ingredients here that are missing and the pattern community is generally weary of something claiming to be one unless it has been heavily vetted. Even if something is presented to us which *appears* to meet the criteria for a pattern, it should not be considered one until it has undergone suitable periods of scrutiny and testing by others.<br>
@@ -136,7 +136,7 @@ <h1 id="patternity">'Pattern'-ity Testing, Proto-Patterns &amp; The Rule Of Thre
136 136 Alternatively, the individual(s) sharing the pattern may not have the time or interest of going through the &lsquo;pattern&rsquo;-ity process and might release a short description of their proto-pattern instead. Brief descriptions of this type of pattern are known as patlets.<br>
137 137 <br>
138 138 The work involved in fully documenting a qualified pattern can be quite daunting. Looking back at some of the earliest work in the field of design patterns, a pattern may be considered &lsquo;good&rsquo; if it does the following: </p>
139   -<p>&nbsp;</p>
  139 +
140 140 <ul type="disc">
141 141 <li><strong>Solves a particular problem</strong> - patterns are not supposed to just capture principles or strategies. They need to capture solutions. This is one of the most essential ingredients for a good pattern.</li>
142 142 <li><strong>The solution to this problem cannot be obvious </strong>- you can often find that problem-solving techniques attempt to derive from well-known first principles. The best design patterns usually provide solutions to problems indirectly - this is considered a necessary approach for the most challenging problems related to design.</li>
@@ -148,19 +148,19 @@ <h1 id="patternity">'Pattern'-ity Testing, Proto-Patterns &amp; The Rule Of Thre
148 148 You wouldn&rsquo;t be blamed for thinking that a proto-pattern that doesn&rsquo;t meet the guidelines for a complete pattern isn&rsquo;t worth investigating, but this is far from the truth. Many proto-patterns are actually quite good. I&rsquo;m not saying that all proto-patterns are worth looking at, but there are quite a few useful ones in the wild that could assist you with future projects. Use best judgment with the above list in mind and you&rsquo;ll be fine in your selection process. <br>
149 149 <br>
150 150 One of the additional requirements for a pattern to be valid is that they display some recurring phenomenon. This is often something that can be qualified in at least three key areas, referred to as the <em>rule of three</em>. To show recurrence using this rule, one must demonstrate: </p>
151   -<p>&nbsp;</p>
  151 +
152 152 <ol start="1" type="1">
153 153 <li><strong>Fitness of purpose</strong> - how is the pattern considered successful?</li>
154 154 <li><strong>Usefulness </strong>- why is the pattern considered successful?</li>
155 155 <li><strong>Applicability</strong> - is the design worthy of being a pattern because it has wider applicability? If so, this needs to be explained.When reviewing or defining a pattern, it is important to keep the above in mind.</li>
156 156 </ol>
157   -<p>&nbsp;</p>
158   -<p>&nbsp;</p>
  157 +
  158 +
159 159 <h1 id="designpatternstructure">The Structure Of A Design Pattern</h1>
160 160 <p>When studying design patterns, you may wonder what teams that create them have to put in their design pattern descriptions.&nbsp; Every pattern has to initially be formulated in a form of a <strong>rule</strong> that establishes a relationship between a <strong>context</strong>, a system of <strong>forces</strong> that arises in that context and a <strong>configuration</strong> that allows these forces to resolve themselves in context.&nbsp; </p>
161   -<p>&nbsp;</p>
  161 +
162 162 <p>I find that a lot of the information available out there about the structure of a good pattern can be condensed down to something more easily digestible.With this in mind, lets now take a look at a summary of the component elements for a design pattern.</p>
163   -<p>&nbsp;</p>
  163 +
164 164 <p><strong>A design pattern must have a:</strong></p>
165 165 <ul>
166 166 <li><strong>Pattern Name</strong> and a <strong>description </strong></li>
@@ -176,10 +176,10 @@ <h1 id="designpatternstructure">The Structure Of A Design Pattern</h1>
176 176 <li><strong>Known usage</strong> – is the pattern being used in the &lsquo;wild&rsquo;?. If so, where and how? </li>
177 177 <li><strong>Discussions</strong> – the team or author&rsquo;s thoughts on the exciting benefits of the pattern </li>
178 178 </ul>
179   -<p>&nbsp;</p>
  179 +
180 180 <p>Design patterns are quite a powerful approach to getting all of the developers in an organization or team on the same page when creating or maintaining solutions. If you or your company ever consider working on your own pattern, remember that although they may have a heavy initial cost in the planning and write-up phases, the value returned from that investment can be quite worth it. Always research thoroughly before working on new patterns however, as you may find it more beneficial to use or build on top of existing proven patterns than starting afresh.</p>
181   -<p>&nbsp;</p>
182   -<p>&nbsp;</p>
  181 +
  182 +
183 183 <h1 id="writingdesignpatterns">Writing Design Patterns</h1>
184 184 <p>Although this book is aimed at those new to design patterns, a fundamental understanding of how a design pattern is written can offer you a number of useful benefits. For starters, you can gain a deeper appreciation for the reasoning behind a pattern being needed but can also learn how to tell if a pattern (or proto-pattern) is up to scratch when reviewing it for your own needs.<br>
185 185 <br>
@@ -192,7 +192,7 @@ <h1 id="writingdesignpatterns">Writing Design Patterns</h1>
192 192 Once you&rsquo;ve exposed yourself to a wealth of information on pattern literature, you may wish to begin your pattern using an <em>existing</em> format and see if you can brainstorm new ideas for improving it or integrating your ideas in there. &nbsp;An example of someone that did this quite recently is JavaScript developer Christian Heilmann, who took an existing pattern called the <em>module</em> pattern and made some fundamentally useful changes to it to create the <em>revealing module</em> pattern (this is one of the patterns covered later in this book). <br>
193 193 <br>
194 194 If you would like to try your hand at writing a design pattern (even if just for the learning experience of going through the process), the tips I have for doing so would be as follows:</p>
195   -<p>&nbsp;</p>
  195 +
196 196 <ul type="disc">
197 197 <li><strong>Bear in mind practicability</strong>: Ensure that your pattern describes proven solutions to recurring problems rather than just speculative solutions which haven&rsquo;t been qualified.</li>
198 198 <li><strong>Ensure that you draw upon best practices:</strong> The design decisions you make should be based on principles you derive from an understanding of best practices. </li>
@@ -202,11 +202,11 @@ <h1 id="writingdesignpatterns">Writing Design Patterns</h1>
202 202 <li><strong>Know the differences between patterns and design</strong>: A design pattern generally draws from proven best practice and serves as a model for a designer to create a solution<em>. The role of the pattern is to give designers guidance to make the best design choices so they can cater to the needs of their users.</em></li>
203 203 <li><strong>Your pattern needs to have a strong set of examples:</strong> A good pattern description needs to be followed by an equally strong set of examples demonstrating the successful application of your pattern. To show broad usage, examples that exhibit good design principles are ideal.</li>
204 204 </ul>
205   -<p>&nbsp;</p>
  205 +
206 206 <p><br>
207 207 Pattern writing is a careful balance between creating a design that is general, specific and above all, useful. Try to ensure that if writing a pattern you cover the widest possible areas of application and you should be fine. &nbsp;I hope that this brief introduction to writing patterns has given you some insights that will assist your learning process for the next sections of this book. </p>
208   -<p>&nbsp;</p>
209   -<p>&nbsp;</p>
  208 +
  209 +
210 210 <h1 id="antipatterns">Anti-Patterns</h1>
211 211 <p>If we consider that a pattern represents a best practice, an anti-pattern represents a lesson that has been learned. The term anti-patterns was coined in 1995 by Andrew Koenig in the November C++ Report that year. It was inspired by the Gang of Four's book <em>Design Patterns</em>, that developed the concept of design patterns in the software field. In Koenig&rsquo;s report, there are two notions of anti-patterns that are presented. Anti-Patterns: </p>
212 212 <ul type="disc">
@@ -231,17 +231,17 @@ <h1 id="antipatterns">Anti-Patterns</h1>
231 231 <li>Using JavaScript in an inline form as this is inflexible </li>
232 232 <li>The use of document.write where native DOM alternatives such as document.createElement are more appropriate. document.write has been grossly misused over the years and has quite a few disadvantages including that if it's executed after the page has been loaded it can actually overwrite the page you're on, whilst document.createElement does not. You can see <a href="">here</a> for a live example of this in action. It also doesn't work with XHTML which is another reason opting for more DOM-friendly methods such as document.createElement is favorable.</li>
233 233 </ul>
234   -<p>&nbsp;</p>
  234 +
235 235 <p><br>
236 236 Knowledge of anti-patterns is critical for success. Once you are able to recognize such anti-patterns, you will be able to refactor your code to negate them so that the overall quality of your solutions improves instantly. </p>
237   -<p>&nbsp;</p>
  237 +
238 238 <h1 id="categoriesofdesignpatterns">Categories Of Design Pattern</h1>
239   -<p>&nbsp;</p>
  239 +
240 240 <p>A glossary from the well-known design book, <em>Domain-Driven Terms, </em>rightly states that:</p>
241 241 <h3>&ldquo;A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and their instances, their roles and collaborations, and the distribution of responsibilities. </h3>
242 242 <h3>Each design pattern focuses on a particular object-oriented design problem or issue. It describes when it applies, whether or not it can be applied in view of other design constraints, and the consequences and trade-offs of its use. Since we must eventually implement our designs, a design pattern also provides sample ... code to illustrate an implementation. </h3>
243 243 <h3>Although design patterns describe object-oriented designs, they are based on practical solutions that have been implemented in mainstream object-oriented programming languages ....&rdquo;</h3>
244   -<p>&nbsp;</p>
  244 +
245 245 <p>Design patterns can be broken down into a number of different categories. In this section we&rsquo;ll review three of these categories and briefly mention a few examples of the patterns that fall into these categories before exploring specific ones in more detail.
246 246 </p>
247 247 <h2><br>
@@ -250,20 +250,20 @@ <h1 id="categoriesofdesignpatterns">Categories Of Design Pattern</h1>
250 250 Creational design patterns focus on handling object creation mechanisms where objects are created in a manner suitable for the situation you are working in. The basic approach to object creation might otherwise lead to added complexity in a project whilst creational patterns aim to solve this problem by <em>controlling</em> the creation of such objects.<br>
251 251 <br>
252 252 Some of the patterns that fall under this category are: Factory, Abstract, Prototype, Singleton and Builder.</p>
253   -<p>&nbsp;</p>
  253 +
254 254 <h2>Structural Design Patterns</h2>
255 255 <p><em><br>
256 256 </em>Structural patterns focus on the composition of classes and objects. Structural &lsquo;class&rsquo; creation patterns use inheritance to compose interfaces whilst &lsquo;object&rsquo; patterns define methods to create objects to obtain new functionality. <br>
257 257 <br>
258 258 Patterns that fall under this category include: Decorator, Facade, Composite, Adapter and Bridge</p>
259   -<p>&nbsp;</p>
  259 +
260 260 <h2>Behavioral Design Patterns<br>
261 261 <br>
262 262 </h2>
263 263 <p>The main focus behind this category of patterns is the communication between a class&rsquo;s objects. By specifically targeting this problem, these patterns are able to increase the flexibility in carrying out this communication.<br>
264 264 <br>
265 265 Some behavioral patterns include: Iterator, Mediator, Observer and Visitor.</p>
266   -<p>&nbsp;</p>
  266 +
267 267 <h2>Summary Table Of Design Pattern Categorization</h2>
268 268 <p>In my early experiences of learning about design patterns, I personally found the following table a very useful reminder of what a number of patterns has to offer - it covers the 23 Design Patterns mentioned by the GoF. The original table was summarized by Elyse Nielsen back in 2004
269 269 and I've modified it where necessary to suit our discussion in this section of the book.
@@ -436,16 +436,16 @@ <h1 id="categoriesofdesignpatterns">Categories Of Design Pattern</h1>
436 436 <td colspan="3"> Adds a new operation to a class without changing the class </td>
437 437 </tr>
438 438 </tbody></table></p>
439   -<p>&nbsp;</p>
440   -<p>&nbsp;</p>
  439 +
  440 +
441 441 <h1 id="designpatternsjavascript">An Introduction To Design Patterns</h1>
442   -<p>&nbsp;</p>
  442 +
443 443
444 444 <p>We are now going to explore JavaScript implementations of a number of both classical and modern design patterns. This section of the book will cover an introduction to these patterns, whilst the next section will focus on looking at some specific patterns (such as the Observer) in greater detail.</p>
445 445
446 446 <p>A common question developers regularly ask is what the 'ideal' set of patterns they should be using are. There isn't a singular answer to this question, but with the aid of what you'll learn in this book, you will hopefully be able to use your best judgement to select the right patterns to best suit your project's needs.</p>
447 447
448   -<p>&nbsp;</p>
  448 +
449 449 <p><strong>The patterns we will be exploring in this section are the:</strong></p>
450 450 <ul>
451 451 <li class="subitem"><a href="#creationalpatternjavascript">Creational Pattern</a></li>
@@ -463,7 +463,7 @@ <h1 id="designpatternsjavascript">An Introduction To Design Patterns</h1>
463 463 <li class="subitem"><a href="#mixinpatternjavascript">Mixin Pattern</a>
464 464 <li class="subitem"><a href="#decoratorpatternjavascript">Decorator Pattern</a></li>
465 465 </ul>
466   -<p>&nbsp;</p>
  466 +
467 467 <h2 id="creationalpatternjavascript">The Creational Pattern</h2>
468 468
469 469 <p>The creational pattern is the basis for a number of the other design patterns we'll be looking at in this section and is probably the easiest to understand. As you may guess, the creational pattern deals with the idea of <em>creating</em> new things, specifically new objects. In JavaScript, the common way of creating new objects (collections of name/value) pairs is as follows:</p>
@@ -526,7 +526,7 @@ <h2 id="creationalpatternjavascript">The Creational Pattern</h2>
526 526 </pre></p>
527 527 <p>A lot of the time, you'll have reasons for approaching this in a much more object-specific way but the above simplistic approach to creation shows you how easy it is to apply this pattern where non-specific object types need to be created. You simply use a constructor to instantiate an instance of your object for later on when you need it. </p>
528 528
529   -<p>&nbsp;</p>
  529 +
530 530 <h2 id="constructorpatternjavascript">The Constructor Pattern</h2>
531 531 <p>The phrase &lsquo;constructor&rsquo; is familiar to most developers, however if you&rsquo;re a beginner it can be useful to review what a constructor is before we get into talking about a pattern dedicated to it. Constructors are used to create specific types of objects - they both prepare the object for use and can also accept parameters which the constructor uses to set the values of member variables when the object if first created. The idea that a constructor is a paradigm can be found in the majority of programming languages, including JavaScript. You&rsquo;re also able to define custom constructors that define properties and methods for your own types of objects. <br></p>
532 532
@@ -557,7 +557,7 @@ <h2 id="constructorpatternjavascript">The Constructor Pattern</h2>
557 557
558 558 <p>The above is a simple version of the constructor pattern but it does suffer from some problems. One is that it makes inheritance difficult and the other is that functions such as toString() are redefined for each of the new objects created using the Car constructor. This isn't very optimal as the function should ideally be shared between all of the instances of the Car type.</p>
559 559
560   -<p>&nbsp;</p>
  560 +
561 561
562 562 <h3>Constructors With Prototypes</h3>
563 563
@@ -678,9 +678,9 @@ <h2 id="singletonpatternjavascript">The Singleton Pattern</h2>
678 678
679 679 </pre>
680 680 </p>
681   -<p>&nbsp;</p>
  681 +
682 682 <p>So, where else is the singleton pattern useful in practice?. Well, it's quite useful when exactly one object is needed to coordinate patterns across the system.&nbsp; Here's one last example of the singleton pattern being used:</p>
683   -<p>&nbsp;</p>
  683 +
684 684 <p>
685 685 <pre class="brush: js">
686 686
@@ -726,7 +726,7 @@ <h2 id="singletonpatternjavascript">The Singleton Pattern</h2>
726 726
727 727
728 728 </pre></p>
729   -<p>&nbsp;</p>
  729 +
730 730 <h2 id="modulepatternjavascript">The Module Pattern</h2>
731 731 <p>Let's now look at the popular <em>module</em> pattern. Note that we'll be covering this pattern in greater detail in the next section of the book, but a basic introduction to it will be given in this chapter.</p>
732 732
@@ -828,8 +828,8 @@ <h2 id="modulepatternjavascript">The Module Pattern</h2>
828 828
829 829 </pre></p>
830 830 <p>To continue reading more about the module pattern, I strongly recommend <a href="">Ben Cherry's JavaScript Module Pattern In-Depth</a> article.</p>
831   -<p>&nbsp;</p>
832   -<p>&nbsp;</p>
  831 +
  832 +
833 833 <h2 id="revealingmodulepatternjavascript">The Revealing Module Pattern</h2>
834 834 <p>Now you&rsquo;re probably a little more familiar with what the Module pattern is. Let&rsquo;s take a look at a slightly improved version - Christian Heilmann&rsquo;s Revealing Module pattern, often described as a neat extension to a rather robust pattern.</p>
835 835 <p>The Revealing Module Pattern came about as Heilmann (now at Mozilla) was frustrated with the fact that if you had to repeat the name of the main object when you wanted to call one public method from another or access public variables.&nbsp; He also disliked the Module pattern&rsquo;s requirement for having to switch to object literal notation for the things you wished to make public. </p>
@@ -863,15 +863,15 @@ <h2 id="revealingmodulepatternjavascript">The Revealing Module Pattern</h2>
863 863
864 864
865 865 </pre></p>
866   -<p>&nbsp;</p>
867 866
868 867
869 868
870 869
871 870
872 871
873   -<p>&nbsp;</p>
874   -<p>&nbsp;</p>
  872 +
  873 +
  874 +
875 875 <h2 id="observerpatternjavascript">The Observer Pattern</h2>
876 876
877 877 <p>Note that this is another pattern we'll be looking at in greater detail in the next section of the book.</p>
@@ -1001,8 +1001,8 @@ <h2 id="observerpatternjavascript">The Observer Pattern</h2>
1001 1001
1002 1002 <p><strong>Note:</strong>If you are interested in a pub/sub pattern implementation using jQuery, I recommend Ben Alman's <a href="">GitHub Gist</a> for an example of how to achieve this.</p>
1003 1003
1004   -<p>&nbsp;</p>
1005   -<p>&nbsp;</p>
  1004 +
  1005 +
1006 1006
1007 1007
1008 1008 <h2 id="mediatorpatternjavascript">The Mediator Pattern</h2>
@@ -1136,8 +1136,8 @@ <h2 id="mediatorpatternjavascript">The Mediator Pattern</h2>
1136 1136 </p>
1137 1137
1138 1138 <p>
1139   - <p>&nbsp;</p>
1140   - <p>&nbsp;</p>
  1139 +
  1140 +
1141 1141 </p>
1142 1142 <h2 id="prototypepatternjavascript">The Prototype Pattern</h2>
1143 1143 <p>The GoF refer to the prototype pattern as one which creates objects based on a template of an existing object through cloning.</p>
@@ -1145,7 +1145,7 @@ <h2 id="prototypepatternjavascript">The Prototype Pattern</h2>
1145 1145 <p>Looking at the definitions for the prototype pattern in existing literature non-specific to JavaScript, you *may* find references to concepts outside the scope of the language such as classes. The reality is that prototypal inheritance avoids using classes altogether. There isn't a 'definition' object nor a core object in theory. We're simply creating copies of existing functional objects.</p>
1146 1146 <p>One of the core benefits of using the prototype pattern is that we're working with the strengths JavaScript has to offer natively rather than attempting to imitate features of other languages (something a few design pattern implementations do). Not only is this an easy way to implement inheritance, but this also comes with a performance boost as well. When defining a function in an object, they're all created by reference (so all child objects point to the same function) instead of creating their own individual copies. </p>
1147 1147 <p>For those interested, real prototypal inheritance, as defined in the ECMAScript 5 standard, requires the use of Object.create which is a recent newly native method. Object.create creates an object which has a specified prototype and which optionally contains specified properties (i.e Object.create(prototype, optionalDescriptorObjects)). We can also see this being demonstrated in the example below:</p>
1148   -<p>&nbsp;</p>
  1148 +
1149 1149 <pre class="brush: js">
1150 1150
1151 1151 // No need for capitalization as it's not a constructor
@@ -1159,10 +1159,10 @@ <h2 id="prototypepatternjavascript">The Prototype Pattern</h2>
1159 1159 = 'Toyota Camry';
1160 1160
1161 1161 </pre></p>
1162   -<p>&nbsp;</p>
  1162 +
1163 1163 <p>
1164 1164 Object.create allows you to easily implement advanced concepts such as differential inheritance where objects are able to directly inherit from other objects. With Object.create you're also able to initialise object properties using the second supplied argument. For example:
1165   -</p><p>&nbsp;</p>
  1165 +</p>
1166 1166 <p>
1167 1167 <pre class="brush: js">
1168 1168
@@ -1189,7 +1189,7 @@ <h2 id="prototypepatternjavascript">The Prototype Pattern</h2>
1189 1189 Here the properties can be initialized on the second argument of Object.create using an object literal using the syntax similar to that used by the Object.defineProperties and Object.defineProperty methods. It allows you to set the property attributes such as enumerable, writable or configurable.</p>
1190 1190
1191 1191 <p>If you wish to implement the prototype pattern without directly using Object.create, you can simulate the pattern as per the above example as follows:</p>
1192   -<p>&nbsp;</p>
  1192 +
1193 1193 <p>
1194 1194 <pre class="brush: js">
1195 1195
@@ -1222,8 +1222,8 @@ <h2 id="prototypepatternjavascript">The Prototype Pattern</h2>
1222 1222 </p>
1223 1223
1224 1224
1225   -<p>&nbsp;</p>
1226   -<p>&nbsp;</p>
  1225 +
  1226 +
1227 1227 <h2 id="commandpatternjavascript">The Command Pattern</h2>
1228 1228 <p>The command pattern aims to encapsulate method invocation, requests or operations into a single object and gives you the ability to both parameterize and pass method calls around that can be executed at your discretion. In addition, it enables you to decouple objects invoking the action from the objects which implement them, giving you a greater degree of overall flexibility in swapping out concrete 'classes'.</p>
1229 1229
@@ -1288,8 +1288,8 @@ <h2 id="commandpatternjavascript">The Command Pattern</h2>
1288 1288 CarManager.execute({request: "requestInfo", model: 'Ford Escort', carID: '543434'});
1289 1289 CarManager.execute({request: "buyVehicle", model: 'Ford Escort', carID: '543434'});
1290 1290 </pre></p>
1291   -<p>&nbsp;</p>
1292   -<p>&nbsp;</p>
  1291 +
  1292 +
1293 1293 <h2 id="drypatternjavascript">The DRY Pattern </h2>
1294 1294 <p><strong>Disclaimer: </strong>DRY is essentially a way of thinking and many patterns aim to achieve a level of DRY-ness with their design. In this section we'll be covering what it means for code to be DRY but also covering the DRY design pattern based on these same concepts.</p>
1295 1295 <p>A challenge that developers writing large applications frequently have is writing similar code multiple times. Sometimes this occurs because your script or application may have multiple similar ways of performing something. Repetitive code writing generally reduces productivity and leaves you open to having to re-write code you&rsquo;ve already written similar times before, thus leaving you with less time to add in new functionality.</p>
@@ -1361,7 +1361,7 @@ <h2 id="drypatternjavascript">The DRY Pattern </h2>
1361 1361
1362 1362 </pre><br>
1363 1363 </p>
1364   -<p>&nbsp;</p>
  1364 +
1365 1365 <h2 id="facadepatternjavascript">The Facade Pattern</h2>
1366 1366
1367 1367 <p>When we put up a facade, we present an outward appearance to the world which may conceal a very different reality. This was the inspiration for the name behind the next pattern we're going to review - the facade pattern. The facade pattern provides a convenient higher-level interface to a larger body of code, hiding its true underlying complexity. Think of it as simplifying the API being presented to other developers, something which almost always improves usability.</p>
@@ -1463,14 +1463,14 @@ <h2 id="facadepatternjavascript">The Facade Pattern</h2>
1463 1463
1464 1464
1465 1465
1466   -<p>&nbsp;</p>
  1466 +
1467 1467 <h2 id="factorypatternjavascript">The Factory Pattern</h2>
1468 1468 <p>Similar to other creational patterns, the Factory Pattern deals with the problem of creating objects (which we can think of as &lsquo;factory products&rsquo;) without the need to specify the exact class of object being created.&nbsp; </p>
1469 1469 <p>Specifically, the Factory Pattern suggests defining an interface for creating an object where you allow the subclasses to decide which class to instantiate. This pattern handles the problem by defining a completely separate method for the creation of objects and which sub-classes are able to override so they can specify the &lsquo;type&rsquo; of factory product that will be created.</p>
1470 1470 <p>This can come in quite useful, in particular if the creation process involved is quite complex. eg. if it strongly depends on the settings in configuration files.</p>
1471 1471 <p>You can often find factory methods in frameworks where the code for a library may need to create objects of particular types which may be subclassed by scripts using the frameworks.</p>
1472 1472 <p>In our example, let&rsquo;s take the code used in the original Constructor pattern example and see what this would look like were we to optimize it using the Factory Pattern:</p>
1473   -<p>&nbsp;</p>
  1473 +
1474 1474 <p>
1475 1475 <pre class="brush: js">
1476 1476
@@ -1498,7 +1498,7 @@ <h2 id="factorypatternjavascript">The Factory Pattern</h2>
1498 1498 */
1499 1499
1500 1500 </pre>
1501   - <p>&nbsp;</p>
  1501 +
1502 1502
1503 1503 <h3>When To Use This Pattern</h3>
1504 1504
@@ -1509,7 +1509,7 @@ <h2 id="factorypatternjavascript">The Factory Pattern</h2>
1509 1509 <li>When you're working with many small objects that share the same properties</li>
1510 1510 </ul>
1511 1511 </p>
1512   -<p>&nbsp;</p>
  1512 +
1513 1513 <h3>When Not To Use This Pattern</h3>
1514 1514
1515 1515 <p>It's generally a good practice to not use the factory pattern in every situation as it can easily add an unnecessarily additional aspect of complexity to your code. It can also make some tests more difficult to run.
@@ -1580,8 +1580,8 @@ <h2 id="mixinpatternjavascript">The Mixin Pattern</h2>
1580 1580
1581 1581 </pre>
1582 1582 </p>
1583   -<p>&nbsp;</p>
1584   -<p>&nbsp;</p>
  1583 +
  1584 +
1585 1585
1586 1586 <h2 id="decoratorpatternjavascript">The Decorator Pattern</h2>
1587 1587 <p>Decorator patterns are an alternative to creating subclasses. This pattern can be used to wrap objects within another object of the same interface and allows you to both add behaviour to methods and also pass the method call to the original object (ie the constructor of the decorator).</p>
@@ -1624,10 +1624,10 @@ <h2 id="decoratorpatternjavascript">The Decorator Pattern</h2>
1624 1624
1625 1625
1626 1626 </pre></p>
1627   -<p>&nbsp;</p>
  1627 +
1628 1628 <p>
1629 1629 Here's another decorator example where when we invoke performTask on the decorator object, it both performs some behaviour and invokes performTask on the underlying object.</p>
1630   - <p>&nbsp;</p>
  1630 +
1631 1631
1632 1632 <pre class="brush: js">
1633 1633
@@ -1668,18 +1668,18 @@ <h2 id="decoratorpatternjavascript">The Decorator Pattern</h2>
1668 1668 </pre>
1669 1669 </p>
1670 1670
1671   -<p>&nbsp;</p>
1672 1671
1673 1672
1674   -<p>&nbsp;</p>
  1673 +
  1674 +
1675 1675
1676 1676 <h1 id="detailedpatterns">Patterns In Greater Detail</h1>
1677   -<p>&nbsp;</p>
  1677 +
1678 1678 <p>As a beginner, you should hopefully now have a basic understanding of many of the commonly used design patterns in JavaScript (as well as some which are less frequently implemented). In this next section, we're going to explore a selection of the patterns we've already reviewed in greater detail.</p>
1679   -<p>&nbsp;</p>
  1679 +
1680 1680
1681 1681 <h1 id="detailedobserver">The Observer (Pub/Sub) pattern</h1>
1682   -<p>&nbsp;</p>
  1682 +
1683 1683
1684 1684 <p>
1685 1685 As we saw earlier, the general idea behind the Observer pattern is the promotion of loose coupling (or decoupling as it's also referred as). Rather than single objects calling on the methods of other objects, an object instead subscribes to a specific task or activity of another object and is notified when it occurs. Observers are also called Subscribers and we refer to the object being observed as the Publisher (or the subject). Publishers notify subscribers when events occur.</o>
@@ -1733,7 +1733,7 @@ <h1 id="detailedobserver">The Observer (Pub/Sub) pattern</h1>
1733 1733 <li>Ben Truyman's gist <a href=""></a></li>
1734 1734 </ul>
1735 1735
1736   -<p>&nbsp;</p>
  1736 +
1737 1737
1738 1738 <h2>Tutorial</h2>
1739 1739
@@ -2218,7 +2218,7 @@ <h1 id="detailedobserver">The Observer (Pub/Sub) pattern</h1>
2218 2218
2219 2219 <p>
2220 2220 The Observer pattern is useful for decoupling a number of different scenarios in application design and if you haven't been using it, I recommend picking up one of the pre-written implementations mentioned today and just giving it a try out. It's one of the easier design patterns to get started with but also one of the most powerful.</p>
2221   -<p>&nbsp;</p>
  2221 +
2222 2222
2223 2223 <h1 id="detailmvcmvp">MVC And MVP</h1>
2224 2224
@@ -2498,7 +2498,7 @@ <h1 id="detailmvcmvp">MVC And MVP</h1>
2498 2498
2499 2499 <p>As regular Backbone user Derick Bailey has <a href="">previously</a> put it, it&#39;s ultimately best not to force Backbone to fit any specific design patterns. Design patterns should be considered flexible guides to how applications may be structured and in this respect, Backbone fits neither MVC nor MVP. Instead, it borrows some of the best concepts from multiple architectural patterns and creates a flexible framework that just works well.</p>
2500 2500 <p>It <em>is</em> however worth understanding where and why these concepts originated, so I hope that my explanations of MVC and MVP have been of help. Call it <strong>the Backbone way</strong>, MV* or whatever helps reference its flavor of application architecture. Most structural JavaScript frameworks will adopt their own take on classical patterns, either intentionally or by accident, but the important thing is that they help us develop applications which are organized, clean and can be easily maintained.</p>
2501   -<p>&nbsp;</p>
  2501 +
2502 2502
2503 2503 <h1 id="detaildecorator">Decorator Pattern</h1>
2504 2504
@@ -2795,7 +2795,7 @@ <h1 id="detaildecorator">Decorator Pattern</h1>
2795 2795 <p>There are however drawbacks that you should be aware of when implementing the pattern. If poorly managed, it can significantly complicate your application&#39;s architecture as it introduces many small, but similar objects into your namespace. The concern here is that in addition to becoming hard to manage, other developers unfamiliar with the pattern may have a hard time grasping why it&#39;s being used.</p>
2796 2796 <p>Sufficient commenting or pattern research should assist with the latter, however as long as you keep a handle on how widespread you use the decorator in your application you should be fine on both counts.</p>
2797 2797
2798   -<p>&nbsp;</p>
  2798 +
2799 2799
2800 2800
2801 2801 <h1 id="detailnamespacing">Namespacing Patterns</h1>
@@ -2805,7 +2805,7 @@ <h1 id="detailnamespacing">Namespacing Patterns</h1>
2805 2805 <h2>What is namespacing?</h2>
2806 2806 <p>In many programming languages, namespacing is a technique employed to avoid <b>collisions</b> with other objects or variables in the global namespace. They&#39;re also extremely useful for helping organize blocks of functionality in your application into easily manageable groups that can be uniquely identified.</p>
2807 2807 <p>In JavaScript, namespacing at an enterprise level is critical as it&#39;s important to safeguard your code from breaking in the event of another script on the page using the <b>same</b> variable or method names as you are. With the number of <b>third-party</b> tags regularly injected into pages these days, this can be a common problem we all need to tackle at some point in our careers. As a well-behaved &#39;citizen&#39; of the global namespace, it&#39;s also imperative that you do your best to similarly not prevent other developer&#39;s scripts executing due to the same issues.</p>
2808   -<p>&nbsp;</p>
  2808 +
2809 2809 <p>Whilst JavaScript doesn&#39;t really have built-in support for namespaces like other languages, it does have objects and closures which can be used to achieve a similar effect.</p>
2810 2810 <h2>Advanced namespacing patterns</h2>
2811 2811 <p>In this section, I&#39;ll be exploring some advanced patterns and utility techniques that have helped me when working on larger projects requiring a re-think of how application namespacing is approached. I should state that I&#39;m not advocating any of these as *the* way to do things, but rather just ways that I&#39;ve found work in practice.</p>
@@ -3138,10 +3138,10 @@ <h1 id="detailnamespacing">Namespacing Patterns</h1>
3138 3138 <h3>3. Nested namespacing</h3>
3139 3139 <p>An extension of the object literal pattern is nested namespacing. It&#39;s another common pattern used that offers a lower risk of collision due to the fact that even if a namespace already exists, it&#39;s unlikely the same nested children do.</p>
3140 3140 <p>Does this look familiar?</p>
3141   -<p>&nbsp;</p>
  3141 +
3142 3142 <pre class="brush: js">YAHOO.util.Dom.getElementsByClassName(&#39;test&#39;);
3143 3143 </pre>
3144   -<p>&nbsp;</p>
  3144 +
3145 3145 <p>Yahoo&#39;s YUI framework uses the nested object namespacing pattern regularly and at AOL we also use this pattern in many of our main applications. A sample implementation of nested namespacing may look like this:</p>
3146 3146 <pre class="brush: js">var myApp = myApp || {};
3147 3147
@@ -3321,9 +3321,9 @@ <h1 id="detailnamespacing">Namespacing Patterns</h1>
3321 3321 <p>IIFEs and single global variables may work fine for applications in the small to medium range, however, larger codebases requiring both namespaces and deep sub-namespaces require a succinct solution that promotes readability and scales. I feel this pattern achieves all of these objectives well.</p>
3322 3322 <p>I would also recommend trying out some of the suggested advanced utility methods for namespace extension as they really can save you time in the long-run.</p>
3323 3323
3324   -<p>&nbsp;</p>
  3324 +
3325 3325 <h1 id="detailflyweight">Flyweight</h1>
3326   -<p>&nbsp;</p>
  3326 +
3327 3327
3328 3328
3329 3329 <p>The flyweight is considered a useful classical solution for code that's repetitive, slow and inefficient - for example: situations where we might create large numbers of similar objects.</p>
@@ -3371,7 +3371,7 @@ <h1 id="detailflyweight">Flyweight</h1>
3371 3371 <li>Publisher ID</li>
3372 3372 <li>ISBN</li>
3373 3373 </ul>
3374   -<p>&nbsp;</p>
  3374 +
3375 3375 <p>
3376 3376 We'll also require the following properties to keep track of which member has checked out a particular book, the date they've checked it out on as well as the expected date of return.
3377 3377 </p>
@@ -3382,7 +3382,7 @@ <h1 id="detailflyweight">Flyweight</h1>
3382 3382 <li>dueReturnDate</li>
3383 3383 <li>availability</li>
3384 3384 </ul>
3385   -<p>&nbsp;</p>
  3385 +
3386 3386 <p>
3387 3387 Each book would thus be represented as follows, prior to any optimization:
3388 3388 </p>
@@ -3661,7 +3661,7 @@ <h1 id="detailflyweight">Flyweight</h1>
3661 3661 <p>
3662 3662 Note that although we may believe that simply caching our jQuery code may offer just as equivalent performance gains, Padolsey claims that $.single() is still worth using and can perform better. That's not to say don't apply any caching at all, just be mindful that this approach can assist. For further details about $.single, I recommend reading Padolsey's full post.</p>
3663 3663
3664   -<p>&nbsp;</p>
  3664 +
3665 3665
3666 3666
3667 3667 <h1 id="detailmodule">Modules</h1>
@@ -3790,7 +3790,7 @@ <h1 id="detailmodule">Modules</h1>
3790 3790 <li>Given that functions are declared normally and are named, it can be easier to show call stacks in a debugger when we're attemping to discover what function(s) threw an exception.</li>
3791 3791 <li>As T.J Crowder has pointed out in the past, it also enables us to return different functions depending on the environment. In the past, I've seen developers use this to perform UA testing in order to provide a code-path in their module specific to IE, but we can easily opt for feature detection these days to achieve a similar goal.</li>
3792 3792 </ul>
3793   -<p>&nbsp;</p>
  3793 +
3794 3794 <p>
3795 3795 It should be noted that there isn't really an explicitly true sense of 'privacy' inside JavaScript because unlike some traditional languages, it doesn't have access modifiers. Variables can't technically be declared as being public nor private and so we use function scope to simulate this concept. Within the module pattern, variables or methods declared are only available inside the module itself thanks to closure. Variables or methods defined within the returning object however are available to everyone.
3796 3796 </p>
@@ -3896,16 +3896,16 @@ <h1 id="detailmodule">Modules</h1>
3896 3896
3897 3897 <p>Note: I have also written extensively on modern module formats including AMD and CommonJS. If you would like to learn more about these and the upcoming modules in, please feel free to continue reading about them <a href="">here</a>.</p>
3898 3898
3899   -<p>&nbsp;</p>
  3899 +
3900 3900 <h1 id="designpatternsjquery">Examples Of Design Patterns in jQuery</h1>
3901   -<p>&nbsp;</p>
  3901 +
3902 3902 <p>Now that we've taken a look at vanilla-JavaScript implementations of popular design patterns, let's switch gears and find out what of these design patterns might look like when implemented using jQuery. jQuery (as you may know) is currently the most popular JavaScript library and provides a layer of 'sugar' on top of regular JavaScript with a syntax that can be easier to understand at a glance.</p>
3903 3903 <p>Before we dive into this section, it's important to remember that many vanilla-JavaScript design patterns can be intermixed with jQuery when used correctly because jQuery is still essentially JavaScript itself. <br>
3904 3904 <br>
3905 3905 jQuery is an interesting topic to discuss in the realm of patterns because the library actually uses a number of design patterns itself. &nbsp;What impresses me is just how cleanly all of the patterns it uses have been implemented so that they exist in harmony. </p>
3906 3906 <p>Let's take a look at what some of these patterns are and how they are used.<br>
3907 3907 </p>
3908   -<p>&nbsp;</p>
  3908 +
3909 3909 <h2 id="modulepatternjquery"><strong>Module Pattern</strong></h2>
3910 3910
3911 3911 <p><br>
@@ -3958,7 +3958,7 @@ <h2 id="modulepatternjquery"><strong>Module Pattern</strong></h2>
3958 3958 myPlugin.init(/* custom options */);
3959 3959 myPlugin.method1();
3960 3960 </pre>
3961   -<p>&nbsp;</p>
  3961 +
3962 3962 <h2 id="lazyinitialisationjquery"><strong>Lazy Initialization</strong></h2>
3963 3963 <p><br>
3964 3964 <strong>Lazy Initialization </strong>is a design pattern wish allows us to delay expensive processes (eg. the creation of objects) until the first instance they are needed. An example of this is the <code>.ready()</code> function in jQuery that only executes a function once the DOM is ready.<br>
@@ -3980,7 +3980,7 @@ <h2 id="lazyinitialisationjquery"><strong>Lazy Initialization</strong></h2>
3980 3980 </pre>
3981 3981 </p>
3982 3982 <p>Whilst it isn't directly used in jQuery core, some developers will be familiar with the concept of LazyLoading via plugins such as <a href="">this</a>. LazyLoading is effectively the same as Lazy initialization and is a technique whereby additional data on a page is loaded when needed (e.g when a user has scrolled to the end of the page). In recent years this pattern has become quite prominent and can be currently be found in both the Twitter and Facebook UIs.</p>
3983   -<p>&nbsp;</p>
  3983 +
3984 3984 <h2 id="compositepatternjquery"><strong>The Composite Pattern</strong></h2>
3985 3985 <p><br>
3986 3986 <strong>The Composite Pattern</strong> describes a group of objects that can be treated in the same way a single instance of an object may be. Implementing this pattern allows you to treat both individual objects and compositions in a uniform manner. In jQuery, when we're accessing or performing actions on a single DOM element or a collection of elements, we can treat both sets in a uniform manner. This is demonstrated by the code sample below:<br>
@@ -4017,7 +4017,7 @@ <h2 id="wrapperpatternjquery"><strong>The Wrapper Pattern</strong></h2>
4017 4017 });
4018 4018
4019 4019 </pre>
4020   -<p>&nbsp;</p>
  4020 +
4021 4021 <h2 id="facadepatternjquery"><strong>The Facade Pattern</strong></h2>
4022 4022 <p><br>
4023 4023 As we saw in earlier sections, the <strong>Facade Pattern</strong> is where an object provides a simpler interface to a larger (possibly more complex) body of code. Facades can be frequently found across the jQuery library and make methods both easier to use and understand, but also more readable. The following are facades for jQuery's <code>$.ajax()</code>:<br>
@@ -4065,7 +4065,7 @@ <h2 id="facadepatternjquery"><strong>The Facade Pattern</strong></h2>
4065 4065
4066 4066 </pre>
4067 4067 <p>What's even more interesting is that the above facades are actually facades in their own right. You see, <code>$.ajax</code> offers a much simpler interface to a complex body of code that handles cross-browser XHR (XMLHttpRequest) as well as <a href="">deferreds</a>. While I could link you to the jQuery source, here's a <a href="">cross-browser XHR implementation</a> just so you can get an idea of how much easier this pattern makes our lives.</p>
4068   -<p>&nbsp;</p>
  4068 +
4069 4069 <h2 id="observerpatternjquery"><strong>The Observer Pattern</strong> </h2>
4070 4070 <p><br>
4071 4071 Another pattern we've look at previously is the <strong>Observer (Publish/Subscribe) pattern</strong> - it's where a subject (the publisher or object), keeps a list of its dependants, which are known as observers (subscribers), and notifies them automatically of any changes in state.
@@ -4155,7 +4155,7 @@ <h2 id="observerpatternjquery"><strong>The Observer Pattern</strong> </h2>
4155 4155 */
4156 4156 </pre>
4157 4157
4158   -<p>&nbsp;</p>
  4158 +
4159 4159 <h2 id="iteratorpatternjquery"><strong>The Iterator Pattern</strong></h2>
4160 4160 <p><br>
4161 4161 <strong>The Iterator Pattern </strong>is a design pattern where iterators (objects that allow us to traverse through all the elements of a collection) access the elements of an aggregate object sequentially without needing to expose its underlying form.</p><p>Iterators encapsulate the internal structure of how that particular iteration occurs - in the case of jQuery's <code>$(el).each()</code> iterator, you are actually able to use the underlying code behind <code>$.each()</code> to iterate through a collection, without needing to see or understand the code working behind the scenes that's providing this capability. This is a pattern similar to the facade, except it deals explicitly with iteration.<br>
@@ -4171,7 +4171,7 @@ <h2 id="iteratorpatternjquery"><strong>The Iterator Pattern</strong></h2>
4171 4171 });
4172 4172
4173 4173 </pre>
4174   -<p>&nbsp;</p>
  4174 +
4175 4175 <h2 id="strategypatternjquery"><strong>The Strategy Pattern</strong></h2>
4176 4176 <p><br>
4177 4177 <strong>The Strategy Pattern</strong> is a pattern where a script may select a particular algorithm at runtime. The purpose of this pattern is that it's able to provide a way to clearly define families of algorithms, encapsulate each as an object and make them easily interchangeable. You could say that the biggest benefit this pattern offers is that it allows algorithms to vary independent of the clients that utilize them.</p><p>An example of this is where jQuery's <code>toggle()</code> allows you to bind two or more handlers to the matched elements, to be executed on alternate clicks.The strategy pattern allows for alternative algorithms to be used independent of the client internal to the function.<br>
@@ -4185,7 +4185,7 @@ <h2 id="strategypatternjquery"><strong>The Strategy Pattern</strong></h2>
4185 4185 });
4186 4186 </pre>
4187 4187 </p>
4188   -<p>&nbsp;</p>
  4188 +
4189 4189 <h2 id="proxypatternjquery"><strong>The Proxy Pattern</strong></h2>
4190 4190 <p><br>
4191 4191 <strong>The Proxy Pattern</strong> - a proxy is basically a class that functions as an interface to something else: a file, a resource, an object in memory, something else that is difficult to duplicate etc. jQuery's <code>.proxy()</code> method takes as input a function and returns a new one that will always have a particular context - it ensures that the value of <code>this</code> in a function is the value you desire. This is parallel to the idea of providing an interface as per the proxy pattern.<br>
@@ -4220,7 +4220,7 @@ <h2 id="proxypatternjquery"><strong>The Proxy Pattern</strong></h2>
4220 4220 });
4221 4221 </pre>
4222 4222
4223   -<p>&nbsp;</p>
  4223 +
4224 4224 <h2 id="builderpatternjquery"><strong>The Builder Pattern</strong></h2>
4225 4225 <p><br>
4226 4226 <strong>The Builder Pattern</strong>'s general idea is that it abstracts the steps involved in creating objects so that different implementations of these steps have the ability to construct different representations of objects. Below are examples of how jQuery utilizes this pattern to allow you to dynamically create new elements. <br>
@@ -4236,7 +4236,7 @@ <h2 id="builderpatternjquery"><strong>The Builder Pattern</strong></h2>
4236 4236 .appendTo('#container');
4237 4237 </pre>
4238 4238 </p>
4239   -<p>&nbsp;</p>
  4239 +
4240 4240 <h2 id="prototypepatternjquery"><strong>The Prototype Pattern</strong></h2>
4241 4241 <p><br>
4242 4242 As we've seen, the <strong>Prototype Pattern</strong> is used when objects are created based on a template of an existing object through cloning. Essentially this pattern is used to avoid creating a new object in a more conventional manner where this process may be expensive or overly complex.<br>
@@ -4301,7 +4301,7 @@ <h2 id="prototypepatternjquery"><strong>The Prototype Pattern</strong></h2>
4301 4301
4302 4302
4303 4303
4304   -<p>&nbsp;</p>
  4304 +
4305 4305 <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
4306 4306
4307 4307
@@ -4362,8 +4362,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
4362 4362
4363 4363 <p>I should also mention that none of this would be possible without the previous work, input and advice of other members of the jQuery community. I’ve listed them inline with each pattern so that you can read up on their individual work if interested.</p>
4364 4364
4365   -<p>&nbsp;</p>
4366   -<p>&nbsp;</p>
  4365 +
  4366 +
4367 4367 <h3>A Lightweight Start</h3>
4368 4368
4369 4369 <p>Let’s begin our look at patterns with something basic that follows best practices (including those in the jQuery plugin-authoring guide). This pattern is ideal for developers who are either new to plugin development or who just want to achieve something simple (such as a utility plugin). This lightweight start uses the following:</p>
@@ -4465,8 +4465,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
4465 4465 <li>“<a href="">Create Your First jQuery Plugin, Part 2</a>,” Andrew Wirick</li>
4466 4466 </ul>
4467 4467
4468   -<p>&nbsp;</p>
4469   -<p>&nbsp;</p>
  4468 +
  4469 +
4470 4470 <h3>“Complete” Widget Factory</h3>
4471 4471
4472 4472 <p>While the authoring guide is a great introduction to plugin development, it doesn’t offer a great number of conveniences for obscuring away from common plumbing tasks that we have to deal with on a regular basis.</p>
@@ -4587,8 +4587,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
4587 4587 <li>“<a href="">Understanding jQuery UI Widgets: A Tutorial</a>,” Hacking at 0300</li>
4588 4588 </ul>
4589 4589
4590   -<p>&nbsp;</p>
4591   -<p>&nbsp;</p>
  4590 +
  4591 +
4592 4592
4593 4593 <h3>Namespacing And Nested Namespacing</h3>
4594 4594
@@ -4667,8 +4667,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
4667 4667 <li>“<a href="">Modules and namespaces in JavaScript</a>,” Axel Rauschmayer</li>
4668 4668 </ul>
4669 4669
4670   -<p>&nbsp;</p>
4671   -<p>&nbsp;</p>
  4670 +
  4671 +
4672 4672 <h3>Custom Events For Pub/Sub (With The Widget factory)</h3>
4673 4673
4674 4674 <p>You may have used the Observer (Pub/Sub) pattern in the past to develop asynchronous JavaScript web applications. The basic idea here is that elements will publish event notifications when something interesting occurs in your application. Other elements then subscribe to or listen for these events and respond accordingly. This results in the logic for your application being significantly more decoupled (which is always good).</p>
@@ -4738,8 +4738,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
4738 4738 <li>“<a href="">Understanding the Publish/Subscribe Pattern for Greater JavaScript Scalability</a>,” Addy Osmani</li>
4739 4739 </ul>
4740 4740
4741   -<p>&nbsp;</p>
4742   -<p>&nbsp;</p>
  4741 +
  4742 +
4743 4743 <h3>Prototypal Inheritance With The DOM-To-Object Bridge Pattern</h3>
4744 4744
4745 4745 <p>In JavaScript, we don’t have the traditional notion of classes that you would find in other classical programming languages, but we do have prototypal inheritance. With prototypal inheritance, an object inherits from another object. And we can apply this concept to jQuery plugin development.</p>
@@ -4834,8 +4834,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
4834 4834 </ul>
4835 4835
4836 4836
4837   -<p>&nbsp;</p>
4838   -<p>&nbsp;</p>
  4837 +
  4838 +
4839 4839 <h3>jQuery UI Widget Factory Bridge</h3>
4840 4840
4841 4841 <p>If you liked the idea of generating plugins based on objects in the last design pattern, then you might be interested in a method found in the jQuery UI Widget Factory called <code>$.widget.bridge</code>. This bridge basically serves as a middle layer between a JavaScript object that is created using <code>$.widget</code> and jQuery’s API, providing a more built-in solution to achieving object-based plugin definition. Effectively, we’re able to create stateful plugins using a custom constructor.</p>
@@ -4957,8 +4957,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
4957 4957 <li>“<a href="">Using $.widget.bridge Outside of the Widget Factory</a>,” Eric Hynds</li>
4958 4958 </ul>
4959 4959
4960   -<p>&nbsp;</p>
4961   -<p>&nbsp;</p>
  4960 +
  4961 +
4962 4962 <h3>jQuery Mobile Widgets With The Widget factory</h3>
4963 4963
4964 4964 <p>jQuery mobile is a framework that encourages the design of ubiquitous Web applications that work both on popular mobile devices and platforms and on the desktop. Rather than writing unique applications for each device or OS, you simply write the code once and it should ideally run on many of the A-, B- and C-grade browsers out there at the moment.</p>
@@ -5094,8 +5094,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
5094 5094 */
5095 5095 </pre>
5096 5096
5097   -<p>&nbsp;</p>
5098   -<p>&nbsp;</p>
  5097 +
  5098 +
5099 5099 <h3>RequireJS And The jQuery UI Widget Factory</h3>
5100 5100
5101 5101 <p>RequireJS is a script loader that provides a clean solution for encapsulating application logic inside manageable modules. It’s able to load modules in the correct order (through its order plugin); it simplifies the process of combining scripts via its excellent optimizer; and it provides the means for defining module dependencies on a per-module basis.</p>
@@ -5229,8 +5229,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
5229 5229 <li>“<a href="">Managing Dependencies With RequireJS</a>,” Ruslan Matveev</li>
5230 5230 </ul>
5231 5231
5232   -<p>&nbsp;</p>
5233   -<p>&nbsp;</p>
  5232 +
  5233 +
5234 5234 <h3>Globally And Per-Call Overridable Options (Best Options Pattern)</h3>
5235 5235
5236 5236 <p>For our next pattern, we’ll look at an optimal approach to configuring options and defaults for your plugin. The way you’re probably familiar with defining plugin options is to pass through an object literal of defaults to <code>$.extend</code>, as demonstrated in our basic plugin boilerplate.</p>
@@ -5293,8 +5293,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
5293 5293 <li><a href="">jQuery Pluginization</a> and the <a href="">accompanying gist</a>, Ben Alman</li>
5294 5294 </ul>
5295 5295
5296   -<p>&nbsp;</p>
5297   -<p>&nbsp;</p>
  5296 +
  5297 +
5298 5298 <h3>A Highly Configurable And Mutable Plugin</h3>
5299 5299
5300 5300 <p>Like Alex Sexton’s pattern, the following logic for our plugin isn’t nested in a jQuery plugin itself. We instead define our plugin’s logic using a constructor and an object literal defined on its prototype, using jQuery for the actual instantiation of the plugin object.</p>
@@ -5409,8 +5409,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
5409 5409 <li>“<a href="">Writing Highly Configurable jQuery Plugins, Part 2</a>,” Mark Dalgleish</li>
5410 5410 </ul>
5411 5411
5412   -<p>&nbsp;</p>
5413   -<p>&nbsp;</p>
  5412 +
  5413 +
5414 5414 <h3>AMD- And CommonJS-Compatible Modules</h3>
5415 5415
5416 5416 <p>While many of the plugin and widget patterns presented above are acceptable for general use, they aren’t without their caveats. Some require jQuery or the jQuery UI Widget Factory to be present in order to function, while only a few could be easily adapted to work well as globally compatible modules both client-side and in other environments.</p>
@@ -5702,8 +5702,8 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
5702 5702 <li>“<a href="">Standards And Proposals for JavaScript Modules And jQuery</a>,” James Burke</li>
5703 5703 </ul>
5704 5704
5705   -<p>&nbsp;</p>
5706   -<p>&nbsp;</p>
  5705 +
  5706 +
5707 5707 <h3>What Makes A Good Plugin Beyond Patterns?</h3>
5708 5708
5709 5709 <p>At the end of the day, patterns are just one aspect of plugin development. And before we wrap up, here are my criteria for selecting third-party plugins, which will hopefully help developers write them.</p>
@@ -5732,7 +5732,7 @@ <h1 id="jquerypluginpatterns">Bonus: jQuery Plugin Design Patterns</h1>
5732 5732
5733 5733
5734 5734
5735   -<p>&nbsp;</p>
  5735 +
5736 5736 <h1 id="conclusions">Conclusions</h1>
5737 5737 <p><span id="internal-source-marker_0.14080225546628167">                </span><br>
5738 5738 That&rsquo;s it for this introduction to the world of design patterns in JavaScript &amp; jQuery– I hope you&rsquo;ve found it useful. The contents of this book are in no way an extensive look at the field of patterns, but should give you enough information to get started using the patterns covered in your day-to-day projects. <br>
@@ -5746,11 +5746,11 @@ <h1 id="conclusions">Conclusions</h1>
5746 5746 <li>'<a href="">JavaScript Patterns</a>' by Stoyan Stefanov</li>
5747 5747 <li>&lsquo;<a href="">Pro JavaScript Design Patterns</a>&rsquo; by Ross Harmes and Dustin Diaz.</li>
5748 5748 </ol>
5749   -<p>&nbsp;</p>
  5749 +
5750 5750 <p>If you&rsquo;ve managed to absorb most of the information in my book, I think you&rsquo;ll find reading these the next logical step in your learning process (beyond trying out some pattern examples for yourself of course) : ) </p>
5751 5751 <p>Thanks for reading <em>Essential JavaScript Design Patterns</em>. For more free learning material on JavaScript, please feel free to check out my site: <a href=""></a>.</p>
5752   -<p>&nbsp;</p>
5753   -<p>&nbsp;</p>
  5752 +
  5753 +
5754 5754 <h1 id="references"><span id="internal-source-marker_0.05095413855216446">References</span><br>
5755 5755 </h1>
5756 5756 <ol id="references-list">

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.