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
ابزارهای یادگیری هوش مصنوعی را باز کنید
ثبتنام کنید تا به ابزارهای قدرتمندی دسترسی پیدا کنید که به شما کمک میکنند سریعتر از هر ویدیو یاد بگیرید.
SOLID: Writing Better Python Without Overengineering
زیرنویسها (532 بخشها)
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,
زیرنویس کامل در پخشکننده ویدیو موجود است
با تمرینها یاد بگیرید
تمرینهای واژگان، گرامر و درک مطلب از این ویدیو بسازید
نظرات (0)
برای نظر دادن وارد شویدثبتنام کن و همه امکانات رو باز کن
پیشرفتت رو دنبال کن، واژگان رو ذخیره کن و تمرین کن
حالت تعاملی
آزمون
پاسخ صحیح:
آزمون
پاسخ صحیح:
آزمونها هنگام تماشای ویدیو ظاهر میشوند
راهنمای حفظ
از این ویدیو
شروع رایگان یادگیری زبان
