Design and Guidance: OOP in Python (Overview)

Christopher Trudeau
Design and Guidance: Object-Oriented Programming in Python Christopher Trudeau 03:30
Recommended Tutorial Course Slides (.pdf) Sample Code (.zip) Ask a Question

Writing good object-oriented code is about more than just how to write the syntax. Knowing when and when not to use it, as well as guiding principles behind object-oriented design will help you write better code.

In this course, you’ll learn about:

  • The objected-oriented approach in Python vs other languages
  • Cases in which you shouldn’t use classes in Python
  • Alternatives to inheritance in structuring your code
  • The SOLID principles for improving your code

SOLID is an acronym for five principles that you should use when thinking about object-oriented code. The principles are:

  • The Single-Responsibility Principle (SRP)
  • The Open-Closed Principle (OCP)
  • The Liskov Substitution Principle (LSP)
  • The Interface Segregation Principle (ISP)
  • The Dependency Inversion Principle (DIP)

This course is the third in a three-part series. Part one is an introduction to class syntax, where you learn how to write a class and use its attributes and methods. Part two is about inheritance and class internals.

Download

Sample Code (.zip)

 3.9 KB
Download

Course Slides (.pdf)

 999.1 KB

00:00 Welcome to Object-Oriented Coding in Python: Design and Guidance. My name is Christopher, and I will be your guide.

00:08 This is the third part of a multi-part course. Parts one and two are about the how of object-oriented coding, covering the syntax of classes in Python and how to use its attributes and methods.

00:21 As everything in Python is an object, that includes intricate details, such as how operations like adding and multiplying apply to your objects through dunder methods. This third part of the course is a little different.

00:34 It’s a bit more about the why and approach. The focus in this part of the course is about how to build better object-oriented software and, in some cases, why you maybe shouldn’t use OO techniques at all.

00:49 This third part of a three-part course teaches you about how the Python object-oriented approach compares to other languages, when not to use classes in Python, alternatives to inheritance, and the SOLID principles.

01:07 The code in this course was written with Python 3.11. Object-oriented coding in Python has gone through some changes over the years, and so the code presented here won’t work in Python 2 without being altered.

01:20 Python’s a bit of a weird beast language-wise. Its history is firmly in the procedural style scripting world, but it has flavors of functional programming and object-oriented coding inside of it.

01:32 This means you can choose how much or how little you use object-oriented techniques when you code. It actually is very object-oriented underneath, but you don’t have to use that mental abstraction if you don’t want to.

01:46 If you’re coming from other languages, especially those which are object-oriented first, this leap can be a bit of an adjustment. If you’re an experienced coder in one language, your first tendency when writing code in a new language is to use the style you’re familiar with, even if it isn’t a good fit for your new language.

02:05 As a Python coder, if you come across a lot of object-oriented code where you’re wondering why they didn’t just use a dictionary, there’s a good chance the original writer was an ex-Java person or something similar. Once you do decide to write some object-oriented code, whether in Python or any other language, there are some guiding principles that should be followed.

02:28 This course is primarily about those principles. You want to write clean code that can be supported by others. Structure your code for reuse following the DRY—that’s don’t repeat yourself—principle, and you also want to take advantage of duck typing or, more formally, polymorphism, where the interface to the object determines how it is used, and it can be passed around to other code, which doesn’t have to be concerned with its underlying implementation.

02:57 And once you start building classes on top of each other, you want to do so in a fashion where you aren’t designing yourself into a corner, keeping your code flexible for future changes.

03:07 There’s an acronym out there that can help you think about these ideas. It’s named SOLID, the expansion of which is confusing, and a paragraph full, so I won’t call it anything but SOLID until you get to that part of the course.

03:23 Before spending some time on SOLID, let’s talk about whether you should orient your objects at all.

Become a Member to join the conversation.