Concerning Separation of Concerns for Object Oriented Programming
(Note: I was not able to hide my API key with dotenv as I would have liked. I have come to the conclusion that in the early days of macOS Big Sur, dotenv is not yet compatible.)
I built my first CLI program from scratch with Ruby. It allows users to enter any city in the U.S. and get a list of hotels related to that query. Upon seeing the list, the user can choose one of the hotels and receive the latitude and longitude of that hotel. I used an API as opposed to scraping a website. The API I used was the free Hotels.com API from RapidAPI.com.
The first thing I realized when writing my own program from the ground up is how intoxicating the possibilities can be. Even for a simple CLI application pulling from a single and straightforward API, the divergent options are nearly endless. My recommendation to anyone starting their first CLI application would be to take a minimalist approach: the absolute dumbest, most straightforward, and ‘hacky-est’ method you can think of. One could say I followed the K.I.S.S. Principle (Keep It Simple, Stupid). If I had attempted to implement all the advanced topics covered thus far in bootcamp, I would have undoubtedly had a difficult time getting started. My current belief is it is much easier to refactor a working application than produce an elegant solution right away. A caveat: what I suggest here is the advice FROM a novice programmer FOR a novice programmer. My gut tells me that with more experience, one’s initial attempt when compared to their final product will be more similar than those of a novice.
Once you have a working application, if resources allow, refactoring should be considered. In my view there are three factors to examine when making these decisions: Readability, efficiency at scale, and time. Readability refers to the ease with which other programmers can understand what you have written. Efficiency is in regards to use of computational resources. Time simply points to the question of whether it is worth it to spend the time to refactor something that is already working. Much of this will be decided by what your organization prioritizes. Do they prefer maintainability and quality or quantity and output? The most important of these three while enrolled at The Flatiron School would be time. Given that I did have extra time before submitting my CLI project, I decided to improve the readability of my code and file structure.
First I separated my code by concern into different files, classes, modules, and methods. Of course, there is some convention to rely on in terms of a template for file structure, but there is a lot to be decided upon as well. Do not stress too much over this, files can be easily rearranged, just do not forget to change the file path in your environment!
Next, I realized that my code was not DRY (Don’t Repeat Yourself). Essentially, I was guilty of copying and pasting certain blocks of code multiple times. This is an obvious candidate for making a new method or a new module if the code is used across different classes.
Another easy refactor is naming. This is especially important in Ruby where the logic of code reads almost like an english sentence. ‘array = [hotel1, hotel2, hotel3]’ will work, but ‘array_of_hotels = [hotel1, hotel2, hotel3]’ is far more intuitive, specific, and easy to grasp when looking back over your code or having someone else read your code for the first time.
The last example concerns classes in OO and assigning their attributes. What I learned from constructing my hotel app is it is easiest to think in terms of the real world when assigning attributes. This will not always apply, but it will get you pretty far. In the case of my hotel class, I thought about what attributes a physical hotel has and which of those are pertinent to my program. A hotel has a name, coordinates, a city in which it exists, rooms, guests, employees, an age, and many other attributes. What was needed for my program was simply the name, coordinates and city.
Some may ask why I kept information relating the hotel and city classes within the hotel class. This was done to keep a single source of truth. By convention, in a ‘has many’ ‘belongs to’ relationship, the SSOT should lie in the ‘belongs to’ category. In other words, the hotels should keep track of what city they are in rather than the city keeping track of all the hotels it has.
