Object-Oriented Programming (OOP)

Software Engineering

(for Intelligent Distributed Systems)

A.Y. 2024/2025

Giovanni Ciatto

Compiled on: 2025-06-30 — printable version

back

Many programming paradigms

(cf. https://en.wikipedia.org/wiki/Programming_paradigm)

• Imperative programming: programs are made by instructions that change the state of the program.
• Procedural programming: programs are made by blocks of code that can be reused.
• Functional programming: programs are made by functions that transform data.
• Logic programming: programs are made by rules that define relationships between data.
• Object-oriented programming: programs are made by objects that interact with each other.

Why object-oriented programming?

(cf. https://en.wikipedia.org/wiki/Object-oriented_programming)

• By far the most used programming paradigm nowadays, both in industry and academia
• Fundamental for understanding modern programming languages, and their libraries
• Most commonly, the design phase of SE involves designing objects, and their behaviours, and their interactions

Three dimensions of software design

• Structure: how is the software organised (decomposed) into components? how is information encoded into data?
• Behaviour: what does each component do? how does it transform data (from input to output)?
• Interaction: how/when do the many software components communicate or cooperate to form a system?

Key principles of OOP

• Everything is an object

• A program is a bunch of objects telling each other what to do by sending messages

• Every object can have its own memory (state) composed by other objects

• Every object is an instance of a class

• Every object has an interface, which defines what messages it can receive

  • and so what the type of the object is

Key principles of OOP, in practice

• An object is a container of attributes. These can be of 3 sorts:

  • fields, i.e. variables that store object-specific data
    • (these constitute the aforementioned memory/state)
  • methods, i.e. functions that can read/write the other members of the object
    • (these constitute the aforementioned “messages that can be received” by the object)
  • properties, i.e. methods that can be accessed as if they were fields

• Classes are blueprints for objects

  • they describe what attributes an object will have
  • each member of a class defines an attribute that all objects of that class will have

• Objects are created as instances of classes

  • each class has a constructor, i.e. a magic function which creates an instance of the class
  • the constructor is in charge of initializing the object’s attributes

• Objects can use other objects, by calling their methods or accessing their fields or properties

  • (this is what the aforementioned “sending messages” is about)
  • the data stored in objects’ fields are indeed other objects
  • the methods of an object are functions which can accept as arguments, and return them as results

Example: the Light class

class Light:
    def __init__(self, initially_on: bool):
        self.state = initially_on

    @property
    def is_off(self) -> bool:
        return not self.state

    @is_off.setter
    def is_off(self, value: bool):
        self.state = not value

    def switch(self):
        self.state = not self.state

    def to_string(self) -> str:
        return f"Light(state={'on' if self.state else 'off'})"

l = Light(True)
print(l.to_string()) # Light(state=on)
l.switch()
print(l.to_string()) # Light(state=off)
l.state = True
print(l.to_string()) # Light(state=on)
l.is_off = True
print(l.to_string()) # Light(state=off)
print(l.is_off) # True

What is self?

• You can think about a class as group of functions, which all have an implicit first argument, self

  • this is a reference to the instance of the class that is being manipulated
  • it is not passed explicitly when calling the method

• Via self, you can access the other attributes of an object, from within a method of that object

  • e.g., self.state in the switch method of the Light class

• The name self is a convention, but you can use any name you want

  • but it is strongly recommended to stick to self for readability
  • the following class is equivalent to the Light class above, by simply renaming self to this:

    class Light:
        def __init__(this, initially_on: bool):
            this.state = initially_on
    
        @property
        def is_off(this) -> bool:
            return not this.state
    
        # etc.
    

• You can imagine that variable self is automatically passed to the method when it is called

  • e.g., l.switch() is equivalent to Light.switch(l)

Encapsulation and Information Hiding

What: Encapsulation

The idea of presenting a consistent interface [of an object, to its users] that is independent of its internal implementation

How: Information Hiding

A means to achieve encapsulation, by restricting/controlling access to the internal details of an object

• Commonly achieved by separating how an object is used from how it is implemented

  • e.g., by providing a public interface, and private implementation details

• Commonly involves enforcing some invariants on the object’s state

  • e.g., by ensuring that some attributes are always in a certain range…
  • … or that some attributes are always consistent with each other

Why Encapsulation Matters?

Encapsulation helps to

• protect data from accidental modification
• ensure controlled access through defined methods
• improve maintainability by allowing internal implementation changes without affecting external usage
• create modular, reusable, and scalable code

Example in real life

• a car’s accelerator pedal: you control speed without directly modifying the engine parameters

Identity and Equality

Identity

• Two objects are identical if they are the same object in memory

  • i.e., if they have the same memory address

• This is checked using the is operator

  • e.g., a is b returns True if a and b are the same object

Equality

• Two objects are equal if they have the same value

  • i.e., if their attributes are recursively equal

• This is checked using the == operator

  • yet, the operator only works if the object’s class has a __eq__ method which defines what equality means for that class

Example: Complex Numbers

class Complex:
    def __init__(self, real: float, imag: float):
        self.re = float(real)
        self.im = float(imag)

    def __eq__(self, other):
        return other is not None and hasattr(other, 're') and self.re == other.re and hasattr(other, 'im') and self.im == other.im

Usage

a = Complex(1, 2) # (1 + i * 2)
b = a
c = Complex(1, 2) # (1 + i * 2)
d = Complex(2, 1) # (2 + i * 1)

print(a is a) # True
print(a is b) # True
print(a is c) # False
print(a is d) # False

print(a == a) # True
print(a == b) # True
print(a == c) # True
print(a == d) # False

How to write good __eq__ methods

1. No object is equal to None (x == None should always return False)

   • always check if the other object is None, returning False if it is
     • this is to avoid NoneType errors

2. Check whether the other object is an instance of the same class of the current object

   • this is to avoid AttributeError errors
   • e.g., isinstance(other, CurrentClass) or type(other) == type(self) or isinstance(other, type(self))

3. Alternatively, check whether the other object has the same attributes as the current object

   • this is to avoid AttributeError errors
   • e.g., hasattr(other, 'attribute') for each attribute of the current object that you want to compare

4. Compare the attributes of the other object with the attributes of the current object

   • this is to define what equality means for the class
   • e.g., self.attribute == other.attribute for each attribute of the current object that you want to compare

Example: Sets of Complex Numbers

a = Complex(1, 2) # (1 + i * 2)
b = a
c = Complex(1, 2) # (1 + i * 2)
d = Complex(2, 1) # (2 + i * 1)

s = {a, b, c, d}
print(len(s)) # TypeError: unhashable type: 'Complex'

Hashable objects

(cf. https://www.pythonmorsels.com/what-are-hashable-objects/)

• Long and complex discussion

• Put simply, you need objects to be hashable in order for them to be used within a set or a dict

• An object is hashable if it has a __hash__ method that returns a semi-unique hash value for that object

  • a hash value is an integer that is used to quickly compare objects
  • if two objects are equal, their hash values must be the same
  • if two objects are not equal, their hash values should be different (but collisions may occur)

Rules of thumb for implementing the __hash__ method

• Always implement the __hash__ method if you implement the __eq__ method (and vice versa)
• HOWTO: pass a tuple to the hash() function, containing all and only the attributes that you compared in the __eq__ method
  • e.g., hash((self.attribute1, self.attribute2))

Example: Hashable Complex Numbers

class Complex:
    def __init__(self, real: float, imag: float):
        self.re = float(real)
        self.im = float(imag)

    def __eq__(self, other):
        return other is not None and hasattr(other, 're') and self.re == other.re and hasattr(other, 'im') and self.im == other.im

    def __hash__(self):
        return hash((self.re, self.im))

Usage

a = Complex(1, 2) # (1 + i * 2)
b = a
c = Complex(1, 2) # (1 + i * 2)
d = Complex(2, 1) # (2 + i * 1)

s = {a, b, c, d}
print(len(s)) # 2
print(s) # {<__main__.Complex object at 0x78d202e09520>, <__main__.Complex object at 0x78d202e09580>}

What’s <__main__.Complex object at 0x78d202e09520>?

Representing objects as strings

• By default, Python represents objects as <package-name.ClassName object at 0x78d202e09520>

  • this is the memory address of the object in hexadecimal notation

• Better would be to represent objects as strings that are meaningful to the user

  • e.g., Complex(1, 2) instead of <__main__.Complex object at 0x78d202e09520>

• There are two more magic methods to be implemented in Python classes, for the sake of string representation

  • __str__: returns a user-friendly string representation of the object
  • __repr__: returns a developer-friendly string representation of the object

• If __str__ is not implemented, Python will use __repr__ as a fallback

  • if __repr__ is not implemented, Python will use the default representation
    • so better to implement them both, or at least just __repr__

• __str__ is used by the print() and the str() functions, as well as in f-strings

  • e.g., print(obj) is equivalent to print(str(obj)), which is equivalent to print(obj.__str__())
  • e.g., f"{obj}" is equivalent to f"{str(obj)}", which is equivalent to f"{obj.__str__()}"

• __repr__ is used by the repr() function, as well as when the object is represented as part of a collection

  • e.g., repr(obj) is equivalent to obj.__repr__()
  • e.g., f"{obj!r}" is equivalent to f"{obj.__repr__()}"
  • e.g., print([obj1, obj2, ...]) is equivalent to print('[', obj1.__repr__(), ', ', obj2.__repr__(), ', ...]')

Repr vs. Str

Long and complex discussion, see: https://realpython.com/python-repr-vs-str

Rules of thumb

1. __repr__ should return a string that is unambiguous and complete

   • i.e., it should be possible to reconstruct the object from the string
   • e.g., Complex(1, 2) instead of <__main__.Complex object at 0x78d202e09520>

2. __str__ should return a string that is readable and informative

   • i.e., it should be meaningful to the user
   • e.g., 1 + i * 2 instead of Complex(1, 2)

Example: Presentable and Hashable Complex Numbers

class Complex:
    def __init__(self, real: float, imag: float):
        self.re = float(real)
        self.im = float(imag)

    def __eq__(self, other):
        return other is not None and hasattr(other, 're') and self.re == other.re and hasattr(other, 'im') and self.im == other.im

    def __hash__(self):
        return hash((self.re, self.im))

    def __repr__(self):
        return f"Complex({self.re}, {self.im})"
    
    def __str__(self):
        sign = '+' if self.im >= 0.0 else '-'
        im = abs(self.im)
        im = str(im) if im != 1.0 else ""
        return f"{self.re} {sign} i{im}" if self.im != 0.0 else str(self.re)

Usage

a = Complex(2, 2)
b = Complex(-1, 1)
c = Complex(1, -1)
d = Complex(-2, -2)
e = Complex(3, 0)

print(a) # 2 + i2
print(b) # -1 + i
print(c) # 1 - i
print(d) # -2 - i2
print(e) # 3

s = {a, b, c, d, e}
print(len(s)) # 5
print(s) # {Complex(-2.0, -2.0), Complex(-1.0, 1.0), Complex(1.0, -1.0), Complex(3.0, 0.0), Complex(2.0, 2.0)}

Immutable vs. Mutable Objects (pt. 1)

• Objects are immutable if their state cannot be changed after they are created

  • e.g., int, float, str, tuple, frozenset

• Objects are mutable if their state can be changed after they are created

  • e.g., list, dict, set

• Immutability is a good thing, as it makes objects easier to reason about, and safer to use

  • e.g., you can pass an immutable object to a function without worrying that it will be changed by that function

• Yet, immutability can be inconvenient in some cases

  • e.g., data needs to be updated in place, rather than replaced by a new object

Immutable vs. Mutable Objects (pt. 2)

When designing a class, you should decide whether it should be immutable or mutable design

How to achieve immutability

1. The attributes of an immutable object should be read-only

   • i.e., they should be set only in the constructor, and never changed afterwards

2. The attributes of an immutable object should be immutable themselves

   • e.g., if an attribute is a list, it should be replaced by a tuple

3. State-changing methods should apply the copy-on-write pattern

   • i.e., they should not change the object’s state, but return a new object with the updated state

Suggestions

• Make classes immutable by default, and mutable only when necessary

  • this is a good practice, as it makes the class safer to use

• Alternatively, support both mutability and immutability

  • e.g., implement methods via the copy-on-write pattern, but provide an optional parameter to activate in-place updates

Example: Immutable Complex Numbers

(cf. https://en.wikipedia.org/wiki/Complex_number)

class Complex:
    def __init__(self, real: float, imag: float):
        self.re = float(real)
        self.im = float(imag)

    def add(self, other):
        return Complex(self.re + other.re, self.im + other.im)

    def subtract(self, other):
        return Complex(self.re - other.re, self.im - other.im)

    def multiply(self, other):
        return Complex(self.re * other.re - self.im * other.im, self.re * other.im + self.im * other.re)

    def divide(self, other):
        if other.re == 0 and other.im == 0:
            raise ZeroDivisionError("Cannot divide by zero: " + str(self))
        denominator = other.re ** 2 + other.im ** 2
        return Complex((self.re * other.re + self.im * other.im) / denominator, (self.im * other.re - self.re * other.im) / denominator)

    def __eq__(self, other):
        return other is not None and hasattr(other, 're') and self.re == other.re and hasattr(other, 'im') and self.im == other.im

    def __hash__(self):
        return hash((self.re, self.im))

    def __repr__(self):
        return f"Complex({self.re}, {self.im})"
    
    def __str__(self):
        sign = '+' if self.im >= 0.0 else '-'
        im = abs(self.im)
        im = str(im) if im != 1.0 else ""
        return f"{self.re} {sign} i{im}" if self.im != 0.0 else str(self.re)

Usage

a = Complex(3, 2)
b = Complex(-1, 1)

print(a.add(b))      # 2.0 + i3.0
print(a.subtract(b)) # 4.0 + i
print(a.multiply(b)) # -5.0 + i
print(a.divide(b))   # -0.5 - i2.5

Example: Mutable Complex Numbers

class Complex:
    def __init__(self, real: float, imag: float):
        self.re = float(real)
        self.im = float(imag)

    def add(self, other):
        self.re += other.re
        self.im += other.im

    def subtract(self, other):
        self.re -= other.re
        self.im -= other.im

    def multiply(self, other):
        re = self.re * other.re - self.im * other.im
        im = self.re * other.im + self.im * other.re
        self.re, self.im = re, im

    def divide(self, other):
        if other.re == 0 and other.im == 0:
            raise ZeroDivisionError("Cannot divide by zero: " + str(self))
        denominator = other.re ** 2 + other.im ** 2
        re = (self.re * other.re + self.im * other.im) / denominator
        im = (self.im * other.re - self.re * other.im) / denominator
        self.re, self.im = re, im

    def __eq__(self, other):
        return other is not None and hasattr(other, 're') and self.re == other.re and hasattr(other, 'im') and self.im == other.im

    def __hash__(self):
        return hash((self.re, self.im))

    def __repr__(self):
        return f"Complex({self.re}, {self.im})"
    
    def __str__(self):
        sign = '+' if self.im >= 0.0 else '-'
        im = abs(self.im)
        im = str(im) if im != 1.0 else ""
        return f"{self.re} {sign} i{im}" if self.im != 0.0 else str(self.re)

(notice the lack of return statements)

Usage

a = Complex(3, 2)
b = Complex(-1, 1)

print(a.add(b))          # None
print(f'a={a}, b={b}')   # a=2.0 + i3.0, b=-1.0 + i
print(a.subtract(b))     # None
print(f'a={a}, b={b}')   # a=3.0 + i2.0, b=-1.0 + i
print(a.multiply(b))     # None
print(f'a={a}, b={b}')   # a=-5.0 + i, b=-1.0 + i
print(a.divide(b))       # None
print(f'a={a}, b={b}')   # a=3.0 + i2.0, b=-1.0 + i

(notice the lack of return values, and that b never changes while a does)

Example: Immutable-by-default Complex Numbers

class Complex:
    def __init__(self, real: float, imag: float):
        self.re = float(real)
        self.im = float(imag)

    def __update_or_create_new(self, re, im, in_place):
        if in_place:
            self.re, self.im = re, im
        else:
            return Complex(re, im)

    def add(self, other, in_place: bool = False):
        re = self.re + other.re
        im = self.im + other.im
        return self.__update_or_create_new(re, im, in_place)

    def subtract(self, other, in_place: bool = False):
        re = self.re - other.re
        im = self.im - other.im
        return self.__update_or_create_new(re, im, in_place)

    def multiply(self, other, in_place: bool = False):
        re = self.re * other.re - self.im * other.im
        im = self.re * other.im + self.im * other.re
        return self.__update_or_create_new(re, im, in_place)

    def divide(self, other, in_place: bool = False):
        if other.re == 0 and other.im == 0:
            raise ZeroDivisionError("Cannot divide by zero: " + str(self))
        denominator = other.re ** 2 + other.im ** 2
        re = (self.re * other.re + self.im * other.im) / denominator
        im = (self.im * other.re - self.re * other.im) / denominator
        return self.__update_or_create_new(re, im, in_place)

    def __eq__(self, other):
        return other is not None and hasattr(other, 're') and self.re == other.re and hasattr(other, 'im') and self.im == other.im

    def __hash__(self):
        return hash((self.re, self.im))

    def __repr__(self):
        return f"Complex({self.re}, {self.im})"
    
    def __str__(self):
        sign = '+' if self.im >= 0.0 else '-'
        im = abs(self.im)
        im = str(im) if im != 1.0 else ""
        return f"{self.re} {sign} i{im}" if self.im != 0.0 else str(self.re)

Usage

a = Complex(3, 2)
b = Complex(-1, 1)

print(a.add(b))                         # 2.0 + i3.0
print(f'a={a}, b={b}')                  # a=3.0 + i2.0, b=-1.0 + i
print(a.subtract(b, in_place=True))     # None
print(f'a={a}, b={b}')                  # a=4.0 + i, b=-1.0 + i
print(a.multiply(b))                    # -5.0 + i3.0
print(f'a={a}, b={b}')                  # a=4.0 + i, b=-1.0 + i
print(a.divide(b, in_place=True))       # None
print(f'a={a}, b={b}')                  # a=-1.5 - i2.5, b=-1.0 + i

Software Systems as Objects can interact with each other

• OOP software designer will model interactions between objects

• To do so, they will design classes that use other classes

• The “single responsibility principle” suggests that each class should have exactly one responsibility

  • so, if a class needs to interact with another class, it should delegate that responsibility to the other class

• Good design is art: designers learn how decompose a problem into smaller, more manageable sub-problems…

  • … assigning each sub-problem to a class, and orchestrating the interactions between classes

Example: The Complex Calculator

Let’s say we want to design a calculator that can compute arithmetic expressions of complex numbers

1. we design a class for representing complex numbers (done!), encapsulating the arithmetic operations’ logic
2. we design a class for representing a complex calculator (to do), encapsulating the orderly execution of expressions
   • this one should use the former but not vice versa

class ComplexCalculator:
    def __init__(self):
        self.__memory = []
    
    def __memorize(self, value):
        self.__memory.append(value)

    def clear(self):
        self.__memory.clear()

    def number(self, value: int | float | Complex):
        if not isinstance(value, Complex):
            value = Complex(value, 0)
        self.__memorize(value)
    
    def operation(self, operator: str):
        if operator not in {'+', '-', '*', '/*'}:
            raise ValueError("Invalid operator: " + operator)
        self.__memorize(operator)

    def compute_result(self) -> Complex:
        if len(self.__memory) == 0:
            raise ValueError("Nothing to compute")
        result = self.__memory[0]
        for i in range(1, len(self.__memory), 2):
            operator = self.__memory[i]
            operand = self.__memory[i + 1]
            match operator:
                case '+':
                    result = result.add(operand)
                case '-':
                    result = result.subtract(operand)
                case '*':
                    result = result.multiply(operand)
                case '/':
                    result = result.divide(operand)
        self.clear()
        self.number(result)
        return result

Usage

c = ComplexCalculator()
c.number(3)
c.operation('+')
c.number(Complex(2, 1))
print(c.compute_result()) # 5.0 + i1.0
c.operation('*')
c.number(Complex(1, 1))
print(c.compute_result()) # 4.0 + i6.0

Advanced OOP Topics

• Operator Overloading to support arithmetic and comparison operations
• Static vs. Class vs. Instance methods (vs. Module functions)
• Inheritance to support re-use and specialization of classes
• Polymorphism to support flexibility and encapsulation

Operator Overloading

• When creating your own data types (i.e. classes, in Python), you can define how they behave with arithmetic operators

  • e.g., you already did that, by defining the __eq__ method for the Complex class to support the == operator

• Redefining the behavior of an operator for a class is called operator overloading

  • e.g., you can define the + operator for the Complex class to support the addition of two complex numbers

• Notice that you cannot add new operators to the language, but just redefine the behavior of the existing operators

• Not all programming languages support operator overloading, and the ones who do it, do it with different syntaxes, yet the idea is similar

  • in Python, operator overloading is supported by magic methods to be implemented in the class definition

Beware: when reading code in a language which supports operator overloading, you should not assume that you know what an operator does, unless you know the types of the operands, and have read the documentation of those types

Operator Overloading in Python (pt. 1)

Python supports operator overloading via magic methods
(complete specification here: https://docs.python.org/3/reference/datamodel.html#special-method-names)

Operator Overloading in Python (pt. 2)

Python supports operator overloading via magic methods
(complete specification here: https://docs.python.org/3/reference/datamodel.html#special-method-names)

Example: 2D Points in Python

class Point2D:
    def __init__(self, x, y):
        self.x = float(x)
        self.y = float(y)
        
    def __str__(self):
        return f"({self.x}, {self.y})"
    
    def __repr__(self):
        return f"Point2D({self.x}, {self.y})"
    
    def __eq__(self, other):  # equality: p1 == p2
        return other is not None and all(hasattr(a, other) for a in ['x', 'y']) and self.x == other.x and self.y == other.y
    
    def __hash__(self):
        return hash((self.x, self.y))

    def __abs__(self): # magnitude: abs(p)
        return math.sqrt(self.x ** 2 + self.y ** 2)

    def __neg__(self): # negation: -p
        return Point2D(-self.x, -self.y)
    
    def __add__(self, other) -> 'Point2D': # addition: p1 + p2
        if not isinstance(other, Point2D):
            other = Point2D(other, other) # if other is a scalar, convert it to a point of equal coordinates
        return Point2D(self.x + other.x, self.y + other.y)
    
    def __sub__(self, other) -> 'Point2D': # subtraction: p1 - p2
        return self + (-other) # implemented via addition and negation
    
    def __mul__(self, other): # multiplication: p1 * p2 or p1 * s
        if isinstance(other, Point2D):
            return self.x * other.x + self.y * other.y # dot product
        return Point2D(self.x * other, self.y * other) # scalar product
    
    def __truediv__(self, other: float) -> 'Point2D': # division: p1 / s
        return self * (1 / other) # implemented via multiplication

    def distance(self, other: 'Point2D') -> float:
        return abs(self - other) # implemented via subtraction and magnitude
    
    def angle(self, other: 'Point2D') -> float:
        diff = other - self
        return math.atan2(diff.y, diff.x) # requires import math

Usage

p1 = Point2D(1, 2)
p2 = Point2D(3, 4)

print(p1 + p2)         # (4.0, 6.0)
print(p1 - p2)         # (-2.0, -2.0)
print(p1 * p2)         # 11.0
print(p1 * 2)          # (2.0, 4.0)
print(p1 / 2)          # (0.5, 1.0)
print(p1.distance(p2)) # 2.8284271247461903
print(p1.angle(p2))    # 0.7853981633974483

Static vs. Class vs. Instance Methods vs. Module Functions (pt. 1)

• So far, functions written inside classes were related to the instances of the class

  • they are called “instance” methods are they are called on and for the instances, and they had the self parameter

    class MyClass:
        def instance_method(self, formal_arg):
            ...
    
    obj = MyClass()
    obj.instance_method("actual arg")
    # notice that the function is called on **an instance** of the class
    

• One may also define static methods, which are not related to the instances of the class

  • they are called “static” methods as they work the same for all instances,

  • they are tagged by the @staticmethod decorator

  • they do not have the self parameter

    class MyClass:
        @staticmethod
        def static_method(formal_arg): # notice the lack of the `self` parameter
            ...
    
    MyClass.static_method("actual arg")
    # notice that the function is called on **the class itself**
    

Static vs. Class vs. Instance Methods vs. Module Functions (pt. 2)

• One may also define class methods, which are like static methods, but they have a reference to the class itself

  • they are tagged by the @classmethod decorator

  • they have the cls parameter, which is a reference to the class itself

    class MyClass:
        @classmethod
        def class_method_1(cls, formal_arg): # notice the `cls` parameter
            ...
    
        @classmethod
        def class_method_2(cls, formal_arg): # notice the `cls` parameter
            return cls.class_method_1(formal_arg) # the cls parameter is usefull to call other class methods
    
    MyClass.class_method_2("actual arg")
    # notice that the function is called on **the class itself**, as if it were a static method
    

• One may also define module functions, which are not related to any class

  • they are just functions defined in a module, not inside a class

  • they are called “module” functions as they are defined at the module level

    class MyClass:
        ...
    
    def module_function(arg: MyClass):
        ...
    
    module_function(MyClass())
    # notice that the function is called with no prefix
    # notice that the function can still use classes defined above them as data types
    

Where to put the function/method?

1. If a function operates at the instance level, and it is generally potentially useful for each instance, it should be an instance method

   • this is automatically true if the functionality can be provided by some magic method
     • e.g. string conversion, equality, hashing, arithmetic operations, etc.

2. If the function involves a variable amount of instances of a class at once, it should be a static method

   • e.g. getting the center of a bunch of points, or the average of a bunch of complex number, etc.

3. If the function could be static, but it needs to use other class methods, it should be a class method

   • e.g. a class method that calls another class method, or a class method that creates an instance of the class, etc.

4. If the function uses the class to do something which is not general, but application specific, it could be a module function

   • e.g. a function accepts $N$ points to create a polygon
   • in this case, you may also consider to design another class to encapsulate the functionality

Example: Ordering 2D Points Anti-Clockwise w.r.t. their Centroid (pt. 1)

This can be supported via 2 class functions:

• Point2D.centroid(points: list[Point2D]) -> Point2D: computes the centroid of a list of points
• Point2D.sort_anti_clockwise(points: list[Point2D]) -> list[Point2D]: orders a list of points anti-clockwise w.r.t. their centroid

Example: Ordering 2D Points Anti-Clockwise w.r.t. their Centroid (pt. 2)

class Point2D:
    # rest of the class is unchanged

    @staticmethod
    def centroid(points: list['Point2D']) -> 'Point2D':
        return sum(points, Point2D(0, 0)) / len(points)

    @classmethod
    def sort_anti_clockwise(cls, points: list['Point2D']) -> list['Point2D']:
        centroid = cls.centroid(points)
        def angle_wrt_center(p):
            return (p - centroid).angle(Point2D(1, 0))
        points = list(points)
        points.sort(key=angle_wrt_center)
        return points

Usage

triangle = [Point2D(1, -1), Point2D(-1, -1), Point2D(0, 1)]
print(Point2D.centroid(triangle))             # (0.0, -0.3333333333333333)
print(Point2D.sort_anti_clockwise(triangle))  # [Point2D(0.0, 1.0), Point2D(-1.0, -1.0), Point2D(1.0, -1.0)]

rectangle = [Point2D(-2, 1), Point2D(2, 1)]
rectangle = rectangle + [-p for p in rectangle]
print(Point2D.centroid(rectangle))            # (0.0, 0.0)
print(Point2D.sort_anti_clockwise(rectangle)) # [Point2D(2.0, 1.0), Point2D(-2.0, 1.0), Point2D(-2.0, -1.0), Point2D(2.0, -1.0)]

The Inheritance Mechanism

• Inheritance is a way to reuse and specialize classes, without repeating code

  • a class can inherit the attributes and methods of another class
  • the inherited class is called the base, parent, or super class
  • the inheriting class is called the derived or child class, or subclass

• Inheritance is a way to factorize common attributes and methods into a base class

  • the base class is a generalization of the derived class
  • the derived class is a specialization of the base class

• Inheritance is a way to extend the functionality of a class

  • the derived class can reuse old attributes of the base class (without re-writing them)
  • the derived class can add new attributes to the base class
  • the derived class can override the attributes of the base class

• Inheritance creates a sub-typing relationship between classes, which are subject to the Liskov Substitution Principle

  • i.e., an instance of a derived class should be able to substitute an instance of the base class in any context
    • (vice versa is not necessarily true)

Examples

• Animal is a base class, Dog and Cat are derived classes
• Shape is a base class, Circle and Rectangle are derived classes
• Vehicle is a base class, Car and Bicycle are derived classes

The Inheritance Mechanism in Python

• In Python, a class can inherit from one or more classes

  • e.g., class Derived(Base1, Base2, ...):

• If no base class is specified, the class implicitly inherits from the object class

  • e.g., class Derived: is equivalent to class Derived(object):

• All classes are (either directly or indirectly) derived from the object class

  • this is the root of the class hierarchy in Python
  • i.e., all classes are subtypes of the object class
    • recall that “everything is an object”

• Inside derived classes, one can:

  • reuse the attributes and methods of the base class
  • redefine (a.k.a. override) the attributes and methods of the base class
  • reuse the old version of a method of the base class, by calling super() instead of self

• Some classes are abstract, meaning that they are incomplete and should not be instantiated

  • they are just meant to factorize common attributes and methods for the derived classes

Dummy Example: The Animal Class Hierarchy (v. 1)

class Animal:
    def __init__(self, name: str):
        self.__name: str = name       # private field

    @property
    def name(self) -> str:            # public, read-only property
        return self.__name

    def speak(self):
        raise NotImplementedError("Subclasses must override this method")

class Dog(Animal):
    def speak(self):
        print(f"[{self.name}]", "Woof!")

class Cat(Animal):
    def speak(self):
        print(f"[{self.name}]", "Meow!")

class Crocodile(Animal):
    def speak(self):
        print(f"[{self.name}]", "...")

animals = [Dog("Rex"), Cat("Garfield"), Crocodile("Dingodile")]
for animal in animals:
    animal.speak()

# [Rex] Woof!
# [Garfield] Meow!
# [Dingodile] ...

Notice that all three classes:

• inherit a constructor from the base class, accepting the name of the animal as a parameter
• inherit the name property from the base class
• inherit, but cannot access, the __name field from the base class
• override the speak method from the base class
• conventionally print the name of the animal before the sound it makes

Private vs. Protected

• Private attributes and methods are not accessible from outside the class

  • they cannot be accessed from outside the class, not even from the derived classes
  • they are inherited but not accessible from the derived classes

• Private attributes are the ones whose names start (and does not end) with __

  • e.g., self.__name
  • not to be confused with magic methods, whose names start and end with __
    • e.g., def __init__(self):
    • these are not private, but rather special, methods: override them only if you know what you are doing

• Protected attributes and methods are not accessible from outside the class, but are accessible from the derived classes

  • they are inherited and accessible from the derived classes
  • they are the ones whose names start with _
  • e.g., self._name

• Protected attributes can be used to factorize some functionality in a base class, and reuse it only in the derived classes

• Public attributes and methods are accessible from outside the class

  • non-private and non-protected attributes and methods are public by default

Dummy Example: The Animal Class Hierarchy (v. 2)

class Animal:
    def __init__(self, name: str):
        self.__name: str = name              # private field

    @property
    def name(self) -> str:                   # public, read-only property 
        return self.__name

    def _say_something(self, sound: str):    # protected method
        print(f"[{self.name}]", sound)

    def speak(self):
        raise NotImplementedError("Subclasses must override this method")

class Dog(Animal):
    def speak(self):
        self._say_something("Woof!") 

class Cat(Animal):
    def speak(self):
        self._say_something("Meow!")

class Crocodile(Animal):
    def speak(self):
        self._say_something("...")

(the classes’ behaviour is unchanged, see slide of v. 1)

Aspects to notice

• the base class Animal now has a protected method _say_something to factorize the printing of the name before the sound…
• … which is reused by the derived classes Dog, Cat, and Crocodile
• in this way the convention about printing the name before the sound is made explicit

Dummy Example: The Animal Class Hierarchy (v. 3)

class Animal:
    def __init__(self, name: str, sound: str):
        self.__name: str = name      # private field
        self.__sound: str = sound    # private field

    @property
    def name(self) -> str:           # public, read-only property 
        return self.__name

    def speak(self):
        print(f"[{self.name}]", self.__sound)

class Dog(Animal):
    def __init__(self, name: str):
        super().__init__(name, sound="Woof!")

class Cat(Animal):
    def __init__(self, name: str):
        super().__init__(name, sound="Meow!")

class Crocodile(Animal):
    def __init__(self, name: str):
        super().__init__(name, sound="Meow!")

(the classes’ behaviour is unchanged, see slide of v. 1)

Aspects to notice

• the speak method is now implemented once and for all in the base class Animal…
• … and not overridden by the derived classes Dog, Cat, and Crocodile
• the base class Animal now has a constructor that accepts the name and the sound of the animal
  • the sound is memorized in a private field, and printed by the speak method
• derived classes Dog, Cat, and Crocodile override the constructor to initialize the sound of the animal
  • each derived class specializes and fixes the sound of the animal, while the name is still parametric
• derived classes’ overridden constructors call the base class’ constructor using super()