Next Level Code 3
1. Debugging
Write short classes and methods that are easy to debug
Use your debugger.
2. Clean Code
Extract Temp to Query: Convert your local variables into methods.
Tell Don’t Ask: Call methods on other classes rather than accessing their instance variables.
Depend Upon Abstractions: The more you abstract, the easier your code will be to change.
3. Object Oriented Programming
You might be noticing a pattern. In debugging I told you to write more shorter methods, because they’re easier to debug. In clean code I told you to write more shorter classes, because they’re easier to change. Today I’m going to go over some more Object Oriented Programming concepts.
Don’t Repeat Yourself (DRY)
DRY is one of the most basic principles of code. Instead of copying and pasting, you should figure out how to abstract that chunk of code so you can reuse it later. Finding and abstracting repetition, or “drying out your code”, is one of the most straightforward ways to refactor.
Inheritance
If you write the same block of code in two of your methods, you can write a third method and have both of your methods call that third method. But what about when you have the same method defined for two different classes? That’s where inheritance comes in. Here’s an example of two classes that share some functionality:
class Dolphin def move puts “I swim with my powerful tail.” end def breathe puts “I breathe with my lungs.” end end class Dog def move puts “I walk on four legs.” end def breathe puts “I breathe with my lungs.” end end
OK, so a dog and a dolphin move differently. But, they breathe the same way. They both have lungs, and can’t breathe under water because they don’t have gills. We should create a class that Dolphin and Dog both inherit from. Here’s what that would look like:
class Mammal def breathe puts “I breathe with my lungs.” end end class Dolphin < Mammal def move puts “I swim with my powerful tail.” end end class Dog < Mammal def move puts “I walk on four legs.” end end
There we go. Now I only have to define the breathe method once. My code is dry. There are some more tricks. There are modules which work like super classes except you can mix them into your class. This lets you have one super class, with some different modules to mix into some of your classes. For example, if I added a seal and a cat, I might add a Swimmable module and a Walkable module. Here’s what that would look like:
class Mammal def breathe puts “I breathe with my lungs.” end end module Swimmable def move puts “I swim with my powerful tail.” end end module Walkable def move puts “I walk on four legs.” end end class Dolphin < Mammal include Swimmable end class Seal < Mammal include Swimmable end class Dog < Mammal include Walkable end class Cat < Mammal include Walkable end
There’s one more thing I want to touch on, which is the “super” key word. Super lets you use a super class’s method, and then add additional functionality to that method. Here’s an example:
class Mammal def move puts “I flex my muscles.” end def breathe puts “I breathe with my lungs.” end end module Swimmable def move super puts “I swim with my powerful tail.” end end module Walkable def move super puts “I walk on four legs.” end end
Calling super will call the super class’s method with the same name, and then proceed to run the rest of the code in this instance’s method.
Polymorphism
Polymorphism is the ability of more than one class of object to respond differently to the same method called on it. Our move method above is an example of polymorphism. The great thing about polymorphism is that when a user or another piece of code uses our API, it doesn’t need to know in advance what kind of object it’s working with. The objects themselves will respond how they should to the API. That’s why our method is called “move” instead of “walk” and “swim”. Maybe we have a list of animals, and we want to make them all move. Rather than checking each one for its type and then calling the corresponding method, we can just tell each one to “move” and it will handle what that means for itself. This is also known as duck-typing.
Encapsulation
Encapsulation is related to “tell don’t ask,” or as I prefer to call it “you do you.” You want to make sure that other objects and users only interact with your object’s “public API”. For both safety and clarity, you should make methods that aren’t part of your public API private. To do that you just put a line “private” in your class, and then every method you define below that line is private. Those methods will only be available within the class itself, and won’t be available in another scope.
Curly’s Law
A class should be responsible for one thing, and one thing only. I’ll let Jeff Atwood take it from there: http://blog.codinghorror.com/curlys-law-do-one-thing/