Week 4: Advanced OOP

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.

giphy

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 Components or Classes are responsible for what. Added to this is the difficulty associated with altering your code at that level.

Resources: 

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.

tumblr_ojdv4b7emr1t0l1jvo1_500

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 files and folders, then Classes, then building Classes then Methods and so on. This way you ensure that your application is working every step of the way!

tenor

Resources:

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 (Methods).

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 Mike & 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 Class Mike.

Resources:

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.

god3ue

Submit a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s