Object Oriented Programming
Week 5 was interesting in a lot of ways. In keeping with the trajectory of Ignition thus far, we went deeper on some previous material – subterraneum in fact. Leading up to Week 5 we have made use of many different Classes (
fixnum, hash, array, float etc.). In practice, I understood what this meant, a class of
fixnum means that the object in question is an
integer, and that assigning a
class to objects is a convenient and necessary way of grouping permissible actions together. For instance, if you have
array = [1, 2, 'mike', true], you don’t actually expect to be able to add that array to a
fixnum of, say
num = 12. You keep apples with apples and oranges with oranges. Simple, right?
Well, we were already creating our own objects. An example of this would be
mike_age = 29. in this instance,
mike_age is an object of the class
fixnum. But, what if we wanted to get more specific and start creating from the ground up? We create our own classes, of course.
This is where things were a little shaky for me. It took me a solid 3 days of re-reading and re-watching all of the provided material for the week. It was a concept that was abstract but functional, general yet specific. Eventually, I just went line by line and kept at it until it began to make sense to me in a usable way. My learning style insists that what I am learning be actionable information, I need to be able to put pen to paper and make something happen. I enjoy abstract conversations and theoretical talk, but in the real world that is only permissible to a point.
Moving on, let’s discuss the components of creating classes. Here is an example of a
class I created called,
So, when we create a
class, it always starts with
class followed by the name of the class, which is always capitalized (e.g.
Person) – worth noting, class naming follows CamelCase (no underscores and every new word is capitalized – e.g.
Naturally, it ends with an
end just like our methods, loops etc. Inside of our class we always have our first method be called
initialize. It can either take arguments or not. If it does, they are defined below and to the right.
In the case above, what you are looking at is a
Person, which takes 2 arguments, the first representing the
first_name and the second argument representing the
last_name. Here’s something new though, below while still in the initialize method, we have these
@ symbols. What’s that about?
Think of the word
initialize. When we create our class we are initializing certain parameters of that class. When we create a class that accepts arguments, we want those arguments (variables) to be available throughout the class to all of its objects, and so we create something called – Instance Variables. These little buggers are cool, because they are just like a normal variables but we are kind of making them like
:symbols in a way. We are giving them more shelf-life in our programs.
From here, we are able to create methods within our class and we now utilize our instance variables to get them running, these methods can either accept arguments are run without any arguments.
@variable is the instance variable and we are saying, in our
initialize method that this instance variable is equal to the argument of the same name from our newly formed object ‘variable’. Hence,
@variable = variable. Any reference to the variable from then on through the use of methods or otherwise inside of the class will reference the
@variable and not the
variable to avoid confusion.
But, I can hear you in the back, muttering to yourself that I skipped over something.
attr_reader – NOT SO FAST BUD, What’s that all about?
attr_reader– Allows us to access the values inside of the class for a given attribute. We call
attr_readerand then assign all of our instance variables that we would like to allow outside users access to. It is important to note, that
attr_readeronly allows outside users to view the
statecontained in the class instance variable, not change it. In order to allow that, we call on something different.
attr_accessor– This allows what I described above, the user can now call on an instance variable and change its
state(data/value). And this is important. Let’s examine how it could be useful.
Object-Oriented Programming focuses on modeling real-world objects through code. So we could model something like a House for instance. Let’s break it down.
What kind of things would be intrinsic to the creation of a house, excluding for the moment any kind of renovations. Well, things like, # of bedrooms, sq_ft, #baths etc. These are examples of instance variables we would like to give the user access to view but NOT change.
What about instance variables related to a home that may change? Ownership would be a big one obviously. In this case, in our
initialize method, we would declare
@owner = nil. Why nil? Because at the moment of creation, it has no
owner, when it is sold the value can be updated. We will include
@owner in our
attr_accessor at the top of the Class structure. And so, if we define a variable of the class as such:
We can now change the value of
owner by creating an object of the class and then assigning a new value to
@owner, which is accessible to us now because of the
attr_accessor stipulation. It would look something like this:
Now, we can both access and change the value of
@owner. This is beneficial for our true to form object representation of a House. With this new concept under our belts, we can combine it with the lessons of compound data structures to begin creating more accurate representations of real-life objects. Cool stuff!
I apologize if this weekly wrap up quickly became just another tutorial on creating custom classes but I felt it useful knowledge to breakdown. It has practical implication which I like and affords us with much more flexibility and wiggle room for creative coding, which is something I am really looking forward to!
A breakdown of topics covered this week :
- Instance Variables
- Class Instance Methods
- Initialize Methods
- attr_reader / attr_accessor