The video owner has disabled playback on external websites.
This video is no longer available on YouTube.
This video cannot be played right now.
Watch on YouTube
Unlock AI-Powered Learning Tools
Sign up to access powerful tools that help you learn faster from every video.
SOLID: Writing Better Python Without Overengineering
Subtitles (532 segments)
This video is brought to you by
Squarespace. You may have heard of the
solid design principles. In fact, you
may have heard of them from an old video
done by me. Robert Martin, aka Uncle
Bob, came up with these principles in
the early 2000s to help engineers write
better software. But are they still
relevant? And do they actually help in
Python or do they make things worse? To
test that, I'm going to refactor a piece
of Python code using these principles.
and we're going to see what we end up
with. And along the way, we're going to
figure out what actually improves the
code. So, here's the example. I have a
CSV file with sales data. There's
customer names, addresses, items, uh,
dates, price, taxes, basically your
standard sales data. Some of these rows
are actually returns. So David Pon for
example from Christensen Land he ordered
a monitor but sent it back and got back
his money and his taxes and that's
indicated by a negative price. Now what
we want to do is generate JSON reports
that includes some useful information
like the number of unique customers in a
certain time period, the average order
value, percentage of returns, the total
sales, and being able to generate that
report for any date range that we want.
So here's a first stab at this in
Python. I have a class called messy
sales report. So that's already
indicates something, right? And it has a
generate method that gets an input file,
gets an output file, a start date, and
an end date, which is the period that we
want the report to be of. And then this
is the code. We read the CSV file, we
apply the filter, uh, we check the
average order returns, the total sales,
and then we create the report, we dump
it into a file, and we're done. So when
I run this then we now have a file here
called sales report that actually
created a report for 2024. There were 33
customers. This was the average order
value. The returns percentage and the
total sales in this period was this
amount. Now of course because we have
this start date and end date. I can also
do this from uh only for the second part
of 2024.
And then when I run this again and I
look back at the sales report now you
see we actually have 20 customers. There
are no returns and we have of course a
lower number of total sales. So that's
our messy report. Now you can already
see that there's plenty of problems with
this code. It's like a big mess. Thus
the class name. So what does that to do
with design principles? Well, design
principles help you tackle this kind of
code and make it better. And a very
well-known set of design principle is
solid. What does that actually mean?
Well, each letter stands for a specific
principle. The S stands for single
responsibility and that means that each
part of your code, each class, each
function should do one thing. Then you
have open closed the O in solid. That
means that code should be open for
extension but closed for modification.
In this example, it should be easy to
add another thing to this report,
another metric. So open for extension,
but it should not be easy to completely
modify the structure of the report. Then
you also have the L that stands for list
of substitution. And that means that
subtypes should behave like their base
types. So if you have a superass that
specifies some sort of method, then you
don't want subasses to interpret
arguments of that method completely
differently cuz then it's going to be
very hard to swap out a subtype for
another subtype. The I stands for
interface segregation. That means you
should prefer small focused interfaces
over large ones. So don't create huge
abstract base classes or protocol class
with hundreds of methods in them but
keep them relatively small and focused
on what you actually need it for. Then
we have the D which stands for
dependency inversion. That means that
highle code shouldn't depend on lowlevel
details. Now in Python you typically
don't follow these like commandments.
They're also very much based in
objectoriented design and well, Python
supports object-oriented programming,
Full subtitles available in the video player
Practice with Exercises
Generate vocabulary, grammar, and comprehension exercises from this video
Comments (0)
Login to CommentSign up to unlock full features
Track progress, save vocabulary, and practice exercises
Interactive Mode
Quiz
Correct answer:
Related Videos
Anatomy of a Scalable Python Project (FastAPI)
Now in Android: 120 – Android Canaries, Agentic AI, 16 KB page size requirements, and more!
The Deadliest Virus on Earth
Developers have a problem with side projects
Many Crystals Take Millions of Years to Form, Not These
Late Night with Seth Meyers
Quiz
Correct answer:
Quizzes appear as you watch the video
Memory Tip
From this video
Start learning languages for free
