Beginning Capstone Prep

It's a bit surreal, but I am just about to complete Launch School's Core Curriculum in software engineering. As of August 8, 2022, here's a summary of my current progress:

• Programming and Backend Development
  • ✅ RB101: Programming Foundations (Ruby)
  • ✅ RB109: Assessment (Written Exam & Live Coding Interview)
  • ✅ RB120: Object Oriented Programming (Ruby)
  • ✅ RB129: Assessment (Written Exam & Live Coding Interview)
  • ✅ RB130: Ruby Foundations: More Topics
  • ✅ RB139: Assessment (Written Exam)
  • ✅ LS170: Networking Foundations
  • ✅ LS171: Assessment (Written Exam)
  • ✅ RB175: Networked Applications (Ruby, Sinatra)
  • ✅ LS180: Database Foundations (PostgreSQL)
  • ✅ LS181: Assessment (Written Exam)
  • ✅ RB185: Database Applications (Ruby, Sinatra, PostgreSQL)
• Frontend Development
  • ✅ LS202: HTML and CSS
  • ✅ JS210: Fundamentals of JavaScript for Programmers
  • ✅ JS211: Assessment (Written Exam)
  • ✅ LS215: Computational Thinking and Problem Solving
  • ✅ LS216: Assessment (Live Coding Interview)
  • ✅ JS225: Object Oriented JavaScript
  • ✅ JS229: Assessment (Written Exam & Project-based Assessment)
  • ✅ JS230: DOM and Asynchronous Programming with JavaScript
  • JS239: Assessment (Written Exam & Project-based Assessment)

As you can see above, I have completed all courses through JS230, which leaves only JS239 to complete the Core Curriculum. JS239 is comprised of two assessments — one written and one project-based — for which I'll begin preparing this week. Launch School assessments are tough, and you have to get 90% or higher in order to pass them. At Launch School there is no such thing as 'good enough'; you have to master the material, and only then can you progress to the next course.

You might be wondering what comes next, once I complete the Core Curriculum. Launch School has a finishing program called Capstone, and I'll be joining the Winter '23 cohort in January.

With that virtual nod from Launch School's founder, Chris, I officially enrolled in Launch School's Core Curriculum for software development. I had just finished the free prep course and was ready to embark on the next phase of the journey that Launch School calls the slow path for studious learners.

It was October 2020, and I was ready.

And more importantly, I was ready to set out on the path to becoming a software engineer. Excited and motivated, I was starting this new journey with as much energy and focus as I've ever had.

But then something happened. About two weeks into the first course, and just as I was about to complete the second to last lesson, I needed to devote a significant amount of mental energy and bandwidth to dealing with some personal family issues. As a result, the time and energy needed to focus on my studies with Launch School quickly dwindled, and by December, I had more or less put my studies on the back burner.

For the time being the road to becoming a software developer was put on hold, and as far as I knew it was put on hold indefinitely.

The Road to Software Engineering

For the previous decade I had been (and still am) a residential real estate broker, helping people buy and sell real estate all over the metropolitan area where I live. For most of that time I’ve also been the broker, meaning that I operate under my own license and firm. In more pedestrian terms, it simply means that I'm the boss— which, of course, is not quite as glamorous as it sounds, as I also own every other job title that goes with operating a business like this. If there’s a task to be done, in most cases I'm the one doing it.

For the most part helping people buy and sell real estate has been a solid career. It’s provided a good income while giving me the opportunity to run my own business, and much of the work involves guiding people through what is often one of the most stressful and financially significant events of their lives. Being able to help people navigate such a momentous time in their lives can be incredibly rewarding, especially when it involves donning the dual roles of successful negotiator and quasi-therapist, as the job often requires calming the nerves of clients who typically buy or sell a home only a few times over the course of their entire lives.

And yet for all of the benefits my career in real estate had provided, something had always been missing.

For as long as I can remember I've consistently loved doing two things— building stuff and solving problems. While my role as a real estate broker requires a fair amount of creative problem solving — negotiating deals and working through the inevitable challenges that real estate transactions bring — it tends to be the same problems requiring the same solutions over and over again. Don't get me wrong; meeting people, building relationships with them and helping them achieve a goal with so much at stake is a great way to spend a career. But solving the same problems over and over again can leave a mind that needs to be constantly challenged living in a perpetual state of dissatisfaction and longing for that next 'interesting' thing.

To put it bluntly, I was often bored with the core tasks involved with performing my job. Couple that with consistently working nights and weekends (often unpredictably) and the constant need to find new clients (which I've never liked), and you've got a recipe for an unfulfilling career. As a result, I was feeling as though I had hit a plateau and started to seriously think about whether or not there might be a viable path to making a near mid-life career change.

A path to a career in software engineering almost seemed inevitable. I've always had a deep interest in technology, even from childhood, whether obsessing over my first Nintendo gaming system or entering a command on an Apple IIe for the first time. A perpetual tinkerer, I was always fascinated by the underlying mechanics of how things worked.

Like many people, I had assumed that a career in software engineering started with a 4-year degree in a related field; and that if you didn't start there, you missed your chance unless you wanted to enroll in a program to get that degree. For me, I had studied philosophy and classical languages and literature, and by the time I had gotten curious about a career in software engineering, enrolling in a university program again did not sound appealing at all.

So what, then, does one do?

A few years back I had met a software engineer named Jeff. We were actually co-workers when I took a short gig as the Director of Sales for a real estate tech startup. Unlike the other engineers, Jeff didn't have any experience as a software engineer before joining the team; he didn't even have a degree in a related field. What he did have, though, was a certificate from a software engineering bootcamp.

Until then I had never heard of such a thing— an intensive program where within just a few months you could ostensibly learn what you need to know to start a career as a software engineer. It was an interesting datapoint at the time, and just that — a datapoint — as I wasn't quite ready then to broach the idea of switching my career into a different industry, to a position completely unrelated to anything I had ever done before. But the idea would stick with me— an idea that I would revisit again a few years later.

By early to mid 2020, I was ready to make that change I had been thinking about, even itching for. Remembering my former colleague, Jeff, who had leveraged a bootcamp to start a career as a software engineer, I started researching everything I could about bootcamps— course offerings, program duration, tuition, job outcomes, online reviews... literally everything I could get my hands on.

It was really enticing— the idea that I could invest just a few months to completely take my career into a new direction. But was it really possible, becoming a software engineer in just a few months time? Every bootcamp certainly said I could, with most waving around self-published reports showing statistics of 80-90% job placement within 6 months to a year of completing their programs. There was also a lot of polished marketing promising the prize of a new job in tech, while brandishing the logos of all the companies their graduates were working at.

It all sounded promising on paper. But as I continued to research the idea of attending a bootcamp to make a career change, and as I even started to narrow down potential choices, I never had a feeling of complete confidence that a bootcamp would be the right choice for me. While I attended several consultations and Q&A events with different bootcamps, I never left feeling like my questions were adequately answered or that even attending their bootcamp would be the right choice for me. And for all of the fancy marketing, for all the promises of how just a few months of study was all I needed to become a software engineer, and for all the self-reported "statistics" for job placement, none of it ever closed the "trust gap" for me. And if I couldn't totally trust a bootcamp with my future career, I certainly wasn't going to commit a sizable portion of my future salary to them either.

Discovering Launch School

I really wrestled with whether or not to attend a bootcamp. I badly wanted to get into software engineering, but the allure of bootcamp promises reeked just a bit too much of snake oil for my taste. And that cloud of distrust made me a bit nervous to take the bootcamp plunge.

Then one day it happened— some random person, in some random Twitter discussion about software engineering bootcamps, told some other random person that they should check out Launch School.

"Launch School...?" I thought.

I had never heard of Launch School, even though I felt like I had researched bootcamps to the high heavens and knew all the viable options out there. Still heavily in the research phase of things, off to Google I went...

Whoa...

One of the first things that stands out after a quick visit to Launch School's website: while you can digest what a bootcamp has to offer in about 20 minutes or less of perusing its website, it takes at least a few hours to fully digest everything at Launch School's website and really understand all it has to offer, from program goals, to its mastery-based approach to pedagogy, to what it really takes to launch a career in software engineering, to outcomes, etc. And while dense and lengthy (especially reading it's approach to mastery-based learning), having so much information available about the program was a massive breath of fresh air. What I really wanted was information, because how can one make a critical decision without sufficient information upon which to make that decision?

With bootcamps, I felt like the only thing I had to base a career-changing decision on was mostly lots of marketing material and self-reported outcomes that were fuzzy at best or deceptive at worst if you really studied the reports. There were student reviews at places like Course Report, but if you look closely, a large portion of those reviews are from current students early in their programs, not ones who actually finished and got a job they were happy with. But with Launch School, I felt it really laid everything out on the table. There was just so much information available to anyone willing to invest the time to review it— its informative website, lots of student-written articles on Launch School's excellent Medium publication, interviews with current and former students on its podcast, and, of course, a plethora of glowing reviews on Course Report . With so much information available, especially from students past and present, I felt I had enough information to make a truly informed decision.

Obviously traditional bootcamps work for some people — probably even a lot of people, depending on what your goals and expectations are. But for me, making a decision to attend a bootcamp felt more like a leap of faith than a calculated decision. And that bar just isn't high enough when there's a career and tens of thousands of dollars in educational costs on the line. By contrast, decisions of this nature need to be very, very calculated.

In short, Launch School closed the "trust gap" for me, which no other program was able to do. Nearly devoid of any marketing fluff, the approach wasn't to get as many students through the door as possible. Rather, Launch School presented itself as the right solution only if my goals aligned with the goals of the program— mastery over awareness, fundamental engineering principles over the trending framework of the moment, launching a career over just getting a job, taking the slow and studious path as the means to better long-term career prospects. It all really resonated with me, as I've never been one to take the shortest route if an exponentially better route lay ahead, even if that route were a little bit longer. In fact, it didn't just resonate with me; it was all leading to a very calculated decision based on the plethora of information available to prospective students, from the mastery-based pedagogy, to student articles and interviews, to the industry-leading salaries coming out of its Capstone program. Plus, at just $199/mo (at the time of writing) and no commitment for the Core Curriculum, there was virtually no risk.

So in September 2020, I started Launch School's free prep course.

Rediscovering Focus through Launch School

I finished Launch School's prep course mid-October 2020, and promptly enrolled in its Core Curriculum the same day. That effort swiftly died around December 2020 for the reasons mentioned above, and the next time I would invest serious time and effort into Launch School's program would be mid-July 2021.

And I am so glad I found my way back.

Ramping up and getting fully into the swing of studying again took about 6 weeks. Because I had taken about 7 months off, I had to go back and review everything I had learned before— a bit of a drag but a necessary step in getting back on track. Launch School is about mastery after all, not just getting by. In fact, there is no such thing as good enough at Launch School; you can't even move from one course to the next without passing one or two assessments per course with very high scores. Even when you do pass with high scores, you are still asked to go back and refine answers that while technically acceptable could still benefit from improvement.

By early September I had hit a stride of serious daily study and was once again making real progress. By the third week of September I had completed the first course, RB101, and by October 7th (my birthday!) I had passed the written assessment for that same course. Two weeks later I would pass the interview assessment, culminating in the completion and passing of my first Launch School course.

It felt amazing.

Learning software engineering is tough; we all know that. But the depth through which Launch School's curriculum takes you is especially difficult. Coupled with Launch School's very high standards, where conceptual fuzziness isn't allowed and the standard for excellence is mastery, passing assessments is a monumental achievement even for the best of us. This is especially true when you invest so much time and effort into not just knowing but mastering the course material. Best of all, because of Launch School's strict, high standards, when you pass an assessment you can rest assured that you truly have mastered the material at a high level.

At the time of writing, I am just on the verge of taking the assessment for my third Launch School course (there are 12 courses total in the Core Curriculum— 22 if you count the assessments). And what a ride it's been. Learning the course material, studying for the assessments and then subsequently passing the assessments has been one of the most rigorous academic experiences I've ever had; and this is coming from someone who studied philosophy and Greek and Latin in both college and graduate school. Some of that challenge no doubt comes from learning difficult material I've never studied before, but it also comes from the rigor of the Launch School curriculum and the high standards imposed on students for moving through the coursework.

As difficult and challenging as this path has been so far, I have a deep gratitude for it all. Even though the Core Curriculum is self-paced, with no live classroom instruction and no cohorts (the opposite is true of the Capstone program, of which the Core Curriculum is a prerequisite), I've been immersed in an amazing community of studious, focused learners, where the pursuit of mastery is a given, not an afterthought. And that feeling of mastery, coupled with the endpoint of the excellent career outcomes Launch School is known for, has given me a level of focus and excitement for my career I can't say I've ever had until now.

Without Launch School, I probably wouldn't be on this path to a new career in software engineering. Even with the plethora of bootcamps out there, it seems likely that I would never have felt confident enough to go down that route, with the high cost, the inability to leave once you start and the lack of confidence about the outcome once I finished. Especially with the significantly lower average salaries compared to Launch School's Capstone program, enrolling in a traditional bootcamp was even less appealing.

So thank you, Launch School, for helping me regain focus and excitement for my career, and for giving me what is likely the only viable opportunity I would have had to make the career change I so badly wanted... and probably even needed.

Onward and upward....

Inheritance in object oriented programming is a concept that refers to the ability of classes to inherit behaviors from other classes. It is not, however, a two-way inheritance. In other words, one class, a subclass, inherits behaviors from another class, a superclass; the superclass does not inherit behaviors from the subclass.

In Ruby there are two types of inheritance: class inheritance and interface inheritance. Both are equally important and together widen our ability to give functionality to objects while adding the benefits of simplicity, flexibility and scalability to our code.

Class Inheritance

Class inheritance is created when common behaviors (methods) are extracted to a superclass from which one or more subclasses inherit those behaviors. This means that an object of the subclass can invoke methods that are defined in the superclass without the method needing to be defined in the subclass. We can think of a superclass as a library of methods that, when inherited, extends the functionality of the subclass; in other words, a subclass has not only the functionality defined within itself but the functionality of its superclass as well. The syntax to indicate class inheritance is simple: when defining a class we use the < character after the class name, followed by the name of the superclass.

For example, let's say we have a restaurant where we want to define an Employee superclass with multiple subclasses of different types of employees. Here is how we would indicate that a class Host is a subclass of the superclass Employee:

class Employee
  def clock_in
    "I clocked in!"
  end
end

class Host < Employee; end

To see how inheritance is implemented in the code above, we can simply invoke the clocked_in method from the Employee class on an object of the Host class.

class Employee
  def clock_in
    "I clocked in!"
  end
end

class Host < Employee; end

host = Host.new

puts host.clock_in
# => "I clocked in!"

To further demonstrate the implementation and benefits of inheritance we can add some complexity to our example.

class Employee
  def clock_in
    "I clocked in!"
  end

  def clock_out
    "I clocked out!"
  end
end

class Host < Employee; end

class Server < Employee; end

class Busser < Employee; end

class Cook < Employee; end

host = Host.new
puts host.clock_in
# => "I clocked in!"
puts host.clock_out
# => "I clocked out!"

server = Server.new
puts server.clock_in
# => "I clocked in!"
puts server.clock_out
# => "I clocked out!"

busser = Busser.new
puts busser.clock_in
# => "I clocked in!"
puts busser.clock_out
# => "I clocked out!"

cook = Cook.new
puts cook.clock_in
# => "I clocked in!"
puts cook.clock_out
# => "I clocked out!"

As mentioned previously, inheritance allows us to extract common behaviors to a single superclass. This means that we can write code once and then reuse that same code in as many subclasses as needed, all without having to rewrite the same code over and over again. We see this in the above code with the clock_in and clock_out methods from the Employee superclass: we've defined the methods once and can invoke them from any of the subclasses we've defined after it. Without inheritance we would have to define the clock_in and clock_out methods in every class where those behaviors are needed.

Additionally, with inheritance we can still define more fine-tuned behaviors in a subclass that may not be applicable to all subclasses of the superclass from which the subclass inherits. To further elaborate on our example above, while every employee has the ability to clock in and clock out when starting and ending a shift, each employee also has behaviors specific to the employee’s role. For example, while a server can serve guests, a host cannot.

class Employee
  def clock_in
    "I clocked in!"
  end

  def clock_out
    "I clocked out!"
  end
end

class Host < Employee
  def seat_guest
    "Guest has been seated."
  end
end

class Server < Employee
  def serve_guest
    "Guest has been served."
  end
end

class Busser < Employee
  def bus_table
    "Table has been cleared."
  end
end

class Cook < Employee
  def cook_dish
    "Dish has been cooked."
  end
end

Structuring code in classes that inherit behaviors from a common superclass enables great flexibility in the code we write. With such flexibility we can easily reuse the common behaviors that we’ve extracted into superclasses while still defining more specific behaviors in subclasses where needed. For example, we can define as many subclasses of the Employee class as needed — executives, managers, marketers, dishwashers and so on — without having to rewrite and repeat any of the behaviors inherited from the Employee superclass.

But what if we have common behaviors shared between multiple but not all subclasses? For example, let’s say that servers are able to perform the same functions that a host does— taking down the guest’s name, seating the guest and giving the guest a menu. Does this mean that we need to define all of these behaviors in both classes? Or is there a way to extract those behaviors to common, inheritable location as well?

The second type of inheritance — interface inheritance — allows us to do just that.

Interface Inheritance

Before we dive into a discussion of interface inheritance, let’s continue our thought experiment with our make-believe restaurant. To do so, let’s postulate that an object of a Server class is able to perform many of the same functions as an object of the Host class, specifically functions related to seating a guest. For example, both hosts and servers are able to take down a guest's name, seat the guest at a table, give the guest a menu and inform the guest of the daily special when the guest is seated. However, because these are not behaviors that are shared among all subclasses of the Employee superclass, we do not want these behaviors to be defined in that class and then inherited by subclasses for whom those behaviors would not be appropriate (like cooks and bussers).

Let’s modify our code to give our Host and Server classes these new behaviors.

class Employee
  def clock_in
    "I clocked in!"
  end

  def clock_out
    "I clocked out!"
  end
end

class Host < Employee
  def take_guest_name
    # implementation
  end

  def seat_guest
    # implementation
  end

  def give_guest_menu
    # implementation
  end

  def recite_daily_special
    # implementation
  end
end

class Server < Employee
  def take_guest_name
    # implementation
  end

  def seat_guest
    # implementation
  end

  def give_guest_menu
    # implementation
  end

  def recite_daily_special
    # implementation
  end

  def serve_guest
    "Guest has been served."
  end
end

class Busser < Employee
  def bus_table
    "Table has been cleared."
  end
end

class Cook < Employee
  def cook_dish
    "Dish has been cooked."
  end
end

That’s a lot of repetitive code, which leads us to ask: is there a way to extract that code to a common location, from which the Host and Server classes can inherit those behaviors in the way we did with class inheritance from the Employee class? Interface inheritance enables us to do just that. The difference though is that, rather than inheriting the behaviors from a superclass, these behaviors can be inherited from a module.

A module is similar to a class in that it is a collection of related behaviors; however, a key difference is that an object cannot be instantiated from a module. While a class provides a blueprint for the state and behaviors of objects instantiated from the class, a module simply adds functionality to a class where that module has been included. As a collection of behaviors, a module can be “mixed in" to a class by invoking the include method, followed by the name of the module. When a module is used this way it is called, appropriately, a mixin module. Modules are defined like classes except by using the module keyword instead.

Let’s go back to our example above and extract the methods common to both the Host and Server classes to a module called Hostable ^[1].

module Hostable
  def take_guest_name
    # implementation
    puts 'Guest name taken...'
  end

  def seat_guest
    # implementation
    puts 'Guest seated...'
  end

  def give_guest_menu
    # implementation
    puts 'Menu given to guest...'
  end

  def recite_daily_special
    # implementation
    puts 'Daily special recited...'
  end
end

class Employee
  def clock_in
    "I clocked in!"
  end

  def clock_out
    "I clocked out!"
  end
end

class Host < Employee
  include Hostable
end

class Server < Employee
  include Hostable

  def serve_guest
    "Guest has been served."
  end
end

class Busser < Employee
  def bus_table
    "Table has been cleared."
  end
end

class Cook < Employee
  def cook_dish
    "Dish has been cooked."
  end
end

host = Host.new
host.seat_guest
# => 'Guest seated...'

server = Server.new
server.seat_guest
# => 'Guest seated...'

As you can see in our example above, we’ve deduplicated all of the functionality related to seating a guest and extracted it to a single module named Hostable . We then gave access to that functionality in our Host and Server classes by mixing in the Hostable module via invocation of the include method. In fact, we can include as many modules as may be appropriate for the class in question. For example, let's say that both hosts and servers, but not bussers and cooks, can sing a birthday song when a guest visits the restaurant on her birthday. Rather than writing a sing_birthday_song method in both the Host and Server classes, we can define that method in a Singable module and then include that module in the two classes, just as we did with the Hostable module.

module Hostable
  # code omitted for brevity
end

module Singable
  def sing_birthday_song
    # implementation
  end
end

class Employee
  def clock_in
    "I clocked in!"
  end

  def clock_out
    "I clocked out!"
  end
end

class Host < Employee
  include Hostable
  include Singable
end

class Server < Employee
  include Hostable
  include Singable

  def serve_guest
    "Guest has been served."
  end
end

Structuring inheritance through modules gives Ruby classes the ability to inherit from multiple places. While some programming languages have multiple inheritance, which means that a subclass can inherit from more than one superclass, Ruby is strictly a single inheritance language. However, through the use of modules and interface inheritance, Ruby can mimic multiple inheritance.

Class Inheritance vs. Interface Inheritance

So far we have seen both class and interface inheritance in practical examples, but it may not yet be clear as to when one might use one or the other to structure behaviors and the classes that inherit them.

You’ll recall from earlier in our discussion that inheritance is about grouping common behaviors into a single place from which multiple classes can inherit these behaviors, with that single place being either a superclass or a module. In both cases, the goal is to group common behaviors that can be defined once and then reused as many times as needed without duplicating code unnecessarily. Yet we want to group behaviors in such a way that the behaviors being inherited are appropriate to the classes that inherit them. In doing so, we can write code that is more flexible, highly scalable and much easier to maintain.

In general, if there is a ‘is-a’ relationship between classes, class inheritance is typically the best place to start. Class inheritance allows us to structure classes and behaviors into logical hierarchies, often in a way that models the hierarchies we see in the real world. Referring back to the examples we used previously, a host ‘is a’ employee, as is a server, a busser and a cook. And, naturally, as members of a more general class of Employee , there will be behaviors that each of them have in common, such as clocking in and out at the start and end of a shift.

However, there are often exceptions to this sort of hierarchical modeling such that there may be behaviors that some subclasses have in common but not all. We saw this with the Host and Server classes, which were both able to perform the functions of a host (i.e., seating guests). Since such behaviors are common only to them and not the other subclasses of the Employee superclass, we should not define these behaviors in the Employee class, since this would result in subclasses (like bussers and cooks) inheriting behaviors which would not be appropriate for them to have.

The alternative of course is to define these methods in the individual subclasses that need them; but that’s not a very good alternative, as our code becomes unnecessarily repetitive. This is where interface inheritance through mixin modules comes in. When common behaviors don’t necessarily fit into the hierarchical models we’ve created through subclassing, and there is a ‘has-a’ relationship between these behaviors and the classes that need them, then interface inheritance would typically be the better choice in such a case. This is exactly what we saw with the Host and Server classes and the Hostable module, where the behaviors didn't fit into the Employee superclass, and both the Host and Server classes "had” the behaviors in the Hostable module.

Chain of Inheritance and the Method Lookup Path

Even though Ruby is a language of single inheritance, where a class can have only one superclass, it is the case that a class also inherits the behaviors that its superclass inherits. That’s a bit of a mouthful, but it simply means that there is always a chain of inheritance involved when subclassing one class from another. Like water running from the top to the bottom of a chain, the water (behaviors) runs through any links (classes) in the chain that are created through subclassing additional classes until it reaches the last link in the sequence.

For our restaurant thought experiment we created an Employee superclass with a number of employee type subclasses. To demonstrate this chain of inheritance, we're now going to define a Person superclass from which the Employee class subclasses. Additionally, we will also create a class Guest , which also subclasses from the Person class, in addition to Adult and Child classes that subclass from Guest .

class Person
  attr_reader :name

  def initialize(name)
    @name = name
  end
end

# classes related to a Guest
class Guest < Person; end

class Adult < Guest; end

class Child < Guest; end

# classes related to an Employee
class Employee < Person; end

class Host < Employee; end

class Server < Employee; end

class Busser < Employee; end

class Cook < Employee; end

To make it easier to see, let’s extract the structure we’ve created between our classes.

Person < Guest < Adult
Person < Guest < Child
Person < Employee < Host
Person < Employee < Server
Person < Employee < Busser
Person < Employee < Cook

With this structure in place, the final subclasses in the chain we’ve created inherit behaviors that are defined at the top of the chain as well as any classes in between. For example, the Host class inherits the behaviors in the Person class because these behaviors are inherited in the Employee class, and the Host class inherits behaviors from the Employee class.

To see this chain of inheritance in practice we’ll create an object from the Adult class and then invoke the name method that's defined in the Person class.

class Person
  attr_reader :name

  def initialize(name)
    @name = name
  end
end

# classes related to a Guest
class Guest < Person; end

class Adult < Guest; end

class Child < Guest; end

# classes related to an Employee
class Employee < Person; end

class Host < Employee; end

class Server < Employee; end

class Busser < Employee; end

class Cook < Employee; end

adult = Adult.new('Nancy')
puts adult.name
# => 'Nancy'

As we saw in our discussion of class inheritance, we are able to invoke the name method that's defined in the Person class on an object of the Adult class, even though the name method is defined in neither the Adult class nor in the Guest class. This, again, is inheritance at work.

To illustrate the chain of inheritance further, consider the commonly used object_id method. This method can be invoked on any Ruby object, even though this method isn't defined in any of the classes of the objects upon which we commonly invoke this method (e.g., strings, integers and arrays). This is because the object_id method is an instance method of the Object class, and all Ruby objects ultimately inherit from the Object class in the chain of inheritance.

For example, if we were to invoke the object_id method on an object of the Cook class, the chain of inheritance would look like this:

Object < Person < Employee < Cook

In Ruby there is a specific mechanism underlying this chain of inheritance called the method lookup path. This is the means by which Ruby locates a method definition in order to execute a method invocation of the same name. In more pedestrian terms, this is the answer to the question: how does Ruby know where to find the definition of a method when it's invoked? We can think of the method lookup path exactly as the name implies: the path that Ruby takes through the chain of inheritance to find a method definition for an invoked method.

For any method invocation, the general sequence that Ruby follows to find a matching method definition looks like this:

Class (of the object upon which the method was invoked)
  ↓
Module(s)
  ↓
Superclass
  ↓
[repeat w/the Superclass now in the beginning position taken by Class]

As you can see in the outline above, Ruby first looks in the class of the object upon which the method was invoked. If Ruby doesn’t find a matching method definition there, Ruby then looks in included modules, if any. If there are two or more modules included in the class, Ruby looks in the most recently included module first (which would be the last included module), then works its way backwards through any remaining modules. If a method definition still hasn’t been found, Ruby then looks in the class’s superclass, repeating the same cycle as many times as necessary. Once Ruby has exhausted all custom classes and modules without finding a matching method definition, then Ruby continues through the following classes and modules:

Object
  ↓
Kernel (module in the Object class)
  ↓
BasicObject

If Ruby is unable to find a matching method definition anywhere in the method lookup path, a NoMethodError is raised.

To see the method lookup path in practice, let’s consider the following code.

module Hostable
  def take_guest_name
    # implementation
    puts 'Guest name taken...'
  end

  def seat_guest
    # implementation
    puts 'Guest seated...'
  end

  def give_guest_menu
    # implementation
    puts 'Menu given to guest...'
  end

  def recite_daily_special
    # implementation
    puts 'Daily special recited...'
  end
end

module Singable
  def sing_birthday_song
    # implementation
  end
end

class Person
  attr_reader :name

  def initialize(name)
    @name = name
  end
end

class Employee < Person
  def clock_in
    "I clocked in!"
  end

  def clock_out
    "I clocked out!"
  end
end

class Host < Employee
  include Hostable
  include Singable
end

class Server < Employee
  include Hostable
  include Singable

  def serve_guest
    "Guest has been served."
  end
end

class Busser < Employee
  def bus_table
    "Table has been cleared."
  end
end

class Cook < Employee
  def cook_dish
    "Dish has been cooked."
  end
end

host = Host.new('Dave')
host.seat_guest
# => 'Guest seated...'

server = Server.new('Betsy')
server.name
# => 'Betsy'

In the above example we have created two objects, one of the Host class and one of the Server class. On our host object we have invoked the seat_guest method.

Upon invocation of the seat_guest method on host , here’s the method lookup path that Ruby uses to locate the matching method definition.

Host
  ↓
Singable
  ↓
Hostable

[seat_guest method definition found in Hostable module]

Had a seat_guest method not been found, Ruby would have exhausted the entire method lookup path before raising a NoMethodError.

Host
  ↓
Singable
  ↓
Hostable
  ↓
Employee
  ↓
Person
  ↓
Object
  ↓
Kernel
  ↓
BasicObject
  ↓
[NoMethodError]

Conclusion

To summarize, inheritance refers to the ability of one class to inherit the behaviors of another class, which allows us to extract common code to a single inheritable location. Because Ruby is a single inheritance language, which means that a class can only subclass from a single superclass, Ruby has two types of inheritance: class inheritance and interface inheritance. While class inheritance allows us to create hierarchical relationships between classes, it doesn’t always make sense for certain behaviors that are shared between only some subclasses to be inherited from the superclass. As a result, interface inheritance through mixin modules gives us the ability to mimic multiple inheritance. To execute a method invocation, Ruby uses the method lookup path to find the matching method definition.

—

Encapsulation in object oriented programming is the grouping of data into objects while making that data unavailable to other parts of a codebase. It's one of the fundamental conceptual pillars of object oriented programming (along with abstraction, polymorphism and inheritance).

More simply, encapsulation is akin to placing information into a bucket, closing the lid and then hiding that information from the curious and prying eyes of others. Within the context of object oriented programming, the data we're hiding is the attributes that an object has (which together comprise the state of the object) and the functionality (behaviors) of which the object is capable. Therefore, to say that we have encapsulated data is to say that we have hidden the state and behaviors of an object from the rest of the codebase. To say that we are hiding data is to say that we are making that data inaccessible from the rest of the program, which also protects that data from unintentional manipulation.

In this article I discuss what exactly encapsulation looks like, how methods are used to encapsulate data or expose it to the rest of a codebase, and how exactly encapsulation benefits our ability to design complex programs.

The Hidden Nature of Objects

Ruby uses instance variables to track the values associated with an object’s attributes. For example, we may have a Dog class whose objects have the following attributes: name, weight and age. To track these attributes, our Dog class has instance variables of the same name: @name , @weight and @age . Together, these three instance variables comprise the state of objects instantiated from the Dog class.

Let’s consider the following example:

class Dog
  def initialize(name, weight, age)
    @name = name
    @weight = weight
    @age = age
  end
end

spot = Dog.new('Spot', 12, 4)
p spot
# => #<Dog:0x000000010d85f198 @name="Spot", @weight=12, @age=4>

Here we have initialized a local variable spot to a new object of the Dog class. The state of this object is represented by the instance variables that we have initialized in lines 3-5 , which tell us that the @name of this object is ‘Spot’, that it has a @weight of ‘12' (lbs) and that its @age is ‘4’. Invoking p on line 10 returns a human readable representation of the object spot: the class name of our object, an encoding of the object id and, most importantly for this discussion, all of the instance variables that have been initialized within that object along with their values.

At their most basic level, objects are distinct entities that are separate and independent of each other. We could also say that the internal representation of objects is hidden from each other, where one object is unable to access information about the other. Practically, this means that we cannot interact with an object unless we explicitly expose the state and behaviors of that object to other parts of our code. Ruby uses methods to expose the state of an object, but without these methods an object remains what is essentially an information silo, closed off and isolated from the rest of the world (or, rather, code). With these methods, we can retrieve and manipulate the data within an object.

To use the example above, our dog spot has a number of attributes. However, with the code as currently written there is no way to access them from the rest of the program. To demonstrate this we can attempt to reference one of the instance variables from outside of the class Dog where the instance variable was initialized.

class Dog
  def initialize(name, weight, age)
    @name = name
    @weight = weight
    @age = age
  end
end

spot = Dog.new('Spot', 12, 4)
p spot
# => #<Dog:0x000000010d85f198 @name="Spot", @weight=12, @age=4>

p @name
# => nil

As we saw before, we’ve initialized the @name instance variable in line 3, to which we've assigned the value ’Spot’ . We also confirmed that the instance variables have been initialized when we invoked p on line 10 , which returned the instance variables and their values along with other information about our object spot . Yet when we attempt to reference the variable in line 13, nil is returned.

There’s a good chance this result isn’t surprising to you, but it might not be surprising for the reason you think.

The reason nil is returned when directly referencing the @name instance variable outside of the Dog class is because instance variables are encapsulated in the object where they were initialized. As you recall from the beginning of our discussion, when data is encapsulated it is hidden — that is to say, inaccessible — from other parts of our codebase. For instance variables, they are hidden by default unless we deliberately create a way to access their values. To expose an object's instance variables — to take them out of hiding, so to speak — we have to define methods that allow us to access the instance variable's value outside of the object.

Using Methods to Open Objects to the Rest of the World

Instance variables are scoped at the object level, meaning that an instance variable exists only within the object where it was initialized. Therefore, to gain access to the values assigned to an object’s instance variables we have to consider the object as the gateway to access them.

To access these values, we need to define instance methods that expose them to other parts of our code. When an object's instance variables are exposed we can retrieve the values assigned to them, or we can manipulate those values altogether. When we don't have methods that expose them, they remain locked and hidden within the object.

Let’s define instance methods that allow us to retrieve and manipulate the value assigned to one of our instance variables; such methods are called getter and setter methods, respectively. For this example, we’ll use the @name instance variable.

class Dog
  # previous code omitted for brevity

  def name
    @name
  end

  def name=(new_name)
    @name = new_name
  end
end

spot = Dog.new('Spot', 12, 4)

p spot.name
# => 'Spot'

spot.name = 'Daisy'

p spot.name
# => 'Daisy'

On lines 4-6 we've defined our getter method name . When we invoke the name method on line 13, it simply returns the value assigned to the @name instance variable. Likewise, on lines 8-10 we've defined our setter method name=() , which reassigns the @name instance variable to the string passed as an argument to the name=() method.

And voilà, we are now able to access the value assigned to @name from outside of the class where it was initialized. With both getter and setter methods in place, we can now both retrieve and reassign the value assigned to @name .

You’ll notice, of course, that the name and name=() instance methods are invoked on our Dog object spot. This is because instance methods can only be invoked on objects of the class where those methods are defined. As mentioned previously, if we want to access information about the state of an object, we have to consider the object as the gateway to that information. If we were to invoke, for example, the name method apart from spot , an error would be raised.

class Dog
  # previous code omitted for brevity

  def name
    @name
  end

  def name=(new_name)
    @name = new_name
  end
end

spot = Dog.new('Spot', 12, 4)

name
# => undefined local variable or method `name' for main:Object (NameError)

Controlling How Objects are Exposed with Method Access Control

Encapsulation allows a programmer to have fine tuned control over what data is hidden within an object and what data is exposed to other parts of a program. Think of it like peeling back the layers of an onion: rather than exposing the entirety of the inner onion, I can peel back as many or as few layers as I want, revealing only as much of the onion as is necessary.

Any discussion of encapsulation necessarily entails a discussion of how exactly Ruby accomplishes the encapsulation of data. Like many other programming languages, Ruby uses the concept of access control to restrict and open access to the methods that allow one to retrieve and manipulate data within an object. Within the context of Ruby, we call this mechanism method access control.

Method access control uses access modifiers to control access to methods. In Ruby, access modifiers are public, private and the less commonly used protected. Public methods are available outside of the class where they are defined, meaning that they can be invoked anywhere without restriction. In Ruby, methods are public unless explicitly declared to be private or protected. In our code example above where we defined getter and setter methods for the @name instance variable, these are public methods since we did not declare them to be otherwise. We also saw this in practice when we successfully invoked the name and name=() methods from outside of the Dog class.

Private methods, on the other hand, can only be invoked from within the class itself. It is also the case that private methods cannot have a caller, because they are implicitly invoked on self .^[1]

Let’s look at an example of how to declare a method to be private, as well as the implications of doing so.

class Dog
  # previous code omitted for brevity

  def name=(new_name)
    @name = new_name
  end

  private  # methods defined after this are private methods

  def name
    @name
  end
end

spot = Dog.new('Spot', 12, 4)

p spot.name
# => private method `name' called for #<Dog:0x0000000123136608 @name="Spot", @weight=12, @age=4> (NoMethodError)

To declare a method as a private method, we simply include the private method invocation, followed by any method definitions we intend to be private. In the above code, we have taken the name getter method and moved it below the private method invocation. And the result? As we see here, invoking a private method from outside the class raises a NoMethodError as well as an indication that the method we have tried to call is a private method. While Ruby typically raises a NoMethodError when it doesn’t find a method in the calling object's lookup path, in this case it raises the error not because the method doesn't exist but because making the method private has blocked access to it.

As stated previously, private methods can only be invoked from within the class where the method is defined. Now that we’ve declared the name method as a private method, here’s an example of how we can call it without raising an error.

class Dog
  # previous code omitted for brevity

  def speak
    "My name is #{name}!"
  end

  private

  def name
    @name
  end
end

spot = Dog.new('Spot', 12, 4)

p spot.speak
# => 'My name is Spot!'

In line 5 we've interpolated the name method within a new method definition, speak , with the resulting output on line 18. Whereas we could not invoke the private name method from outside of the class, this demonstrates that private methods can be invoked by other instance methods of the same class. It also demonstrates how we can encapsulate methods, since private methods are accessible only within the class itself and are protected from invocation outside of the class.

Protected methods lie between public and private methods. Like private methods, they can only be invoked from within the class where they are defined. However, unlike private methods they can be invoked on a calling object other than self , so long as the calling object is an instance of the same class. Protected methods aren't commonly used, but one common use case is when comparing objects of the same class.

class Dog
  def initialize(name, weight, age)
    @name = name
    @weight = weight
    @age = age
  end

  def <(other)
    weight < other.weight
  end

  protected

  def weight
    @weight
  end
end

spot = Dog.new('Spot', 12, 4)
daisy = Dog.new('Daisy', 25, 12)

puts spot < daisy
# => true

puts spot.weight
# => protected method `weight' called for #<Dog:0x00000001260c1710 @name="Spot", @weight=12, @age=4> (NoMethodError)

In the above example we’ve declared weight as a protected method. This allows us to protect the weight method from being accessed outside of the Dog class, while also allowing us to compare the weight of objects of the Dog class as defined in the < method on lines 8-10 . Like private methods, protected methods can only be invoked from within the class, but unlike private methods they can be invoked on both self and other objects of the same class.

The Practical Benefits of Encapsulating Data in Objects

Learning object oriented programming for the first time can be very challenging. Not only is it a major conceptual shift in how we think about programming, but it can be difficult to translate object oriented programming on a conceptual level to how it benefits the code we write on a practical level. This is true as well of understanding encapsulation and how it is implemented in Ruby.

Encapsulating data into objects has two chief benefits:

1. It protects data from unintentional manipulation. In other words, in order to change data within an object there must be obvious intention behind doing so. It also means that we can restrict the way in which data is manipulated.
2. It allows us to hide complex operations while leaving a simple public interface to interact with those more complex operations.

Let’s illustrate these benefits with an example.

class Person
  attr_accessor :car

  def initialize(name)
    @name = name
    @car = nil
  end
end

class Car
  attr_reader :make, :model, :year, :engine_status

  def initialize(make, model, year)
    @make = make
    @model = model
    @year = year
    @engine_status = :off
  end

  def start_engine
    switch_ignition
    start_relay
    start_motor
    puts "Engine is #{engine_status}!"
  end

  private

  attr_writer :engine_status

  def switch_ignition
    # implementation
    puts 'Starting ignition...'
  end

  def start_relay
    # implementation
    puts 'Starting relay...'
  end

  def start_motor
    # implementation
    puts 'Starting motor...'
    self.engine_status = :on
  end
end

joe = Person.new('Joe')
joe.car = Car.new('Chevy', 'Impala', 1958)

joe.car.start_engine
# => 'Starting ignition...'
# => 'Starting relay...'
# => 'Starting motor...'
# => 'Engine is on!'

puts joe.car.engine_status
# => 'on'

joe.car.engine_status = :off
# => private method `engine_status=' called for #<Car:0x0000000147948bd8 @make="Chevy", @model="Impala", @year=1958, @engine_status=:on> (NoMethodError)

The above code illustrates a simple but key point: in order to start the car, the object joe doesn’t need to know the implementation details of every method involved in starting the engine, or even that those methods exist. More specifically, objects of the Person class do not need to access the switch_ignition , start_relay and start_motor methods, which are all necessary steps in starting an engine. Rather, the only method that objects of the Person class need to know about is the start_engine method; all other implementation details that follow from this method can remain hidden and inaccessible.

And that is encapsulation in practice. We've packaged all of the complex details involved in starting an engine, have made them inaccessible outside of the Car class and instead have defined a simple public interface — the start_engine method — to handle all of the underlying complexity. In fact, this models the real world implementation of starting a car: one doesn’t need to know the internal mechanics of how exactly a car engine starts. Instead, a person only needs to know how to turn the ignition with a key. The rest of the implementation happens under the hood and out of sight; in other words, it is encapsulated.

Notice as well that while we have defined a public getter method for the @engine_status instance variable in line 11, we have made its setter method in line 27 private. While we may want the status of the engine to be publicly accessible (for example, a mobile app is able to check if the engine is running), we want only the internal implementation of the object’s class to be able to reassign it, which protects it from the possibility of being directly changed from outside the class. In practical terms, we don't want an object other than a Car to be able to modify @engine_status. Rather, we want it to be changed only as a result of the internal implementation that begins with the public start_engine method and ends with the private start_motor method. In other words, we want the value of @engine_status to reflect the actual status of the engine, while also preventing arbitrary changes that don't. Using method access control to structure our methods this way ensures that @engine_status is manipulated with clear intention and only in the specific way we've designed it to be changed in our program.

Conclusion

In summary, encapsulation allows a programmer to group data into objects and then hide that data from the rest of the codebase. Likewise, it also allows a programmer to expose only data that needs to be accessed outside of the class. By encapsulating data, we can prevent arbitrary changes to data, and we can also hide complex operations while providing a simple public interface to interact with them.