If you work in the Tech sphere long enough you come to hear the phrase Object-Oriented Programming or OOP, quite often. Especially so if you are newer to the programming world and you are interviewing for your first job as a developer, you might get asked the question, "What are the 4 major principles of OOP?". If you are here you probably don't know what they are and you are hoping to find out, if you do know and you're still here, well maybe you can get a refresher or point out my mistakes if there are any in how I define what OOP and its 4 major principles are, though there are more than 4 principles, we will only go over the major 4.
Defining OOP
Now Wikipedia defines OOP as “ a programming paradigm based on the concept of “objects”, which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods.” Now for me personally being given this "textbook-like" definition gets me more confused, so I try and simplify its definition like this. Object Oriented Programming is one of many different ways to create structure behind how you write or organize your code into more readable and reusable forms. These forms that you organize your code into are known as objects, thus the name Object oriented programming.
Things you need to know
So before we go into the actual major principles of OOP, you need to know how to define a few things: Objects, Classes, Methods, Instances.
Object: Are simply an instance of a class.
Class: A model of what you want your objects to do.
Method: Simply a function, the way you modify state or properties of your class.
Instance: Instances are better described with an example. In a manufacturing company, when they create their product in bulk, they often use a blueprint. These blueprints can be seen as objects of a class. But once that product is created, it's not an object any more but because it becomes something physical or tangible it becomes an instance of that object, thus the name Instance.
The 4 Major Principles
Encapsulation
Encapsulation, is probably the easiest of the major principles to understand, and in my eyes it's mostly used to hid or restrict access of classes. For example, say you have a class of Users, now these users will probably have multiple methods and a bulk of sensitive data that you don't want just anyone to access or retrieve. If you don't encapsulate your User, class, any class you make will have access to the methods and data store in your User class and thats a no no. So encapsulation is used to protect classes from each other and requires you to use getter or setter methods in order to access or use the protected class. Now how do you use encapsulation? There are usually keywords in your language that similar or are Private/Public, etc. Private classes are usually the encapsulated/protected classes, that need special setter/getter methods in order to access them.
Abstraction
Abstraction is basically an extension of encapsulation. Abstraction is the practice of hiding how an object works. For example, when you are using your phone or something and you want to access an app, you simply touch that app, the app opens up, the pictures you want to see load, your status updates, etc. Basically a lot of things happen with one click. Abstraction is used to basically hide all functionality and only show the user the simple easy clicks. Thus organizing and cleaning up how code works.
Inheritance
Next is inheritance, so this leads into the concept of having one object you create, having children to other objects. So when one object meets another object and they really like each other... Just kidding. So think of it like this say you are a car dealership, you probably have a ton of cars, but they are all the same make or model of the car. So how would you create this kind of relationship with code. Simply you use the parent/child relationship with inheritance. So you would have a car object(the parent) and since all cars have similar features like all cars will have a make/model/etc. You create separate but similar classes for each make, so a Ford class, Porsche Class, etc. Now if you created this classes just individually without inheritance, you can see the problem of having multiple classes having repetitive data and thats wasted space and time. So instead you use inheritance and the Ford/Porsche class would become children of the Car class, and through that you can allow repetitive data to be inherited, rather than repeating code. So if the Car class has a specific method, all of the children of the Car class(Ford/Porsche) will have those methods as well.
Polymorphism
Now inheritance has some problems, that are addressed with polymorphism. So polymorphism is used on children class, in order to customize methods inherited from the parent and adjust them to work uniquely for that child. This is done either by using something called method overloading or method overriding. So let's use a different example for this. Say we have a Shape class, and 3 different children classes square, circle, triangle. Now we give the shape class a method called calculateArea. The 3 children now have the same calculate area method, but look at this problem, the formulas for area in a square, circle, and triangle are all different. This is where you can use method overriding to change what the calculateArea method does for a square, circle, and triangle so that the formulas match the shape. Overloading is when you have multiple methods in a class with the same name, but with different number of parameters.
Conclusion
Welp these were kinda messy, but hopefully simplified and good definitions of the 4 major OOP principles. There are more principles such as Association, Aggregation, Composition, and such, but if you're only worried about getting starting or more beginner tech jobs you probably wont be asked about these principles. Though you might come across questions about other types of programming structures like functional or procedural and how they differ or compare to OOP and that might be my next blog topic, if y'all want. Just leave a like and I'll take that as a sign to write about that.
Top comments (0)