Lecture 6

Object-oriented Programming

Subclasses and inheritance II

MCS 275 Spring 2024
Emily Dumas

Lecture 6: Subclasses and inheritance II

Reminders and announcements:

• Homework 2 is due Tuesday at Noon.
• Project 1 will focus on object-oriented programming (OOP). Will be posted late this week or early next.

Plan

Finish our robot simulation class hierarchy

Discuss more OOP theory & practice

Planned Bot hierarchy

• ✅ WanderBot walks about randomly.
• ✅DestructBot sits for a while and deactivates.
• 🟨PatrolBot walks back and forth.

Updated Simulation

Now there are two simulation programs:

• botsimulation.py - Active bots shown as *
• botsimulation_fancy.py - Bots have their own symbols, inactive ones are shown as ☠.

Class vs instance

Classes: Cat, Dog, Vector2, WanderBot

Instances of Cat:

Instances of Vector2:

Instance attributes

self.* assignments in constructor like

                    class Cat(Pet):
                        def __init__(self, age, fur_color):
                            # other stuff...
                            self.age = age             # applies to *this* cat
                            self.fur_color = fur_color # applies to *this* cat
                

add attributes to the instance. They are therefore called instance attributes.

Often initialized from __init__ arguments and modified by methods.

Class attributes

Attributes can also be declared in the class definition, outside of any method. Then they are shared by every instance and are called class attributes. E.g.

                    class Cat(Pet):
                        retractable_claws = True  # Applies to all cats
                

Typically used for constants (never changed).

Bot class attributes

Natural to use class attributes for:

• Vectors WanderBot selects its step from
• Preferred symbol to represent the robot in a simulation.

PatrolBot

Takes direction (vector) and n (int). Walks n steps of size direction, then n steps of size -direction. Repeats indefinitely.

This robot has internal state:

• Whether walking out or coming back
• How many steps it has taken in the current direction

Finite State Machine

Keep track of which state we're in. Handle input differently depending on the state. Fixed set of possible states.

                    if state == "work":
                        handle_at_work(sms_content)
                    elif state == "home":
                        handle_at_home(sms_content)
                

Handlers may change state depending on the input.

                    def handle_at_home(sms_content):
                        if announces_critical_outage(sms_content):
                            send_reply("on my way")
                            state = "work"
                        else:
                            # deal with it tomorrow
                            return
                

Four pillars of OOP

• Encapsulation - Objects manage their own private, internal state.
• Abstraction - Method calls express intent (independent of implementation).
• Inheritance - Distinct classes can share behavior.
• Polymorphism - Code using a class will also work on its subclasses.

Extending the simulation

Beyond adding more robot types, how might me improve or extend the simulation?

Extending the simulation

Might create a class Arena that manages the list of bots and the space in which they move. Would have a single .update() method that updates all bots.

Arena object would be made first, then passed to each robots constructor. Robots would call Arena methods to interrogate surroundings (e.g. avoid collision, seek other bots, ...)