So, before we get too far into the mechanics of programming,

let's talk about the biggest subject of all design.

I don't mean how your software looks on a website or a phone, though.

I'm talking about the organization thinking and layout of your code.

In previous courses, most of our code has been in a single file.

This is fine for small amounts of code, but

you'll quickly see that we don't always have small code footprints.

Libraries and tools can quickly reach hundreds, if not thousands,

of lines of code.

That's just not something you want to read all in one file.

We've all been there, right, a document that just keeps scrolling and

scrolling and scrolling.

Now, imagine you're on line 595 of some script and

see a function reference from all the way up at line 18.

IDEs and other editors can reduce the amount of scrolling,

but wouldn't it be better if you didn't have to do that?

And this is the first case that software design solves.

Well, it helps at least.

We can break our code up into modules or files.

By putting code into logical groupings we can make it easier to take it all in and

think about what we need to do to do our job.

This logical grouping goes even further though.

We already grouped related lines of code together into functions.

Now with classes we have another layer of grouping.

If you have multiple functions that all work together think about putting them

into a class.

OO provides us with so many tools that it's often hard to know which ones to use,

or, if you should even use any of them.

I don't want to just dump a ton of terms and

features on you, so, I'll be bringing them up as we go through the course.

I'll also be talking about how to use and

think about these features in the design of your software.

But I can only influence your thinking so far.

I need you to also consider how you'd use each of these things

in the design of your own software.

An often overlooked truth of software development is that there's rarely any

one correct way to solve a problem or

design an algorithm, so like I said this organization starts at its

barest of bones with organizing code into functions and classes.

Let's think back to the shopping list app that we built in Python basics and

Python collections.

[SOUND] We had a list that held the things we wanted to shop for,

we had functions to add things to the list, reorganize the list,

and remove things we didn't need or had already bought.

Well right there I see something that makes sense for a class,

the ShoppingList itself.

I can see going a step further though and making each thing on the list and

instance of some other class.

Maybe this class would hold the name for

the thing, how many that I wanted, what store it was at, who knows.

There are many options for the functionality of this class.

And that brings me to another point, ruthless editing.

As you build classes and methods and functionality,

keep in mind a very common acronym, YAGNI, which stands for, you ain't gonna need it.

Keep your code lean and mean and you'll find it easier to use and

better for building awesome things with.

It's always a good idea to keep it simple or as the Zen of Python says,

if implementation is hard to explain, it's a bad idea often you'll find that you can

approach software design like you would the design of something in the real world.

Just like you wouldn't add a fish radar to your screwdriver,

you probably shouldn't add a function to send email to your calculator app,

practicality and logical thinking will lead to better software every time.

As part of that practicality, remember you're writing Python not Java or C# or

any other language.

If you come to Python from one of those languages, you might expect me to talk

about getters and setters or access controls on methods and attributes.

Python doesn't rely on these design features.

And you'll rarely find a place where they're absolutely needed in Python.

Stick to writing simple, clean code and as little code as possible,

and you'll find yourself a happier programmer.

All right, I think that's enough talking about design for now.

Go back and look at the code we've written together previously and

see if you can find places to add simple classes.

Even if you can't add them right now, keep those places in mind for

when you hit further through this course.

I'm sure you'll find all sorts of places to improve our old code.

Now though, let's get into the fun stuff and

start talking about the real wealth of object oriented design, inheritance.