3 Essential OOP Concepts To Know For Your Technical Interview
A few months back while I was job hunting I interviewed with a software consulting firm which specialized in Java/C#, both very powerful object-oriented programming (OOP) languages. One of the first questions they asked me during the interview was about the three “pillars” of OOP. Although maybe this firmed asked me about my OOP knowledge because they worked with OOP heavy languages, I think it is important for everyone to be well versed in what OOP’s main ideas are. Not only will it be helpful for interviews, but it will make your development process more efficient(if you do it properly).
I was initially quite phased by the interviewer’s question. What in the heck are “pillars”? One thing that was drilled into my mind when I learned OOP in school was the concept of Inheritance. Actually, I was able to regain my memory of the other “pillars” because of this. Inheritance is the pillar that accentuates the principle of reusing code in OOP design. The idea of Inheritance is to write code for one behavior once, and simply extend that code for similar behavior later on in the development process. I have a habit of explaining programming concepts with examples, which is what I did in the interview. I used this example:
Let’s say you’re being contracted to build employee management software for a fast-food franchise. The employees at this franchise consists of cashier, cook, janitor, and manager. You have to write some code to store data about each type of employee such as their name, birthday, location, but also some type-specific data such as the number of burgers flipped for the cook, the number of hours at the cashier for the cashier, the number of mops broken for the janitor, and whether the manager has a certification in management. One clever thing you can do to reduce the amount of code you have to rewrite for this process, is to write the code for a generic employee which stores data about their name, birthday, location. Then, if you’re using a language which supports OOP, you simply extend the generic employee code, and add onto it any type-specific code to support the type-specific data we have to store. This practice is called inheritance, since you are making the type-specific code inherit from the generic employee code.
The second pillar of OOP is Encapsulation. Personally, understanding this concept allowed me to connect physical objects to the abstract objects in OOP. One idea which you need to understand is that objects have instances. Instances are representations of an object which initially share the same properties, specified by the object, with other instances. However, as you perform operations on an instance, its instance properties change and its values for its properties become different from other instances. An instance of a car that is blue is different from an instance of a car that is yellow. Understanding this concept is important in grasping the idea of Encapsulation. Actually, we just went over what Encapsulation is! When we perform an operation on an object, say, make a car instance’s paint color from blue to red, that operation will only affect that car instance. All other cars are separate from this operation, because their paint colors are encapsulated within the instance. Programmatically, encapsulation also prevents name pollution.
The last “pillar” of OOP is Polymorphism. Personally I think this is the most abstract pillar. Let’s make it less abstract with an example. Let’s say you’re building a car wash. Your car wash supports all kinds of cars, but not all carrs are the same! Your car wash implicitly washes all the cars the same way because you can assume that all cars have a property. Programmatically, let’s say you have a Data object that has an isEmpty() method. You have other objects that inherits from this object such as BigData and SmallData. Since they inherit from Data, you can implicitly call isEmpty() when you create an instance of either object.