-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathfeed.xml
398 lines (306 loc) · 44.4 KB
/
feed.xml
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
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Sloppy Coding</title>
<description></description>
<link>http://slopyjoe.github.io/</link>
<atom:link href="http://slopyjoe.github.io/feed.xml" rel="self" type="application/rss+xml"/>
<pubDate>Tue, 08 Mar 2016 12:24:31 -0700</pubDate>
<lastBuildDate>Tue, 08 Mar 2016 12:24:31 -0700</lastBuildDate>
<generator>Jekyll v3.1.2</generator>
<item>
<title>Test Driven Development Chapter 2</title>
<description><h2 id="chapter-2-degenerate-objects">Chapter 2 Degenerate Objects</h2>
<p>Kent Beck starts off talking about three rules</p>
<ol>
<li>Make a test - the test serves as design documentation. How a piece of code should be invoked, what setup it needs, what outputs we should expect, and what side-effects it can produce (hopefully not any).
I see it as I love to write code but I hate to write technical documentation. By writing tests I get to start off with documentation of the code using code!!! (Crazy right?!)</li>
<li>Make it run - now that the documentation is done we do as little as can be done to make the documentation true. The key to remember to do <strong>as little as possible</strong>. This is like making the code work but hiding it in the basement far far far away from anyone else.</li>
<li>Make it right - this is where we polish up the code as if we want to show it off to the world. Clean up the horrors we created by making it run. The documentation is our guide, letting us know instantly when we
stray off the path.</li>
</ol>
<p>In chapter one we focused on making a test and making it run. In doing so we created a side-effect, everytime we invoke the <em>times</em> method we mutate the <em>amount</em> Dollar contains. Since we have it running lets
make it right.</p>
<p>Here is our checklist with current working item in bold</p>
<ul>
<li>$5 + 10 CHF = $10 if rate is 2:1</li>
<li>~~$5 * 2 = $10~~</li>
<li>Make “amount” private</li>
<li><strong>Dollar side-effects</strong></li>
<li>Money rounding?</li>
</ul>
<p>Before we go making the code right we need to update the ~~documentation~~ test. We want something like</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">public</span> <span class="kt">void</span> <span class="nf">testMultiplication</span><span class="p">(</span><span class="o">)</span> <span class="o">{</span>
<span class="n">Dollar</span> <span class="n">five</span> <span class="o">=</span> <span class="k">new</span> <span class="n">Dollar</span><span class="o">(</span><span class="mi">5</span><span class="o">);</span>
<span class="n">Dollar</span> <span class="n">product</span> <span class="o">=</span> <span class="n">five</span><span class="o">.</span><span class="na">times</span><span class="o">(</span><span class="mi">2</span><span class="o">);</span>
<span class="n">assertEquals</span><span class="o">(</span><span class="mi">10</span><span class="o">,</span> <span class="n">product</span><span class="o">.</span><span class="na">amount</span><span class="o">);</span>
<span class="n">product</span> <span class="o">=</span> <span class="n">five</span><span class="o">.</span><span class="na">times</span><span class="o">(</span><span class="mi">3</span><span class="o">);</span>
<span class="n">assertEquals</span><span class="o">(</span><span class="mi">15</span><span class="o">,</span> <span class="n">product</span><span class="o">.</span><span class="na">amount</span><span class="o">);</span>
<span class="o">}</span>
</code></pre>
</div>
<p>Notice that the test fails to compile with the above changes. We again revert to step two <em>Make it run</em>, this means we need to update our code just enough to get the test to compile and see the expected failure.</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">class</span> <span class="nc">Dollar</span> <span class="o">{</span>
<span class="kt">int</span> <span class="n">amount</span><span class="o">;</span>
<span class="kd">public</span> <span class="n">Dollar</span><span class="o">(</span><span class="kt">int</span> <span class="n">amount</span><span class="o">)</span> <span class="o">{</span> <span class="k">this</span><span class="o">.</span><span class="na">amount</span> <span class="o">=</span> <span class="n">amount</span><span class="o">;</span> <span class="o">}</span>
<span class="kd">public</span> <span class="n">Dollar</span> <span class="n">times</span><span class="o">(</span><span class="kt">int</span> <span class="n">multiplier</span><span class="o">)</span> <span class="o">{</span>
<span class="n">amount</span> <span class="o">*=</span> <span class="n">multiplier</span><span class="o">;</span>
<span class="k">return</span> <span class="kc">null</span><span class="o">;</span>
<span class="o">}</span>
<span class="o">}</span>
</code></pre>
</div>
<p>This little stub gives us the ability to run the test and have a starting point of what to fix. Now it’s time to make it work, taking small steps of course.</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">class</span> <span class="nc">Dollar</span> <span class="o">{</span>
<span class="kt">int</span> <span class="n">amount</span><span class="o">;</span>
<span class="kd">public</span> <span class="n">Dollar</span><span class="o">(</span><span class="kt">int</span> <span class="n">amount</span><span class="o">)</span> <span class="o">{</span> <span class="k">this</span><span class="o">.</span><span class="na">amount</span> <span class="o">=</span> <span class="n">amount</span><span class="o">;</span> <span class="o">}</span>
<span class="kd">public</span> <span class="n">Dollar</span> <span class="n">times</span><span class="o">(</span><span class="kt">int</span> <span class="n">multiplier</span><span class="o">)</span> <span class="o">{</span>
<span class="k">return</span> <span class="k">new</span> <span class="n">Dollar</span><span class="o">(</span> <span class="n">amount</span> <span class="o">*</span> <span class="n">multiplier</span> <span class="o">);</span>
<span class="o">}</span>
<span class="o">}</span>
</code></pre>
</div>
<p>And bam! we removed the side-effects and updated some documentation. It is interesting to see how, during the third phase of making it right, we also had to update the documentation and make it run. Just because we
are on the last phase doesn’t mean we can’t go back to other phases as needed.</p>
<p>Kent Beck left off the chapter talking about the importance of our ~~documentation~~ tests. It gives us something to talk about. It gives future developers something to look at. They may not understand the
decisions made but will definitely understand the way some operation is meant to be called. They will see what is expected of it, and what can be left behind by it. In other words this may not answer the why’s of our software but it
answers the how’s and what’s of our software.</p>
</description>
<pubDate>Mon, 07 Mar 2016 21:16:17 -0700</pubDate>
<link>http://slopyjoe.github.io/bookclub/2016/03/07/tdd_chapter2.html</link>
<guid isPermaLink="true">http://slopyjoe.github.io/bookclub/2016/03/07/tdd_chapter2.html</guid>
<category>bookclub</category>
</item>
<item>
<title>Test Driven Development Intro/Chapter 1</title>
<description><h1 id="about">About</h1>
<p>There are two things I want to get better, 1) writing more and 2) reading more. So since we all love efficiency why not combine the two needs.
This series of posts will be target at summarizing a chapter read to how I interpreted it. The book of interest at the moment is Kent Beck’s
Test Driven Development. As a note some of these posts will be short and sweet and some will be in more detail, all of which are for me and how I interpreted that chapter.
Without further ado lets begin.</p>
<h1 id="part-1---the-money-example">Part 1 - The Money Example</h1>
<p>I will be trying out any examples with code and will post said code on GitHub at <a href="https://github.com/slopyjoe/bookclub-source.git">bookclub-source</a>
I will try to keep it broken up by chapter then by language. Yes I want to experiment with different languages if time is permitting.</p>
<h2 id="chapter-1-multi-currency-money">Chapter 1 Multi-Currency Money</h2>
<p>Ah the beginning, it always seems the hardest just to get the ball rolling but once it’s in motion you can’t stop it!
Before any code/test examples are given we first see what we are trying to achieve. This is an important tool that I seem to forget a lot or it gets lost in my ambition to code.</p>
<p>The requirement given to us is the ability to add multiple amounts in different currencies and convert the end result to a certain currency using exchange rates.
Which then implies we need to be able to convert an amount in one currency to another using an exchange rate.</p>
<p>Kent Beck then writes up a todo list with the two requirements which looks like</p>
<ul>
<li>$5 + 10 CHF = $10 if rate is 2:1</li>
<li><strong>$5 * 2 = $10</strong></li>
</ul>
<p>Notice we tackle the second item as it is the simplest thing we can do to get the ball rolling. The main requirement is the first item but looking at it seems daunting. Not only that
but can tempt me to over optimize or over engineer a solution because I’ll focus on too much too soon. The idea is finding the smallest thing I can do to get the ball rolling.</p>
<p>Now we can start writing some ~~code~~ tests.</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">public</span> <span class="kt">void</span> <span class="nf">testMultiplication</span><span class="p">(</span><span class="o">)</span> <span class="o">{</span>
<span class="n">Dollar</span> <span class="n">five</span> <span class="o">=</span> <span class="k">new</span> <span class="n">Dollar</span><span class="o">(</span><span class="mi">5</span><span class="o">);</span>
<span class="n">five</span><span class="o">.</span><span class="na">times</span><span class="o">(</span><span class="mi">2</span><span class="o">);</span>
<span class="n">assertEquals</span><span class="o">(</span><span class="mi">10</span><span class="o">,</span> <span class="n">five</span><span class="o">.</span><span class="na">amount</span><span class="o">);</span>
<span class="o">}</span>
</code></pre>
</div>
<p>Some of us might look at this simple test and say everything looks awesome! While some of us (me included) will look at this and curse, stating things like ew public members(amount) or OMG how
can you be mutating Dollar’s amount that’s sacrilegious.
The thing to remember is if we(I) focus on making the cleanest, best looking code out there(seems like some utopia I try to always reach…) we loose site of our true requirement MAKE IT WORK.
All we need working is to multiply two numbers within our domain (Currency or in our test’s case Dollar).
Now we shouldn’t forget about what we want done to this code, like making amount private but we shouldn’t focus on it, instead we just add it to our list and get the test to <strong>green</strong>.
So our todo list will look like</p>
<ul>
<li>$5 + 10 CHF = $10 if rate is 2:1</li>
<li><strong>$5 * 2 = $10</strong></li>
<li>Make “amount” private</li>
<li>Dollar side-effects</li>
<li>Money rounding?</li>
</ul>
<p>So my head is clear now and I can move on to getting the test Green which means I have to get the code to compile. To get the test to compile we will need the following</p>
<ul>
<li>class Dollar</li>
<li>Dollar can be constructed with an integer</li>
<li>Dollar has a method <em>times</em> that takes an integer</li>
<li>Dollar has a member field <em>amount</em></li>
</ul>
<p>With that said the code should look something like</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">class</span> <span class="nc">Dollar</span> <span class="o">{</span>
<span class="kt">int</span> <span class="n">amount</span><span class="o">;</span>
<span class="kd">public</span> <span class="n">Dollar</span><span class="o">(</span><span class="kt">int</span> <span class="n">amount</span><span class="o">)</span> <span class="o">{}</span>
<span class="kt">void</span> <span class="n">times</span><span class="o">(</span><span class="kt">int</span> <span class="n">multiplier</span><span class="o">)</span> <span class="o">{}</span>
<span class="o">}</span>
</code></pre>
</div>
<p>Notice that there isn’t a default value for amount or that the constructor or times methods are implemented. This is fine we just want to get the test to compile so we can see that RED.</p>
<p>So now I have a failing test, and can start implementing functionality to get that test GREEN. I immediately want to start assigning amount to the amount given during construction and then mutating
amount to itself * the multiplier given when the <em>times</em> method is invoked. This might seem legit in this case but I should focus on the smallest thing I can do to get the test to pass.
What Kent ended up with is</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">class</span> <span class="nc">Dollar</span> <span class="o">{</span>
<span class="kt">int</span> <span class="n">amount</span><span class="o">;</span>
<span class="kd">public</span> <span class="n">Dollar</span><span class="o">(</span><span class="kt">int</span> <span class="n">amount</span><span class="o">)</span> <span class="o">{}</span>
<span class="kt">void</span> <span class="n">times</span><span class="o">(</span><span class="kt">int</span> <span class="n">multiplier</span><span class="o">)</span> <span class="o">{</span> <span class="n">amount</span> <span class="o">=</span> <span class="mi">5</span> <span class="o">*</span> <span class="mi">2</span><span class="o">;</span> <span class="o">}</span>
<span class="o">}</span>
</code></pre>
</div>
<p>Well the test is green, woo! Wait a second we have dependencies and duplication between the test and code. The test will easily turn red if we did something like</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">public</span> <span class="kt">void</span> <span class="nf">testMultiplication</span><span class="p">(</span><span class="o">)</span> <span class="o">{</span>
<span class="n">Dollar</span> <span class="n">five</span> <span class="o">=</span> <span class="k">new</span> <span class="n">Dollar</span><span class="o">(</span><span class="mi">5</span><span class="o">);</span>
<span class="n">five</span><span class="o">.</span><span class="na">times</span><span class="o">(</span><span class="mi">3</span><span class="o">);</span>
<span class="n">assertEquals</span><span class="o">(</span><span class="mi">15</span><span class="o">,</span> <span class="n">five</span><span class="o">.</span><span class="na">amount</span><span class="o">);</span>
<span class="o">}</span>
</code></pre>
</div>
<p>I also have duplication by having the numbers 5 and 2 in both my test code and my production code. This is where the refactoring phase comes in. I keep having to remember to take small steps, so to
help myself out I will focus on removing 5 first. The code should look something like</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">class</span> <span class="nc">Dollar</span> <span class="o">{</span>
<span class="kt">int</span> <span class="n">amount</span><span class="o">;</span>
<span class="kd">public</span> <span class="n">Dollar</span><span class="o">(</span><span class="kt">int</span> <span class="n">amount</span><span class="o">)</span> <span class="o">{</span> <span class="k">this</span><span class="o">.</span><span class="na">amount</span> <span class="o">=</span> <span class="n">amount</span><span class="o">;</span> <span class="o">}</span>
<span class="kt">void</span> <span class="n">times</span><span class="o">(</span><span class="kt">int</span> <span class="n">multiplier</span><span class="o">)</span> <span class="o">{</span> <span class="n">amount</span> <span class="o">=</span> <span class="n">amount</span> <span class="o">*</span> <span class="mi">2</span><span class="o">;</span> <span class="o">}</span>
<span class="o">}</span>
</code></pre>
</div>
<p>Now I re-run the test and validate that I’m still passing! If it is I can move onto removing the 2 to look like</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">class</span> <span class="nc">Dollar</span> <span class="o">{</span>
<span class="kt">int</span> <span class="n">amount</span><span class="o">;</span>
<span class="kd">public</span> <span class="n">Dollar</span><span class="o">(</span><span class="kt">int</span> <span class="n">amount</span><span class="o">)</span> <span class="o">{</span> <span class="k">this</span><span class="o">.</span><span class="na">amount</span> <span class="o">=</span> <span class="n">amount</span><span class="o">;</span> <span class="o">}</span>
<span class="kt">void</span> <span class="n">times</span><span class="o">(</span><span class="kt">int</span> <span class="n">multiplier</span><span class="o">)</span> <span class="o">{</span> <span class="n">amount</span> <span class="o">=</span> <span class="n">amount</span> <span class="o">*</span> <span class="n">multiplier</span><span class="o">;</span> <span class="o">}</span>
<span class="o">}</span>
</code></pre>
</div>
<p>Again I will re-run and validate, if all is well I can move onto making the code pretty</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="kd">class</span> <span class="nc">Dollar</span> <span class="o">{</span>
<span class="kt">int</span> <span class="n">amount</span><span class="o">;</span>
<span class="kd">public</span> <span class="n">Dollar</span><span class="o">(</span><span class="kt">int</span> <span class="n">amount</span><span class="o">)</span> <span class="o">{</span> <span class="k">this</span><span class="o">.</span><span class="na">amount</span> <span class="o">=</span> <span class="n">amount</span><span class="o">;</span> <span class="o">}</span>
<span class="kt">void</span> <span class="n">times</span><span class="o">(</span><span class="kt">int</span> <span class="n">multiplier</span><span class="o">)</span> <span class="o">{</span> <span class="n">amount</span> <span class="o">*=</span> <span class="n">multiplier</span><span class="o">;</span> <span class="o">}</span>
<span class="o">}</span>
</code></pre>
</div>
<p>Re-run and yep it’s still passing! Now I can mark off one thing on my list</p>
<ul>
<li>$5 + 10 CHF = $10 if rate is 2:1</li>
<li>~~$5 * 2 = $10~~</li>
<li>Make “amount” private</li>
<li>Dollar side-effects</li>
<li>Money rounding?</li>
</ul>
<h2 id="summary">Summary</h2>
<p>Creating lists helps keep my goals in line and allows me to focus on one thing at a time and just append my distractions to that list.
While I focus on one item in that list I have the ability to take the smallest steps I can to scratch off that item. Then once I get a green test I have the ability to take small steps to making the
code right and pretty(time permitting of course).
This is helpful for me as well as for people that suffer from the curse of too many options and paths. The above code could be implemented in any number of ways all of which are right as long as they
meet the requirement. The goal is to get the ball rolling!</p>
</description>
<pubDate>Wed, 02 Mar 2016 21:16:17 -0700</pubDate>
<link>http://slopyjoe.github.io/bookclub/2016/03/02/tdd_chapter1.html</link>
<guid isPermaLink="true">http://slopyjoe.github.io/bookclub/2016/03/02/tdd_chapter1.html</guid>
<category>bookclub</category>
</item>
<item>
<title>Tales of the Refactoring #1</title>
<description><h2 id="brief-explanation-of-tales-of-the-refactoring">Brief explanation of ‘tales of the refactoring’</h2>
<p>Tales of the Refactoring is a collections of interesting refactorings discovered while adding features, fixing bugs (unknown features), or just paying off some technical debt (features stashed for a later day). With that said know that some tales here may be misinterpreted, not fully understood, or just plain old wrong. Either way approach these tales knowing that they are just explanations for a day of development.</p>
<p>These refactoring tales aren’t meant to be ammunition for times when you are itching to refactor but more so smells to be aware of while developing. Not to say that the smell is bad but just a reminder to step back and ask is this the design we want for this feature? (of course the specs gotta be green before you can step back :P)</p>
<p>Action Items are meant for research for the author to understand what happened better and grow his ubiquitous language domain being Software Development.</p>
<h2 id="configuration-for-conditional-logic">Configuration for conditional logic</h2>
<p>While updating some validation logic we ran into a case where config options were passed in to allow conditional validation to happen. This wasn’t an issue until we needed another conditional validation to happen, then we quickly (ok maybe not so quickly and not we mainly my pair) realized that this isn’t going to end well. Below is an example of some action class with config options to conditionally do some action.</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="k">class</span> <span class="nc">ConfigAction</span>
<span class="k">def</span> <span class="nf">initialize</span><span class="p">(</span><span class="n">options</span> <span class="o">=</span> <span class="p">{})</span>
<span class="vi">@switch_1</span> <span class="o">=</span> <span class="n">options</span><span class="p">.</span><span class="nf">fetch</span><span class="p">(</span><span class="ss">:switch_1</span><span class="p">,</span> <span class="kp">false</span><span class="p">)</span>
<span class="vi">@switch_2</span> <span class="o">=</span> <span class="n">options</span><span class="p">.</span><span class="nf">fetch</span><span class="p">(</span><span class="ss">:switch_2</span><span class="p">,</span> <span class="kp">false</span><span class="p">)</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">action</span>
<span class="n">results</span> <span class="o">=</span> <span class="p">{}</span>
<span class="n">results</span><span class="p">.</span><span class="nf">merge</span><span class="p">(</span><span class="n">switch_1_action</span><span class="p">)</span> <span class="k">if</span> <span class="n">switch_1</span>
<span class="n">results</span><span class="p">.</span><span class="nf">merge</span><span class="p">(</span><span class="n">switch_2_action</span><span class="p">)</span> <span class="k">if</span> <span class="n">switch_2</span>
<span class="n">results</span>
<span class="k">end</span>
<span class="kp">private</span>
<span class="kp">attr_reader</span> <span class="ss">:switch_1</span><span class="p">,</span> <span class="ss">:switch_2</span>
<span class="k">def</span> <span class="nf">switch_1_action</span>
<span class="p">{</span><span class="ss">switch_1: </span><span class="s2">"result for switch_1 actions"</span><span class="p">}</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">switch_2_action</span>
<span class="p">{</span><span class="ss">switch_2: </span><span class="s2">"result for switch_2 actions"</span><span class="p">}</span>
<span class="k">end</span>
<span class="k">end</span>
</code></pre>
</div>
<p>So when we need to add a new action say, switch_3 (beautiful name), we would need to have a new config option and another default for it and the new switch_3 action to the <code class="highlighter-rouge">ConfigAction</code> class.
My pair pointed out that it was looking like something he read from Martin Fowler’s Refactoring ‘Replace Conditional with Polymorphism’ section. I should glance through that book and section one day.</p>
<p>Long story short we turned that class into something like:</p>
<div class="highlighter-rouge"><pre class="highlight"><code>
<span class="k">class</span> <span class="nc">ConfigAction</span>
<span class="k">def</span> <span class="nf">initialize</span><span class="err"></span><span class="p">(</span><span class="n">options</span> <span class="o">=</span> <span class="p">{})</span>
<span class="vi">@actions</span> <span class="o">=</span> <span class="n">options</span><span class="p">.</span><span class="nf">fetch</span><span class="p">(</span><span class="ss">:actions</span><span class="p">,</span> <span class="p">[])</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">action</span>
<span class="n">results</span> <span class="o">=</span> <span class="p">{}</span>
<span class="n">actions</span><span class="p">.</span><span class="nf">each</span> <span class="p">{</span> <span class="o">|</span><span class="n">action</span><span class="o">|</span> <span class="n">results</span><span class="p">.</span><span class="nf">merge</span><span class="p">(</span><span class="n">action</span><span class="p">.</span><span class="nf">action</span><span class="p">)</span> <span class="p">}</span>
<span class="n">results</span>
<span class="k">end</span>
<span class="kp">private</span>
<span class="kp">attr_reader</span> <span class="ss">:actions</span>
<span class="k">end</span>
</code></pre>
</div>
<p>Actions now turn into their own objects that respond to <code class="highlighter-rouge">action</code>. The <code class="highlighter-rouge">ConfigAction</code> class no longer knows what switchs can activate actions, it doesn’t even know what actions it can do. All it knows how to do is call <code class="highlighter-rouge">action</code> on some object given to it.</p>
<p>The final product allows additional actions to be added to the <code class="highlighter-rouge">ConfigAction</code> class when we choose to. We don’t need to add behavior and extra tests for that behavior to the <code class="highlighter-rouge">ConfigAction</code> class when a new action is needed. This pays us back by not having to worry about the clients of <code class="highlighter-rouge">ConfigAction</code> and how their behavior might be effected by an additional action. The clients can define their own actions how they seem fit.</p>
<p>Action Items - research name of refactoring and patterns that would have arisen.</p>
<h2 id="decorated-algorithm">Decorated Algorithm</h2>
<p>Next we ran into this little gem while adding a new accessor.
(Note simplified example because I can’t remember exactly how it was but it isn’t the point to regurgitate what we did but to explain what was learned)</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="k">class</span> <span class="nc">ComputerAccessor</span>
<span class="k">def</span> <span class="nf">computers</span>
<span class="no">Computers</span><span class="p">.</span><span class="nf">all</span>
<span class="k">end</span>
<span class="k">end</span>
<span class="k">class</span> <span class="nc">MacCompterAccessor</span>
<span class="k">def</span> <span class="nf">computers</span>
<span class="no">ComputerAccessor</span><span class="p">.</span><span class="nf">new</span><span class="p">.</span><span class="nf">computers</span><span class="p">.</span><span class="nf">where</span><span class="p">(</span><span class="ss">type: </span><span class="s1">'Mac'</span><span class="p">)</span>
<span class="k">end</span>
<span class="k">end</span>
<span class="k">class</span> <span class="nc">WindowsAndDellCompterAccessor</span>
<span class="k">def</span> <span class="nf">computers</span>
<span class="no">ComputerAccessor</span><span class="p">.</span><span class="nf">new</span><span class="p">.</span><span class="nf">computers</span><span class="p">.</span><span class="nf">where</span>
<span class="p">(</span>
<span class="ss">type: </span><span class="s1">'Windows'</span><span class="p">,</span>
<span class="ss">manufacturer: </span><span class="s1">'Dell'</span>
<span class="p">)</span>
<span class="k">end</span>
<span class="k">end</span>
</code></pre>
</div>
<p>After looking a the code puzzled and doodles describing the behavior of all the classes we encountered that decorated the <code class="highlighter-rouge">ComputerAccessor#computers</code> method.<sup id="fnref:decorated"><a href="#fn:decorated" class="footnote">1</a></sup> We came to the conclusion that all the enhanced <code class="highlighter-rouge">ComputerAccessor</code>’s were just filtering on either type or manufacturer.</p>
<p>We ended up enhancing the original <code class="highlighter-rouge">ComputerAccessor</code> to look something like</p>
<div class="highlighter-rouge"><pre class="highlight"><code><span class="k">class</span> <span class="nc">ComputerAccessor</span>
<span class="k">def</span> <span class="nf">initialize</span><span class="p">(</span> <span class="ss">allowed_types: </span><span class="p">[],</span> <span class="ss">allowed_manufacturers: </span><span class="p">[])</span>
<span class="vi">@allowed_types</span> <span class="o">=</span> <span class="n">allowed_typs</span>
<span class="vi">@allowed_manufacturers</span> <span class="o">=</span> <span class="n">allowed_manufacturers</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">computers</span>
<span class="no">Computers</span><span class="p">.</span><span class="nf">all</span><span class="p">.</span><span class="nf">where</span>
<span class="p">(</span>
<span class="ss">type: </span><span class="n">allowed_types</span><span class="p">,</span>
<span class="ss">manufacturer: </span><span class="n">allowed_manufacturers</span>
<span class="p">)</span>
<span class="k">end</span>
<span class="kp">private</span>
<span class="kp">attr_reader</span> <span class="ss">:allowed_types</span><span class="p">,</span> <span class="ss">:allowed_manufacturers</span>
<span class="k">end</span>
</code></pre>
</div>
<p>Action Items - need to conclude what we learned</p>
<p>Category Lesson’s Learned</p>
<div class="footnotes">
<ol>
<li id="fn:decorated">
<p>Yes another new phrase learned today <q>Decorated Algorithm</q> <a href="#fnref:decorated" class="reversefootnote">&#8617;</a></p>
</li>
</ol>
</div>
</description>
<pubDate>Tue, 15 Sep 2015 22:09:00 -0600</pubDate>
<link>http://slopyjoe.github.io/refactoring/2015/09/15/tales-of-refactoring.html</link>
<guid isPermaLink="true">http://slopyjoe.github.io/refactoring/2015/09/15/tales-of-refactoring.html</guid>
<category>refactoring</category>
</item>
</channel>
</rss>