OOP Practice in Python: Bike Share Simulator
Most of my coding experience so far as a student of data science and engineering has revolved around procedural programming. For example, I would write a Python module with several functions that call one another in a logical order within a data pipeline to extract, transform, and then load data. One process would simply trigger another. The only objects I use are those from other packages, which ends up working out completely fine for that particular application!
This is just one approach to programming, however, and it is important in many roles to know how to build object-oriented system. I aspire to build more with my programming, and thus have begun a deep-dive into the world of object-oriented programming (OOP). My reintroduction to OOP consists of two phases:
- Relearning OOP and filling in the holes in my knowledge.
- Implementing my own OOP project from scratch.
What is OOP?
OOP is a paradigm that allows programmers to implement real-world entities with code such as inheritance, polymorphism, etc.
I had some exposure to OOP in an intro CS class I took in college several years ago, but I really needed to brush up on my skills in order to properly implement anything. I thus turned to YouTube, as I often do to learn things.
Corey Schafer
Quick plug for Corey Schafer, who has an incredible YouTube channel covering many programming topics in detail! Most, if not all, of his content is organized into playlists, including his OOP playlist. I used this to go over most of the programming I use below.
Bike Share Simulator
I recently did a really interesting data analysis assessment using a 2012 DC bike share data set on Mode.com. The assessment got me thinking about all of the things one needs to keep track of to properly manage such a system. Given my OOP kick and the fact that the whole system is made up of just a few simple pieces, I figured this would be a great first project.
Bike Share Systems
Bike shares consist of multiple stations throughout a city. Each station contains a fixed number of docks that can each house a single bike.
The number of stations depends on many factors, but there should probably be more stations where there is greatest demand for the service. The number of docks within each station also likely follows a similar criteria, although this varies by bike share company. I would imagine that not all docks are initially filled with bikes because then users wouldn’t be able to park bikes anywhere once they check one out.
The consumer pays based on how long they ride. Classic bikes have a base rate of perhaps $3 for the first 30 minutes. Trips longer than 30 minutes incur an additional small fee (~$0.10) per minute of use. Some bike share systems offer electric bikes at a higher cost.
Design
This provides an excellent starting point for my project. To keep things simple, I limit the bike share system to its main components:
- Bike (of which there can be two varieties: classic and electric)
- Dock
- Station
Each component will be its own class as there will need to be multiple stations, each of which tracking the activity of its docks, which each need to check bikes in and out. All stations are fundamentally the same with the exception of location and size. All docks are the same, and all bikes are the same with the exception of the type of bike used. I omit customers as a class because one doesn’t really need to keep track of the customers to run the simulation.
Simplest Simulation
The simplest case of the simulation with the pieces above is one with just a single station, a single dock, and a single bike. The bike has only one option, which is to leave and then come back at some later time. Every time the bike moves, the dock records the time and trip id, and the bike registers some wear and tear.
The station has the ability to pull all of the records from each dock to compile a master list of all the activity at that station. In theory, when there are multiple stations and multiple docks at each station, this allows the simulation to compile all of the stations’ data into a database (I’ll use PostgreSQL) that can be used to see where and when each trip starts and ends.
That’s all for now. I’ll cover the implementation of this system with code snippets in my next post. In the meantime, you can check out the GitHub repo to see my progress!
