Has it ever been so hot that you wanted to step inside your fridge? 100 degrees outside and this place is the best place to possibly be. #beercave #twoliquors #giant #fridge #atx #austin #texas (at Twin Liquors)
Breaktime. View from the building. #nofilter (at Dimensional Fund Advisors)
Learning za git and #GitHub (at Dimensional Fund Advisors)
[POODR] Single Responsibility in Classes and their Methods
I’m working through chapter 2 and I love this bicycle narrative that’s been weaved into the book.
Basically, we’re learning some practical concepts in using classes when building ruby applications - in this case, a bicycle app that calculates gear ratio.
I won’t go into all the details of the chapter, but as usual, there are concepts that stick out and are worth blogging about.
For instance, as explained in the book, we have this gear_inches method that calculates a number for comparison between bikes with different gear and wheel sizes.
gear inches = wheel diameter * gear ratio
wheel diameter = rim diameter + twice tire diameter
The code example above needs to be refactored because it has more than one responsibility and we want to define methods that only have single responsibilities.
This is an easy refactor with a big payoff.
We can simply separate the previous method into two methods; one for gear_inches and one to calculate diameter.
“The impact of a simple refactoring like this is small, but the cumulative effect of this coding style is huge. Methods that have a single responsibility confer the following benefits:
- Expose previously hidden qualities: refactoring a class so that all of its methods have a single responsibility has a clarifying effect on the class. Even if you do not intend to reorganize the methods into other classes today, having each of them serve a single purpose makes the set of things the class does more obvious.
- Avoid the need for comments: How many times have you seen a comment that is out of date? Because comments are not executable, they are merely a form of decaying documentation…
- Encourage reuse: Small methods encourage coding behavior that is healthy for your application. Other programmers will reuse the methods instead of duplicating the code. They will follow the pattern you have established and create small, reusable methods in turn. This coding style propagates itself.
- Are easy to move to another class: When you get more design information and decide to make changes, small methods are easy to move. You can rearrange behavior without doing a lot of method extraction and refactoring. Small methods lower the barriers to improving your design.
Practical Object-Oriented Design in Ruby is available on Amazon as well as on other sites; check out the official link to the book here for all the relevant links and info.
[TIL] The Ruby Splat Operator
As of ruby 1.9, you can do some pretty odd things with array destructuring and splatting. Putting the star before an object invokes the splat operator, which has a variety of effects…
This blog by Adam Sanderson was really helpful in understanding how the splat operator behaves.
It helps to type in all the code examples into irb/pry and to see the splat operate in your terminal.
Read the post, but here are two highlights that helped me understand splat more clearly:
def say(what, *people)
people.each{|person| puts "#{person}: #{what}"}
end
say "Hello!", "Alice", "Bob", "Carl"
# Alice: Hello!
# Bob: Hello!
# Carl: Hello!
In the example above, what is the first argument, *people is the 2nd, 3rd, 4th and all the other arguments that come after it; all because of that splat.
a = *"Hello" # ["Hello"]
a = *(1..3) # [1,2,3]
a = *[1,2,3] # [1,2,3]
Array coercion is the other useful thing to know about splat.
The splat operator is a nice way to make sure a value is always an array.
Smitty’s!!!!!!” (at Smitty’s Market)
Upgraded macbook with SSD for boot, and original HDD for data, replacing the super drive. #success
