Introduction to classes: 18. Inheritance exercise


#1

Hello,I am not able to understand , why in the code for the class Equilateral triangle ,after defining the variable
angle (which is supposed to be global ,here ) , we are initializing the attributes as self.angle1 = self.angle ,etc. in the init method ? I mean,since the angle variable is global ,why do we have to go with self, and self.angle1 = self.angle makes no sense at all in language too....Could you please explain this to me.

My link to my code is as below:
https://www.codecademy.com/en/courses/python-intermediate-en-WL8e4/3/4?curriculum_id=4f89dab3d788890003000096

class Equilateral(Triangle):
    """A triangle with all angles equal to 60 degrees, and thus, all sides equal."""
    angle = 60
    def __init__(self):
        self.angle1 = self.angle
        self.angle2 = self.angle
        self.angle3 = self.angle

Need help understanding the purpose behind Overriding
#2

The only reason i can think of is so you can call check_angles method


#4

angle is not really global. It is a class variable accessible only through the class directly, or through an instance. angle1, etc. are instance variables of the super class, and are overwritten in this class. @stetim94 makes a good point, as these are the angles expected in the check_angles method which is inherited by this class.


#5

but wouldn't it more effective to overwrite __init__() with pass:

class Equilateral(Triangle):
    """A triangle with all angles equal to 60 degrees, and thus, all sides equal."""
    angle = 60
    def __init__(self):
        pass

and then overwrite check_angles as well? Personally, it feels more like explaining of things then that its an actual logic design choice for a program, which is a missed opportunity.


#6

I think @appylpye will agree with you on that point. Given that the angle is fixed and equal for all vertices, and declared in the class, it seems pointless to have a check_angles method. However, it wouldn't preclude any other methods that may be in the super class such as area, perimeter, and any methods for finding unknowns. Personally, I am not versed enough to make an argument in any case. Glenn would have more insight.


#7

In my opinion, the Triangle class and any subclasses derived from it should present to the user an interface that enables the values of any of its angles to be queried individually, even if the angles are all equal, or if two of them are equal. There are a number of ways that this could be done, but it seems that the simplest scheme is for all Triangles and child classes to have angle1, angle2, and angle3 instance variables. However, strictly speaking, the internal design of the classes is not what is paramount. The primary issue is that any instance of Triangle or a derived class should present the appearance of having three individual angles, regardless of how the classes are implemented.

Let's consider a hypothetical guessing game in which a list of triangles is randomly generated and the player has to guess each of the angles of each triangle. Some of the items in the list are Triangles, while others are Equilaterals, and others are instances of Isosceles, which has not been defined in the Codecademy exercises. It would be most convenient for the programmer of the game to be able to query each angle individually, regardless of the class of the instance, so long as it is a Triangle or a class derived from it. Perhaps the game enables the user to guess the first angle, in a loop, and when that one is guessed correctly, have another loop for guessing the second angle.

In summary, we should design groups of types so that when the objects they represent share a commonality, such as three angles in the case of a triangle, we are able to treat, programmatically, instances of the parent class and all derived class similarly with regard to those commonalities.


#8

A post was split to a new topic: 18. inheritance


#9