Need help understanding the purpose behind Overriding


#1

Hey guys!

I just reached the object oriented programming section of the python course, and have been having a hard time understanding with every chapter i complete. I feel like some of my solutions are just mindless applying of the instructions i'm given without ever fully understanding what it's all about, and that made me stop and reconsider what i'm doing. You can't call it coding if you're not even sure of what you're actually writing.

So it is with a confused mind that i ask of you guys to shed some light upon Overriding for me, and explain -in details, please- what is the purpose behind it and how it works. Some examples would be appreciated.

Same thing goes for bit manipulation, i've gone through its section without any difficulty, but i'm still unsure about the reason why would someone choose to manipulate data in bits instead of just using 'normal' code.

Thank you


#2

That is why the gradual approach is superior to brute force learning. These track courses are introductory, and will not coders make of us. It will only reveal our aptitude for coding.

At first, that is what it takes. Follow instructions and work toward desired finished result. There is no test at the end of this. However, if one's aptitude proves out as favorable for learning programming then it puts us in a better position to begin digging deeper into each new concept, starting with a review of the completed units.

As a learner we must set our pride aside and accept that we are naive. Our logical minds are still forming and we will naturally reach for the solutions we understand before ones we do not. That is fine, and there is no fault in it. The concepts of time and space complexity should not come into question when we are beginning to learn code. It's more important that we can reason out algorithms that solve our problem so we can grow our logical brain gradually. Much of what we learn off the top will draw criticism from a more advanced learner.

For an understanding of overriding, I recommend search for posts by @appylpye on the topic. He posted something on this only a few weeks ago that was particularly excellent and easy to grasp. Any explanation I could offer would pale in comparison.

A short time ago the quesion was raised about where would we use bit manipulation, and likewise my answer was not very good, but it does shed some light on the topic.

I'll see if I can dig up the two topics mentioned above.


Here is one on bitwise operations.

https://discuss.codecademy.com/t/bitwise-operation-use-cases/125060

Still trying to find the one on override.


#3

Thank you for your answer concerning bit manipulation. It was a bit too advanced and hard for me to understand, but it did the job and gave a general idea about its uses.

Still waiting for the answer concerning overriding. If you find anything, don't hesitate to share, i'd take anything if it means getting over this impasse with some understanding of what i actually wrote.

Thank you again


#4

From a generalized point of view, consider we have a parent class (super) and a child class (sub). The child class inherits from the parent class. The purpose of override is to permit a subclass to have its own methods that supercede any of the same name inherited from the super class. There is a vice versa, as well, where a particular circumstance requires the super class method over the subclass method. This is covered in the exercise on full time employee and part time employee.

Hopefully I can find that post mentioned earlier. Still haven't found it.


#5

Thank you for your answer, but it's still not as clear as i'd liked it to be. The question that's causing me the most trouble is "why would someone want to override a parent class's method instead of creating a method that does the same thing for the subclass?"
I don't think the usefulness behind overriding is economizing code lines, since you'll be retyping everything anyway (that's what we're shown in the course anyway), and i can't think of any other reason.


#6

Still lacking in a clear way to explain this. Glenn does such a good job.

Take for instance a square and a rectangle. They both use the same area calculation, length times width, and the same perimeter calculation (2 * (l + w)). However, we can change up this calculation for a square since we only need one dimension to find the area or perimeter. The square subclass could inherit other properties and methods from a rectangle class but override the area and perimeter methods to take advantage of the single variable equation in favor of the two variable one.


#7

And would that be different from creating two new methods for the square subclass, instead of overriding the existent one inside the rectangle parent class?

I'm sorry if i'm being annoying with all this thickheadedness (it's really demoralizing for me), but i really want to understand and would be infinity grateful to you if you helped get through this, as you're the only one willing to answer this question for me atm.

Thank you again.


#8

class Rectangle(object):
    vertice_angle = 90
    number_of_sides = 4
    sum_of_interior_angles = 360
    def __init__(self, length, width):
        self.length = length
        self.width = width
    def area(self):
        return self.length * self.width
    def perimeter(self):
        return 2 * (self.length + self.width)

class Square(Rectangle):
    def __init__(self, width):
        self.width = width
    def area(self):
        return self.width ** 2
    def perimeter(self):
        return self.width * 4

Not a very good example but it builds upon what was previously mentioned. Note that Square instances inherit all the class variables of Rectangle, but overrides the __init__, area and perimeter methods.


#9

Ohhhhh, i think everything just clicked in place. A square is, after all, just a peculiar case of a rectangle with all his sides being equal.
Which means that asking the user to state the square's sides measurements would be pointless upon creating an instance of the square object.
Hence the overriding, so that it would ask for only one parameter instead of two.

It's ironic how an example you thought to be not good enough turned out to be the key for me to understand all of this.

I still have some uncertainty about the subject, like why not just create two new methods to calculate the area and perimeter instead of overriding the parent class', but it's a huge improvement compared to a few minutes earlier, and i have you to thank for that.


#10

See Introduction to classes: 18. Inheritance exercise.

The concept presented here is known as polymorphism. This refers to the practice of handling particular aspects or processing of objects differently based on their type. We can achieve this by overriding methods within derived classes. The point of defining a new class that inherits from a parent class is that the new class will have much in common with the parent class. For the commonalities, we provide and utilize inherited methods and class variables.

We have various choices concerning how to handle the differences between a child class and its parent class. One choice could be to define entirely new methods, with new names, to handle the differences, leaving the original methods intact. However, we only want to do this in cases where the original version of a particular method is still relevant to the derived class, and where we anticipate using the original method on a regular basis for instances of the derived class.

One major convenience associated with polymorphism, wherein we override a method, is that we can write code that anticipates the creation of derived classes, and that is ready to handle them. For example, if we have a program that draws shapes, we can define a parent Shape class, and define a draw method within it. We then derive lots of child classes for different shapes that all inherit from the Shape class directly or indirectly. For each descendant class, we can create a draw method that overrides the original. This overriding, as opposed to defining a drawing method with a different name, provides us with the convenience of always being able to rely on calling the draw method to draw any shape, regardless of how many different classes we have derived from Shape, and no matter how many new classes we may define in the future that derive from Shape. It is something akin using an existing standard plug design when we invent a new appliance, so that we can rely on a standard outlet to power it that was designed long before the appliance was invented, or even anticipated. The plug, like the name of the draw method for Shape descendants, is the same for all appliances. We rely on each type of appliance to perform its own special magic when we power it on; we rely on each type of Shape descendant to know how to display its glory when we call its draw method.


#11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.