Object-Oriented Programming (Advanced)
This week was a nice break from the stress of the previous two. Instead of learning some completely new framework or language we instead built upon the existing knowledge we had of Ruby. I was so happy to get back to Ruby this week and I think the feeling was unanimous amongst the cohort.
So what did we cover then? Basically, we redefined what we knew of
Class structure in Ruby by insisting that we break each
Class into its simplest of parts. This goes back to what we dealt with in the previous two weeks of React with our Separation of Concerns.
This concept has significant value as we progress further down the line. As our applications begin to scale and grow larger it will become far more difficult to discern what
Classes are responsible for what. Added to this is the difficulty associated with altering your code at that level.
- Separation of Concerns
- Separation of Concerns (StackOverflow)
- When to use Modules and separate classes
If you break up your
Classes into their simplest of functions you now have a modular codebase which can be easily altered – otherwise one change may ignite a firestorm of errors.
From there we went back into Test-Driven Development. We have covered TDD in the past, but this time it was more of a central focus. I really got a lot out of this week in terms of developing strategies for building an application from scratch.
In essence, the importance of TDD can be summarized as such. It helps you to visualize the properties and functionality you would expect to see out of your application and then ensures that, once created, your application is functioning correctly.
Someone may naturally think that they would first conceptualize an app and then begin writing code to fulfill those ideas followed by some testing. TDD says this is a backwards view of coding. TDD calls for first writing tests and then the code necessary to make those tests pass.
Why is this important? It is important because it eliminates (or greatly reduces) the likelihood of erroneous or conflicting code being written. If you can write a solid test, you then only need to focus on writing code that will satisfy those tests. In this sense, you start small, Test for
Classes, then building
Methods and so on. This way you ensure that your application is working every step of the way!
- TDD (Wikipedia)
- Intro to TDD, an Essay (really great overview)
- How to best learn TDD
- What TDD is and why you should care!
After we nailed TDD we covered Modules and Inheritance. Modules can be described similar to how we were breaking up our classes above. In short, we can create
Modules that will hold
Methods which can then be imported into classes as we see fit to be used.
This is similar to breaking up our classes in that we are able to call on our
Module from anywhere in our code, as long as you import it into your
Class you will now have access whatever code is contained inside of it. This is especially useful for making your code
DRY when you have multiple
Classes utilizing identical functionality (
Inheritance is similar in a lot of ways. If you are creating a
Class that you expect will have a lot of the same
methods as another
Class you can just use inheritance to
inherit those properties.
For instance, you have a
Class Mike and a
Class Jim. Inside both of these classes you have a function called
say_hello which will say
hello!. You could then just create a
Person class, give it the
say_hello function, then create your classes for
Mike & Jim and then call the method inherited from
Person on those classes for both
Jim. Inheritance syntax will look something like this
Class Mike < Person. It looks just like you would imagine it working,
Person is the “master” class if you want to think of it like that, and
Mike is inheriting the properties defined within
Person to be used in the
Aside from the nitty gritty of what we covered we were also tasked with making a fully functional game of Blackjack! I had a lot of fun working on this with two of my classmates. We were able to get it up and running and fully functional, we even included into it some random variability so that the dealer didn’t always act in such a predictable way which was fun.