How To Understand OO Relationships in Ruby
Before I get started on my very first blog, let me at least introduce myself. My name is Vivek Sanghvi and only a few months ago my knowledge in anything related to coding was => nil. I had graduated with a degree in Biology with the vision to apply to medical school, only to decide I wasn’t satisfied with my career choice.
I had first heard about bootcamps from a family friend who was in a similar boat a few years prior to me. If you’re like me, you probably spent a solid week in panic mode, scouring the internet to see if you had any interest in coding.
To my surprise while prepping for bootcamp interviews, I truly found myself enjoying what I was learning.
I had taken the time to become privy to the basic fundamentals of Ruby, apply to a few coding bootcamps and finally decided on attending Flatiron School’s Software Engineering Immersive Program.
I am currently on the start of the third of the 15 week program and lets just say it has been an experience in itself. However, I can honestly say what you put into the program is what you get out. It is crazy how much I have learned in just a mere two weeks and this blog will delve into the first topic we learned here at Flatiron, Object Oriented Relationships.
Side note: Master this topic for your first coding challenge should you choose to attend Flatiron.
Before we start talking about the various relationships, it is important we have an understanding of Objects and Classes in Ruby. A great resource which I had found helpful when I first started learning about this topic was: https://launchschool.com/books/oo_ruby/read/classes_and_objects_part1
So lets start with the 3 main types of relationships:
- The “Belongs To” Relationship
- The “Has Many” Relationship
- The “Has Many Through/Many to Many” Relationship
If you’re like me, it is way easier understanding something if I am able to visualize it. So let us talk about each relationship using something most of us know and can understand easily: Pokemon. To show the relationships between characters we can imagine Ash and other trainers like Brock and Misty each being an instance of “class Trainer”. The job of each trainer is to try and catch different Pokemon like Pikachu, Charmander, etc. Each of these pokemon are an instance of “class Pokemon”.
- The “Belongs To” Relationship
Using our Pokemon example we can illustrate this “belongs to” model. As stated earlier, each Pokemon has a specific trainer.
The belongs to example illustrated in code can look like:
In the above code, each Pokemon belongs to a trainer. As a result when we initialize a new Pokemon (Pokemon.new) each instance created has a name as well as a trainer which it belongs to. Additionally, the Pokemon class will keep track of the relationship between each Pokemon and each trainer.
2. The “Has Many” Relationship
Using the same code for our belongs to example, but now looking at it from a more abstract point of view, we can see how our code also depicts a has many relationship. In this case, our trainer can have multiple pokemons (because we want our trainer to “catch em all”) and every time a new Pokemon is initialized, it will pass through a pokemon “name” as well as a trainer Object, thus showing and keeping track of the relationship between the two.
3. The “Has Many Through/Many to Many” Relationship
This last relationship can be pretty daunting. But once you understand it from an abstract perspective, coding it out will become way easier.
This is a perfect example of explaining the has many through relationship. In this case, a trainer can have multiple pokemon and the type (type of Pokemon it is: Steel, Fire, Electric, etc) can have many pokemon as well. Furthermore, a pokemon belongs to a trainer as well as a type.
The has many through example illustrated in code can look like:
This relationship will most often be used when we want to access some information from one class from another using the Single Source of Truth. So for instance, if I wanted to find out what types of Pokemon a certain trainer had, I would be using this sort of relationship.
Let’s say for the sake of argument I actually did want to figure out what types of Pokemon a certain trainer had, I would have to add two instance methods as seen in the picture. First my all_pokemon method would iterate through the Pokemon class and returns all of the Pokemon that my specific trainer owns. Next by calling on the types method, we are able to then iterate through my previously called method because within the method types we are calling our all_pokemon method and using .map to get an array back with what types of pokemon our trainer has.
Once you get the general idea of what is happening and how each class is related, coding it out becomes way simpler. The best advice I can give is to not only continue practicing but make your own classes and relationships in order to see how they can all be inter-related.
Understanding code can be pretty terrifying at first but also one of the most rewarding things when we finally understand something. Each day will seem like a challenge but just know you aren’t alone and with practice and definitely with a lot of patience you’ll be learning numerous topics before you know it.
