5 Tips For Object-Oriented Programming Done Well - In Python



💡 Get my FREE 7-step guide to help you consistently design great software: https://arjancodes.com/designguide.

You can do Object-Oriented Programming badly, or you can do it well. Especially in Python, there are many ways to trip up. So, here are 5 tips for Object-Oriented Programming done well.

🎓 Sign up to Brilliant now and get 20% off the annual subscription: https://brilliant.sjv.io/arjancodes.

👍 If you enjoyed this content, give this video a like. If you want to watch more of my upcoming videos, consider subscribing to my channel!

💬 Discord: https://discord.arjancodes.com
🐦Twitter: https://twitter.com/arjancodes
🌍LinkedIn: https://www.linkedin.com/company/arjancodes
🕵Facebook: https://www.facebook.com/arjancodes

👀 Code reviewers:
– Yoriz
– Ryan Laursen
– James Dooley
– Dale Hagglund

🎥 Video edited by Mark Bacskai: https://www.instagram.com/bacskaimark

🔖 Chapters:
0:00 Intro
1:14 A bit of background
3:01 #1 You can combine FP and OOP
5:16 #2 Make classes either behavior-oriented or data-oriented
7:24 #3 Be careful with inheritance
10:22 #4 Use dependency injection
13:32 #5 Don’t abuse Python’s power features

#arjancodes #softwaredesign #python

DISCLAIMER – The links in this description might be affiliate links. If you purchase a product or service through one of those links, I may receive a small commission. There is no additional charge to you. Thanks for supporting my channel so I can continue to provide you with free content each week!

source

26 thoughts on “5 Tips For Object-Oriented Programming Done Well – In Python”
  1. I've worked in crazy spaghetti codebases, and architecture astronaut code mazes. After those experiences, I love this practical, real-world advice. Thank you.

  2. I don't think functional alone is conductive to clean code. How do you group functions? How do you initialize data in a group of functions that share some state or configs? How do you decouple the functions' contract from its implementation, etc.

  3. Would have been nice to also mention the terms "pure core" and "side effects". Especially the way the code should be organised. Haskel is probably one of the best examples. It allows I/O operations only in the "main" context. Hence all that unpredictability that I/O has is located in a "thin top layer" (easier to debug). The core must be immutable – the input gets transformed and returned at the output without any side effects. Same input generates same output no matter how many times that function is called. For dynamic programming languages there is also the PFAAO design pattern which is quite helpful. Writing tests for "pure" code is always a joy because it is really straight forward.

    Personally, I'm coming from more of a RoR background. Wouldn't say that Python is that great with FP. I think that Ruby does a much better job at FP but it has its own downsides (i.e: there are no native immutable data structures). After learning a bit of Scala, I was able to understand that 95% of the Ruby projects I've ever seen were done in a classical imperative way that mixes the stateful with the stateless and then gets really messy over time.

    PS: FP is a style. Can be very well achieved in any OOP language if FP principles are well understood and followed (ofc if we ignore the type system altogether which to me is probably Scala's best selling point).

  4. Thanks, I used the dictionary as a collection of functions/objects a lot but until this video, I did not realize that enums as keys can work really nice.

  5. This opened my mind, I was trying to follow the trend and make everything OO, and it seemed so counterintuitive for many things. Now it is much more clear.

  6. Writing object oriented code well is basically a process of mostly avoiding object oriented programming

  7. python is designed to do a lot of things … functional programming isn't one of them

    point in case:
    a=[1,2,3]
    a.append(4) # how to get as imperative as it can possibly get

  8. This kind of insight is quite rare for a you tube video. Really well delivered on a topic that should be discussed more!

    Key takeaway is mostly that your chosen method of programming doesn’t have to be right or wrong. Is it useful? Is it readable to others in the team?

    Great work!

  9. Arjan, I love all your videos. You are a great teacher. I know it's not the focus of your video, but can you tell us how you have your line numbering setup in VSCode?

  10. Data classes have brought way more OOP to my code. A series of transformations on an object with predefined values is way easier to track compared to a dictionary

  11. I did all your tips in my last refactoring and it's working wonders 😂 A sane combination of functional and oop is actually great for writing well-structured code without crazy side-effects! 😄

    One thing about turning behavior-oriented classes into raw functions: If you wanna do dependency injection and duck typing via protocols, it's really essential to represent your set of functions as a class because it's way more cohesive than passing each function separately (really helps readabity). And moreover something like attributes is necessary to store the handle to each dependency instance. But for the rest of the video, I totally agree 😁

  12. Basically all big and popular Python libs are written in a OO manner. OO and "Pythonic" is not contradictory. IMHO, who believes that simply is a programming novice and has never worked on any bigger project in RL. And sure: you CAN go even further and do everything using functional programming. But than again: in RL good luck finding enough staff familiar with that to the required degree. OO is here to stay for many more years to come because it maps relations in a manner how we associate things in our brains. Easy to learn, hard to master.

  13. So you just use it how Rust is? Rust uses Structs for data and "Traits" for behavior. Rust has no classes. I do like to keep data and functionality separated in any kind of programming language. Sometimes the data can have some kind of "interface" on top of it for lightweight functionality. But even that interface or lightweight functions are mostly separated. haha

  14. this is quality content for senior devs; you're talking about abstract topics that matters on the big picture/decision making of big projects; I loved it, subscribed!

  15. Hey Arjan.
    Maybe you'll consider making a tutorial about creating python packages with setuptools etc? 🙂

Leave a Reply

Your email address will not be published.

Captcha loading...