Polymorphism comes form the greek words ‘polys’ meaning much or many and ‘morphe’ meaning form or shape. In programming, it refers to the ability to use functions or methods in different ways for different objects or data types.
Having the ability to use the same method in a different way depending on data input is very useful in Ruby. It greatly decreases the need for long, ugly if statements like this: Continue reading
Receiving input from a user, doing something with that input, and then displaying some output is core to software development. This input and output is reffered to as IO.
In TDD, we should test the behavior of all the code we write, but testing IO can be challenging because we don’t want to be prompted for input or have miscellaneous text printed in the terminal while running our tests. I’m going to walk through a scenario where we have a UI class (i.e., user interface) in Ruby that handles all of the IO and explain how to test it. We’re also going to look at the IO class and its STDIN and STDOUT constants. Continue reading
Self has confused me for a while now so I decided to get to the bottom of the purpose and meaning of self.
- At any point in your program, there is one and only one self
- Self is the current object accesible to you
- It can also be said that Self is the receiver object of the current method (ex: String is the object in String.send(:”length”))
- Since objects in Ruby are usually instances of classes, self is usually the class you are in at any moment
- Using self enables you to call a method on a class (like Person), instead of just one instance of a class (like Laura)
- There are a couple different ways to call methods on self: ‘self.some_method’ OR ‘class << self’ before a group of methods
- You might want to use self if you want to call a method on any potential instance of that object (every Person is born on planet earth but not every Person is named Laura), especially if you don’t plan on having more than one instance of an object (maybe you’re creating a game with one Person, one Fish, and one Monkey–I’m not sure why you would do that–and you don’t want to create multiple instances of Person).
Okay, now for the longer explanation. Continue reading
In my last blog post, I showed how you can estimate the processing time of your algorithm with Big-O notation. But there are easier, more concrete ways to determine how long it will take your algorithms to run. Ruby has two great tools that will help you determine bottlenecks in your code and help you decide which algorthms are the most efficient: Ruby Profiler & Benchmark Modules Continue reading
I’m new to Ruby and to Test Driven Development (TDD). Good thing the latter is helping me learn the former and write better code in the process.
I recently went through the Roman Numeral Kata shown by Jim Weirich here to get more acquainted with TDD. This kata showed me that through TDD I could write pretty, complex (hey, for me this is complex) code without much difficulty. Continue reading