Ruby Object Relationships: AirBnB with the Kardashians.
By: Sunny P
Tags: Object Relationships, Flatiron School, Ruby, London Tech, Programming

Until we get to doing Object Oriented Programming, we haven’t actually utilised the true capabilities of the ruby language (or any language for the matter). At the start of my bootcamp journey, this is something I found quite tricky to wrap my head around. Here I outline certain things that have stuck to me about this topic that I feel will help me in my learning going forward. Great, so lets get to it!

With object-oriented programming we can write programs that reflect real-world situations and environments. In the real world, different things (like people) are related to one another and interact with each other (sometimes too much) . For example, one of the coding labs I was working on, followed a structure of classes/models that would be involved in the formation of an app like AirBnB. This was one of the first coding exercises I did where I wasn’t able to run rspec to check if my tests were passing a given criteria. So of course that meant I had to input my own data.

Behold my seed data!

Now seed data is basically anything that must be loaded for an application to work properly. At first the idea of having to put in my own data and seeing if it was doing what I wanted it to seemed a bit daunting. However with more practice, I started to have fun with the data, due to the newfound freedom of being able play around with your data.

So as you see there, I created multiple instances in each of my classes. That’s 7 trips across the Kardashian sisters who were in my Guest class who between them travelled to London, Paris & Milan, cities that are in my Listing class. Here the Trip class is my joining class, so this is where we can establish the relationship that my Guest s have used many Listing s through going on Trips . So what I’ve just described is the “Many to many relationship”. Something I have been taught at bootcamp, is that it would be of great help to you if you drew out the relationships between your classes to help you visualise these relationships. Like seen below:

This in a way outlines exactly whats going on with the triple lined arrows pointing to the Trip class. What this show’s is that a Guest can have “many” trips and that a Trip belongs to a Guest . Similarly a Listing can have “many” trips (through being booked multiple times), whilst Trip belongs to a Listing (assuming the guests stay in one location for the duration of their trip). So Listings can have many Guests through trips and Guests can have many Listings through trips, hence the “Many-to-many”.

I guess what I’m trying to get at here is that there is always a way to simplify these relationships in a way that you can understand them. Whether it be a diagram like the one above, or a seed data which you can then test in your command line.

Now let’s talk a bit about the code. So here I have the guest class the ReadMe guide to the coding lab was pretty explicit so in terms of setting up classes it was made quite clear what my methods would need to do.

Now starting with the initialize method which takes in the argument of name in the Guest class, essentially creates an instance of a “Guest” in my case one of the Kardashians. So in my seed data I was able to initialise an instance of Kourtney Kardashian as one of my guests with the line kourtney = Guest.new("Kourtney") where kourtney (in lower case) is the key of the object stored and “Kourtney”, is the string stored in the @name instance variable. Notice I also have the @@all class variable which has been set to an empty array at the very start. This is a process which repeats in each of my classes. After setting @@all to an empty array, as my initialize method is called with Class.new I store the instance itself into that array and with the self.all method I am then able to call on it to return the array of all the instances in the that class. So the same happens for the Listing and Trip classes too.

You will see that the trip method repeats itself in both the non-joiner classes. As I’ve been going over class relationships more and more I have come to realise that instance methods like trip actually connect my instances from each class. So now my Listing and Guest classes have access to the Trip class, since both have many trips. With the initialize method in the Listing class we have passed arguments of city and type which makes sense because we would want our app to have more than one ‘type’ of listing in one city. Hence why we use :city as an attribute accessor in this class.

So now we can go over and have a look at the (joining) Trip class where each of the Kardashian sisters have made bookings at various listings. So here in my initialise method I have passed in both guest and listing as arguments so that each of my instances of a trip will have these as attributes. We can test this out in the command line by running ruby tools/console.rb to get into pry, as this is where I have inputted the seed data shown above.

Now if I wanted to check all of the instances in each of my classes I can use the self.all method on all classes, like so.

So now we can see Kourtney, Kim and Khloe taking London, Paris and Milan at various Listings. We can check their attributes by calling on the trip object with the .guest and .listing methods as they have been listed as “attribute accessors” they can literally read our trip object. The first trip we named trip1 in the seed data, where our Guest Kim takes Paris, and stays at an Apartment Listing . By calling trip1.listing we get the the listing object for the trip with the given attributes of @city and @type . Similarly for our trip2 where Khloe takes a trip Milan in an apartment listing. Again we can call trip2.guest to obtain the guest object for the trip, which just as a @name attribute .

And there we have it. We can now see that our classes are indeed related to one another!

There is a sense of accomplishment that comes with the process of being able to get a code to do what you want it to. I would say practice does make perfect here. Some of you may agree, when I say that this is a tricky concept to get your head around if you’re a complete newbie like I was.

At Flatiron school’s bootcamp, I’ve had a number of coding challenges like this Airbnb app thrown my way. I have found that being able to test your seed data is key in being able to understand what your code is doing. If you haven’t quite grasped the concepts of classes and instances yet, maybe that would be a better place to start looking into before you get to forming relationships between objects in Ruby. Hope this was an insightful read into my perspective of getting the hang of object relationships. Till next time.

Happy Coding

Sunny. P