In today's episode, you'll learn the four principles of object-oriented programming. We'll discuss abstraction, inheritance, encapsulation, and polymorphism. By the end of the show, you'll understand each one of them; you'll know how they relate to each other, and how to use them in practice.
Transcript
Episode 14 - The Four Principles of OOP
00:00:02 - 00:05:01
welcome to the programming podcast. Here you can learn about computers in the brief and accessible way. I'm your host mean could get lower today in the programming podcast. We are going to cover the four core principles of the object oriented programming. So why object oriented programming. I know that recently O. P. orchestrated programming in short have had pretty bad fame. A lot of people are criticizing object oriented programming because of how it is used in a couple of languages so a lot of people consider. It's very verbose overcomplicated and the problem programs developed with objects rangers programming over engineered. It doesn't have to be that way. Both object oriented programming and functional programming. They have their pros and cons. Functional programming offense has fewer concepts. Soldiers makes it easier to learn also in purely functional languages we have immutable did structures and all the different functions that operate over these immutable structures. Which are pretty much unchangeable. So we don't have state mutation are pure so it is very predictable to know what's actually happening on the other side with object oriented programming quicken very conveniently create different abstractions and often people consider it much more intuitive to think about because we are used to thinking about the world around us as different objects. Which are instances of certain classes for example we see three and well we think about this. Three as an instance of the class three. This is actually very common to the philosophy which was introduced by plotto many many years ago in Asian Greece where he sold out. We had this world of shapes and what we see on the ground are just different. Instances what we see. Our world are just different. Instances different imperfect instances of these shapes and yeah dishes can be considered as clauses and individual instances that we see around us their individual objects in our programs now since we know that both functional programming in object oriented programming can have their protocols and object oriented. Programming can be extremely powerful paradigm to us in our day to day development process. Eld want to introduce to the four main principles of all opie their abstraction encapsulation inheritance and pornography them. We're going to cover it in particularly in this order because introducing obstructions I is to help us to get to understand the other three principles easier. General obstruction is probably the main reason why we are able to create so complicated software systems because nobody can actually fit an entire platform as cassettes. A Google search or google drive google photos. Nobody can do that in their brain without ignoring some of the implementation details in general the software that we right. It's extremely complicated and we as humans. We cannot keep that many things in our head at the same time so that's why we're using obstruction very often. We destruction we're capturing quality essential properties only the essence of the entities depth modeling and ignoring everything else. That isn't great because it helps us to think about pure things and from their own. We can just combine these abstracted pieces together into more complicated entities and from there ignore some of their implementation details as well. There is a very powerful design pattern called sate which exactly aims to do that. It just provides a very high level interface or API to a more complicated network of objects which communicate together and since we are not interested in this entire API that is the union of the interfaces of all of these tiny objects. We're all interested on a subset of and interactions between these objects. We can very easily abstract us and treated for seats on top. We just shows us a very small of what is actually going on under hoot. So with abstraction we're just hiding some non essential properties of entities. That were very often. We are more than Inc. objects or entities from the real world of very common example is to modal person. Often we just represent a person in our program as a class which has birthdates and a name and this is completely enough in other cases.
00:05:01 - 00:10:02
Ill if you're building a platform for medical services. We may want to in cold for things. For example we may want to introduce some medical history of this person who turns out to be a patience and in these cases we can just like extent shrink or just show a subset of the properties that a particular entity has now. Let's talk about encapsulation. Encapsulation often refers to different things. I hiding some implementation details in class and second just bundling together methods and data the methods that are operating on top of some particular piece of data. We usually bundled them together in class. So just by creating a class which is well coherent. If you're not sure what coherences. You can go back to one of the previous where discussing cohesion and coupling in object oriented programming. So by during this abstraction this class which groups together some data and methods that operate on those data creating some level of encapsulation and on top of that. We don't have to expose all these methods. As part of the public interface of the class. We can just provide a subset of them. The ones which are not essential for customers of this Class D can be hidden often object oriented languages they provide different visibility modifiers for example public private protected so by using those visibility modifiers. You can't hide some methods and some proper key. Some data of these clauses that is not essential for their consumers for example if we would want to have on obstruction of type person we can have the birth date of this person and we can market this private because the user might be interested only in the age of the person so we can have a method. Gold Get H. Who can keep the birthday private? And we can just calculate the birth. H where the person without exposing any application details. The next principle that we're going to discuss today is inheritance is probably the most controversial one. Because inheritance in object oriented programming is primarily used for coulter us and creating an abstraction which is reusable inheritance could be very tricky usually in order to make sense for a certain class to Harry's from another they need to be in an is a relationship for example human is a mammal so a Human Kenny. Herod from Mammal. But this could be quite tricky in a lot of cases so inherited it creates a very strong coupling between the parents and the Child Klaus. They cannot function independently at all and all the data defined in the parent class exists in the child classes. Well there is a very famous quote. That is better to have called duplication than wrong abstraction and. This is so much true very often when you have a ranking abstraction and when you have created a certain base class only in order to be able to reuse some piece of logic defiance of it you create very own maintainable system which is hard to follow hard to track. It's not obvious that a certain class is in a relationship with its parent and it gets even more tricky when you try to hear it from this certain based class many times because this obstruction get's trickier and trickier and guess. Guess more leaky overtime. Let me give you a very simple example. You mentioned. We have e-class Colt rectangle and we also have a close. Kohl square so it kind of makes sense for the Square Harry's from tango right because it is kind of a rectangle juice it's two sides are equal now in the rectangle. We have two methods called said wits and set heights these methods. They don't make much sense in the square because there we have only a single site. We don't have written height so we have two different ways to proceed but probably the most popular one would be just to set both the width and the height of our square to the same sites to the value. Once the user invoked invokes its medicine set. Britain said height. But now imagine we have a collection of tangles. We have many rectangles rate and we want to loop over all of them and extent. There are surface area with ten percent. So what we can do is just calculate that we can extend their wheat with certain percentage so that we can achieve the satisfying area extension as well so far so good.
00:10:02 - 00:13:50
We'RE GOING TO LOOP OVER. Djuric tangos one of now. He's going to turn out to be a square because we're operating base classes but since queer inherits from Rick Tango well. It's absolutely valid for a square to be in this collection as well. There's actually related to the next principle that we're going to discuss polymorphism. So we're going to set the wit of our rectangles and everything has to work as we expect to work but since one of rectangles is a square. We're going to set both. Its with its high to the same value which is going to lead to a book in our program since we're going to increase the area with a bigger percentage that the one we were expecting so here how simple and very obvious inheritance chain can turn out to be problematic so we should be very cautious when using he heritages and the last principal that we're going to discuss. Today is calpoly morphism. We kind of only indirectly mentioned that in our previous example where we had a collection of rectangles and one of these rectangles was actually the square. We're just completely possible. We can have on. The ray of rectangles and took him push square inside of this array if our square misleadingly Heritz from rectangle. That's what we can have different behavior of the methods a certain object depending on to which child clause they're actually bounce to. Here's a simple example. We have an interface or an abstract class cooled render. And we have different implementations of this render looking half on implementation for let's see html five canvas implementation for the Dome and we can have on implementation for a server side surrender which renders everything into a string. So these different implementations they can exist in the same array of type render because they're implementing the interface or they're from the base kloss render whilst performing cranberry though and we invoke render box or render container or however. We want to call the individual methods in our abstraction once methods. We're going to get into the exact instance that implements this method and evoke the correct logic depending on what kind of child class we're currently operating over. This is quite flexible and powerful. Thanks to pull him or visit them. We can implement different behavioral. Depending depending on what circumstances we're operating in polymorphism is essential for many design Potter's previously. We discussed the pattern decorator. Which takes advantage of morphism a lot as well as you probably remember in the decorator pattern where he hearing from a Cohen Obstruction and the decorator. Rops uneasy since a certain class. Let's say are you. I wish it. And since the decorator and of this child's clauses we have wrapped in the decorator the are inherited from the same class. We can use them interchangeably so we can use the child class at the same place where we have used the decorated child class. So that's pretty much all of it. I'm going to apply links for further reference where he can learn more about obstruction encapsulation inheritance and polymorphism. Thank you very much for listening