When You Have An Itch, Scratch It

Throughout the learning process, every student will have concepts she or he does not feel comfortable with, but usually can get by without fully understanding. This common circumstance is one place where a mastery-based learning departs from traditional learning.

In the moment, its hard to tell where you are with your newly acquired knowledge. Should you feel solid about it? Will more clarity come if you keep going? In general, you feel fuzzy about the concept. Dealing with it is mildly uncomfortable, and in fact, annoying like an itch on your foot while wearing socks and shoes. If you find yourself here and aiming for mastery-based learning, scratch that “itch”! Go explore the concept. Read other sources. Write about your confusion. Talk with others. Try to make sense of it.

Our stumbling points are unique to each of us. As a student at Launch School, I struggled with the usage of self when programming in Ruby. Actually, I blogged about it once before in a post called Self vs @: its a decision, not a rule — I was confused about when to use self and when to use @ to access instance variables. Writing about my confusion the first time definitely helped sort things out, but the “itch” came back. Check out why and what I concluded from taking a closer look below:

Issue #1
Encapsulation is the concept of hiding functionality to avoid code dependencies. This idea is the backbone of OOP. Because I wanted to err on the side of caution, I was using @ whenever possible in order to keep my code inaccessible in what I hoped was the OOP fashion. However, it did not feel quite right; it was not congruent with the code written by other students and the code displayed in exercise solutions.

Realization #1
Taking a step back, we can see there is another programming concept for which using @var might cause problems: DRY (“Don’t Repeat Yourself”). It’s one thing to use @var to reference the value as is, but say one day, you realize you need to transform the value stored in the @var in order to make the instance variable usable by your program in new way. You would then need to make the revision to every reference of the instance variable. Ideally, you would be able to make this transformation in one place. For this reason, it seems like a good idea to anticipate needing to make this type of update at some point, and therefore, use a private accessor method until you have to write your own getter and setter methods to add that custom code.

Issue #2
Somewhere along the self vs @ journey, I realized I was also confused about when to make instance methods private and when to leave them as public. The obvious situation here is not too difficult to understand. Say you are working with confidential information such as social security numbers; it is reasonable to expect, in this case, certain instance methods and instance variables should be inaccessible to the rest of the program, at least partially so. What I could not understand, however, was why I was seeing private methods in exercises which did not even pretend to deal with sensitive information.

Realization #2
To see the reason, we have to zoom out again and consider the concept of encapsulation I mentioned earlier. Any methods being used by other methods within the class and not being accessed otherwise can be placed below the private keyword; these methods are what do the work “under the hood”. A car — that’s a perfect metaphor: you don’t need to ‘access’ the specific knowledge of how the engine works in order to drive a car, right? Methods are not dissimilar: other developers do not need access to the supporting methods in order to use my code.

Overall, I think my continued confusion in regard to self really stemmed from the concept of accessibility in OOP. On the one hand, instance variables are private by default. If need be, one can make these variables public with accessor methods. On the other hand, instance methods are public by default (with the exception of the initialize method). If need be, one can make these methods private by placing them below the private keyword. These related, but differing cases nagged at me until it became an “itch” I could not ignore any longer.

Pay attention! Notice what your “itches” are and address them — it will help you form good habits for mastery-based learning.