Taking a Quack at Duck Typing

Your friend, Ruby, goes out and buys¬†Java a pet duck. But wait, on closer inspection, it’s not a duck at all! It just walks like a duck.

Quack!

And quacks like a duck.

“What’s the matter?” Ruby asks.

“It’s not a duck!” Java complains, distraught that the pet has no inheritance relations with the Duck class.

“If it walks like a duck, and quacks like a duck, it’s a duck!”

So what is duck typing?


Duck typing is a feature that allows a language to call a method on an object, if it has the method. Ruby doesn’t care what the object is, but rather, what methods the object has.

However, a caveat of duck typing is that the it tends to only be built-in to the language if the language handles type checking during runtime. This means that duck typing will only work on dynamically typed languages, such as Ruby. In languages like Java and C++, type checking is done during compile-time. As a result, if there is a type conflict, the program will not even compile. Languages that do type-checking during compile-time are called statically typed languages.

In Java, declaring an integer will look like this :

int x = 0;

The type (int) is explicitly stated, which means that Java checks for types during compile-time, making it a statically typed languages.

In Ruby, it would look like this :

x = 0

Ruby sees that x was assigned a number at runtime. Since x was assigned a number, Ruby automatically knows that x must be a Fixnum.

How does it work?


First, we need two different objects that have the same method name. However, the method can’t be given to the object via the same superclass, because it would instead be inheritance.

Let’s take a look at a simple example of duck typing.

class Duck
  def quack
    puts "Quack!"
  end
end

class Alien
  def quack
    puts "I'm not a duck, but... Quack!"
  end
end

def try_quack(duck)
  duck.quack
end

try_quack(Duck.new)
try_quack(Alien.new)

Output :

Quack!
I'm not a duck, but... Quack!

How did Ruby know?


In Ruby’s mind, the Alien instance and the Duck instance are essentially the same. When we called the try_quack method, Ruby wanted an object that had a quack method.

In this case, when we passed in the Duck instance, Ruby saw that the Duck object would quack, so it called the Duck instance’s quack method.

For the Alien, even though the Alien class has nothing to do with the Duck class, it still has a quack method. As a result, Ruby happily calls the Alien class’s quack method.

Conclusion


Duck typing is a powerful feature of Ruby that allows you to call methods on seemingly different objects, as long as those objects have the same method names. As a result, there is no need for inheritance. You simply call the method, and if the object has it, it will work.

Ruby doesn’t care who the object is, but rather what it is.

Top Five Tips for Cleaner Code

We’ve both been there.

You open your favorite programming IDE, and right there. A glorious mess of spaghetti code. You have no clue what it means, and you can’t understand a single thing.

Bad code can waste precious hours of time, when it really should have only taken a few minutes to understand the code if it were refactored and cleaned up.

So today, I’ll teach you, in five simple tips, how to spare other programmers from facing a giant plate of spaghetti.

1. Stop Commenting

That’s right. Stop commenting. While this is controversial, comments are a sign of bad design. If someone needs to read your comment to understand what your code is doing, it is a sign that your code is unreadable. Follow common conventions for your programming language, and make sure what you’re writing is self-explanatory. Which leads into my second tip…

2. Use Good Variable Names

Everyone knows this, but few actually do it correctly. First of all, and this is the critical, stop shortening your variable names. Yes, you can shorten the word “minimum” to min, but if you’re working on an application that handles time, your reader may think min refers to minutes. In particular, if you’re shortening a word, and that shortened word can possibly refer to more than one word, don’t do it.

Readers may also be confused if your variable names don’t actually say what you mean.

For example, imagine if you created a variable called “days”. What does that mean? Days elapsed? Days before something happened? The amount of days in the month? Be specific. Refactor days to daysElapsed, daysInMonth. Do NOT put a comment and write “days refers to the days elapsed since …”. That is absolutely nonsense. Make your variable names self-explanatory.

3. Keep It Simple, Stupid!

Ah, the good ol’ KISS principle. The simplicity of your code determines whether someone looks at your code and says, “WTF IS THIS?” to “Okay, this makes sense.”

If you’re programming a certain function, be clear. Avoid using silly round-about ways. Especially avoid “clever” solutions. Clever and tricky solutions may be shorter or faster, but they can cripple reading speed. Usually, when people do these clever solutions, they will put comments everywhere to compensate for the fact that no one actually understands what they wrote, which ties into tip #1.

This principle also applies to re-inventing the wheel. If your language comes built-in with a feature, use it. Don’t re-implement a data structure that already exists. Often, it isn’t the programmer’s fault, though, since they might not know about the existence of a certain feature. However, this is not an excuse when you are working with other programmers. If what you wrote in 100 lines could be replaced by 1 line, then it should be refactored.

4. Stop Creating God Objects

A good object is one that knows only what it should know, and no more.
A god object is one that knows too much, in particular, things that it shouldn’t.

For example, imagine you had a chair object. It should not know anything except for itself. If your chair knows your social-security number, how much money you make a year, and how many chairs there are around it, then your chair is either the world’s greatest secret spy agent, or it shouldn’t exist.

5. Public Exposure

All variables in a class should be private, unless there is a very compelling reason for a variable to be public. There are very few reasons for a variable to be public, unless it is a global constant, such as Math.PI.

The inverse of this is also true. Stop exposing your privates! If your private variable does not require a getter, do not make a getter. You should be encapsulating your code.

If you have a rectangle class, and you only ever need its area, then don’t make a getter for its width or length. Just make a single public method that multiplies the private width and length variables.

Hide your implementation details! If you have a computer, and you just want to send an email, then there is no reason the user would need to know about the internal workings on the computer. The user doesn’t care how many volts the computer needs. The user doesn’t care about how many gigabytes of RAM the computer has. The user just wants to send an email. And your computer should allow them to do exactly that, in one simple function, without knowing anything else about the computer.

Remember these five points, and you’re sure to write cleaner code.