-
Notifications
You must be signed in to change notification settings - Fork 2
Expand file tree
/
Copy pathintroduction.html
More file actions
427 lines (393 loc) · 15.9 KB
/
introduction.html
File metadata and controls
427 lines (393 loc) · 15.9 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
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Desing Patterns</title>
<meta name="Introduction to Design Patterns">
<meta name="author" content="Froilan Miranda">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
<link rel="stylesheet" href="css/reveal.css">
<link rel="stylesheet" href="css/theme/solarized.css" id="theme">
<!-- Code syntax highlighting -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- Printing and PDF exports -->
<script>
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match( /print-pdf/gi ) ? 'css/print/pdf.css' : 'css/print/paper.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
</script>
<!--[if lt IE 9]>
<script src="lib/js/html5shiv.js"></script>
<![endif]-->
</head>
<body>
<div class="reveal">
<div class="slides">
<section><!------------------------------------slide---------------------------------------------->
<h1>Design Patterns</h1>
<h3>Introduction to Pattern Types</h3>
<p>
<small>Created by <a href="http://www.zipcoder.io">Froilan Miranda</a></small>
</p>
</section>
<section><!------------------------------------slide---------------------------------------------->
<section>
<h3>What are Design Patterns?</h3>
<p>
A pattern is a reusable solution that can be applied to commonly occurring problems in software design - in our case, in writing JavaScript web applications. Another way of looking at patterns is as templates for how we solve problems - ones that can be used in quite a few difference situation
</p>
</section>
<section>
<h3>What are Design Patterns?</h3>
<p>
Patterns are not exact solutions. It's important that we remember the role of a pattern is merely to provide us with a solution scheme. Patterns don't solve all design problems nor do the replace good software designers, however, they do support them.
</p>
</section>
<section>
<h3>What are Design Patterns?</h3>
<h4>Advantages patterns have to offer:</h4>
<p>
Reusing patterns assists in preventing minor issues that can cause magor problems in the application development process.
</p>
</section>
<section>
<h3>What are Design Patterns?</h3>
<h4>Advantages patterns have to offer:</h4>
<p>
Patterns can provide generalized solutions, documented in a fashion that doesn't require them to be tied to a specific problem.
</p>
</section>
<section>
<h3>What are Design Patterns?</h3>
<h4>Advantages patterns have to offer:</h4>
<p>
Certain patterns can actually decrease the overall file-size footprint of our code by avoiding repetition
</p>
</section>
<section>
<h3>What are Design Patterns?</h3>
<h4>Advantages patterns have to offer:</h4>
<p>
Patterns add to a developers vocabulary, which makes communication faster.
</p>
</section>
<section>
<h3>What are Design Patterns?</h3>
<h4>Advantages patterns have to offer:</h4>
<p>
Patterns that are frequently used can be improved over time by harnessing the collective experiences other developers using those patterns contribute back to the design pattern community.
</p>
</section>
<section>
<h3>What are Design Patterns?</h3>
<h2>Categories of Patterns</h2>
<ul>
<li>Creational Patterns</li>
<li>Structural Patterns</li>
<li>Behavioural Patterns</li>
</ul>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h3>Creational Design Patterns</h3>
<p>
Creation design patterns focus on handling object-creation mechanisms where objects are created in a manner suitabled for a given situation
</p>
</section>
<section>
<h3>Creational Design Patterns</h3>
<p>
<ul>
<li>Abstract Factory</li>
<li>Builder</li>
<li>Factory Method</li>
<li>Prototype</li>
<li>Singleton</li>
</ul>
</p>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h2>Singleton Pattern</h2>
</section>
<section>
<h3>Singleton Pattern</h3>
<p>
The Singleton pattern is thus known because it restricts instantiation of a class to a single object.
</p>
</section>
<section>
<h3>Singleton Pattern</h3>
<p>
The Singleton pattern can be implemented by creating a class with a method that creates a new instance of the class if one doesn't exist. In the event of an instance already existing, it simply returns a reference to that object.
</p>
</section>
<section>
<h3>Singleton Pattern</h3>
<p>
Singletons differ from static classes (or objects) as we can delay their initialization, generally because they require some information that may not be available during initialization time.
</p>
</section>
<section>
<h3>Singleton Pattern</h3>
<p>
Singletons reduce the need for global variables which is particularly important in JavaScript because it limits namespace pollution and associated risk of name collisions.
</p>
</section>
<section>
<h3>Singleton Pattern</h3>
<p>
Several other patterns, such as, Factory, Prototype, and Façade are frequently implemented as Singletons when only one instance is needed.
</p>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h2>Prototype Pattern</h2>
</section>
<section>
<h3>Prototype Pattern</h3>
<p>The Prototype Pattern creates new objects, but rather than creating non-initialized objects it returns objects that are initialized with values it copied from a prototype - or sample - object.</p>
</section>
<section>
<h3>Prototype Pattern</h3>
<p>An example of where the Prototype pattern is useful is the initialization of business objects with values that match the default values in the database. The prototype object holds the default values that are copied over into a newly created business object.</p>
</section>
<section>
<h3>Prototype Pattern</h3>
<p>Advantages:</p>
<ul>
<li>New objects created from the "skeleton" of an existing object inherit references to existing functions on the prototype chain, thus boosting performance and keeping memory footprints to a minimum.</li>
<li>Great for an application where the focus is on object creation</li>
</ul>
</section>
<section>
<h3>Prototype Pattern</h3>
<p>Disadvantages:</p>
<ul>
<li>Overkill for a project that uses very few objects and/or does not have an underlying emphasis on the extension of prototype chains</li>
</ul>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h2>Factory Pattern</h2>
</section>
<section>
<h3>Factory Pattern</h3>
<p>A Factory Method creates new objects as instructed by the client.</p>
</section>
<section>
<h3>Factory Pattern</h3>
<p>The Factory Method allows the client to delegate object creation while still retaining control over which type to instantiate.</p>
</section>
<section>
<h3>Factory Pattern</h3>
<p>A Factory can provide a generic interface for creating objects, where we can specify the type of factory object we wish to be created.</p>
</section>
<section>
<h3>Factory Pattern</h3>
<p>This is particularly useful if the object creation process is relatively complex - e.g., if it strongly depends on dynamic factors or application configuration.</p>
</section>
<section>
<h3>Factory Pattern</h3>
<p>The key objective of the Factory Method is extensibility. Factory Methods are frequently used in applications that manage, maintain, or manipulate collections of objects that are different but at the same time have many characteristics (i.e. methods and properties) in common.</p>
</section>
<section>
<h3>Factory Pattern</h3>
<p>An example would be a collection of documents with a mix of Xml documents, Pdf documents, and Rtf documents.</p>
</section>
<section>
<h3>Factory Pattern</h3>
<p>When to use:
<ul>
<li>When our object or component setup involves a high level of complexity</li>
<li>When we need to easily generate different instances of objects depending on the environment we are in.</li>
<li>When we're working with may small objects or components that share the same properties.</li>
</ul>
</p>
</section>
<section>
<h3>Factory Pattern</h3>
<p>When not to use:</p>
<p>When applied to the wrong type of problem, this pattern can introduce an unnecessarily great deal of complexity to an application. Unless providing an interface for object creation is a design goal for the library or framework we are writing, I would suggest sticking to explicit constructors to avoid the unnecessary overhead.</p>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h3>Structural Design Patterns</h3>
<p>
Structural patterns are concerned with object composition and typically identify simple ways to realize relationships between different object
</p>
</section>
<section>
<h3>Structural Design Patterns</h3>
<p>
<ul>
<li>Adapter</li>
<li>Bridge</li>
<li>Composite</li>
<li>Decorator</li>
<li>Facade</li>
<li>Flyweight</li>
<li>Proxy</li>
</ul>
</p>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h2>Decorator Pattern</h2>
</section>
<section>
<h3>Decorator Pattern</h3>
<p>Decorators are a structural design pattern that aim to promote code reuse. Similar to Mixins, they can be considered another viable alternative to object subclassing.</p>
</section>
<section>
<h3>Decorator Pattern</h3>
<p>Decorators offer the ability to add behavior to existing classes in a system dynamically.</p>
</section>
<section>
<h3>Decorator Pattern</h3>
<p>The idea is that the decoration itself isn't essential to the base functionality of the class; otherwise, it would be baked into the <i>superclass</i> itself.</p>
</section>
<section>
<h3>Decorator Pattern</h3>
<p>They can be used to modify existing systems where we wish to add additional features to objects without the need to heavily modify the underlying code using them.</p>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h2>Facade Pattern</h2>
</section>
<section>
<p>
This pattern provides a convenient higher-level interface to a larger body of code, hiding its true underlying complexity.
</p>
</section>
<section>
<p>
Facades are a structural pattern that can often be seen in javascript libraries such as jQuery where, although an implementation may support methods with a wide range of behaviors, only a "facade," or limited abstraction of these methods, is presented to the public for use.
</p>
</section>
<section>
<p>
The Façade pattern provides an interface which shields clients from complex functionality in one or more subsystems.
</p>
</section>
<section>
<p>
The Facade pattern both simplifies the interface of a class and decouples the class from the code that uses it.
</p>
</section>
<section>
<p>
The intent of the Façade is to provide a high-level interface (properties and methods) that makes a subsystem or toolkit easy to use for the client.
</p>
</section>
<section>
<p>
On the server, in a multi-layer web application you frequently have a presentation layer which is a client to a service layer. Communication between these two layers takes place via a well-defined API.
</p>
</section>
<section>
<p>
Another area where Façades are used is in refactoring.
</p>
</section>
<section>
<p>
Façades are frequently combined with other design patterns. Facades themselves are often implemented as singleton factories.
</p>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h3>Behavioral Design Patterns</h3>
<p>
Behavioral patterns focus on improving or streamlining the communication between disparate objects in a system
</p>
</section>
<section>
<h3>Behavioural Design Patterns</h3>
<p>
<ul>
<li>Chain of Responsibility</li>
<li>Command</li>
<li>Interpreter</li>
<li>Iterator</li>
<li>Mediator</li>
<li>Memento</li>
<li>Observer</li>
<li>State</li>
<li>Strategy</li>
<li>Template Method</li>
<li>Visitor</li>
</ul>
</p>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h2>Mediator Pattern</h2>
</section>
<section>
<p>
"a neutral party that assists in negotiations and conflict resolution"
</p>
</section>
<section>
<p>
Define an object that encapsulates how a set of objects interact.
</p>
</section>
<section>
<p>
Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
</p>
</section>
<section>
<p>
The Mediator pattern provides central authority over a group of objects by encapsulating how these objects interact.
</p>
</section>
</section>
<section><!------------------------------------slide--------------------------------------------- -->
<section>
<h2>Observer Pattern</h2>
</section>
<section>
</section>
</section>
</div><!-- slides -->
</div><!-- reveal -->
<script src="lib/js/head.min.js"></script>
<script src="js/reveal.js"></script>
<script>
// Full list of configuration options available at:
// https://github.com/hakimel/reveal.js#configuration
Reveal.initialize({
controls: true,
progress: true,
history: true,
center: true,
transition: 'slide', // none/fade/slide/convex/concave/zoom
// Optional reveal.js plugins
dependencies: [
{ src: 'lib/js/classList.js', condition: function() { return !document.body.classList; } },
{ src: 'plugin/markdown/marked.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/markdown/markdown.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
{ src: 'plugin/zoom-js/zoom.js', async: true },
{ src: 'plugin/notes/notes.js', async: true }
]
});
</script>
</body>
</html>