All language subtitles for 002 Why NOT To Use Design Patterns_en

So let me start out by making this rather click baity statement and say that you shouldn't use design

patterns, at least not in the way that you typically think.

We don't use design patterns as a library of tools that we hammer into any problem.

This is called the Golden Hammer syndrome.

If you happen to know a tool really well, such as a hammer, then everything you look at, even if

it is a screw, is going to look like a nail and you're going to want to use that hammer to solve the

problem.

So this can happen with design patterns.

People will get familiar with one or two.

They will love those design patterns, understand them really well.

And whenever there is a problem, they might think about applying the design patterns.

They know this is the wrong way round.

We should be looking at the problems and trying to solve those root cause problems rather than trying

to find a solution that fits.

It's good to study design patterns as a way of seeing how certain templates of problems have been solved.

But often you'll find that once you're really good at programming and design patterns, you find yourself

writing design patterns and then only later realizing that you used a design pattern.

That's the thing about design patterns.

It's often very easy once you understand the reasoning behind them to just simply reinvent them as you

need them.

However, in this course, we are going to study them as a way to reinforce our understanding of good

programming principles.

So what are those good programming principles?

Well, I have put together my 10 coding commandments, which as a provides, I should say, are more

like guidelines because a good programmer will also know when to break the rules.

These are things that I've put together and learnt in my experience as a programmer.

You may come up with different ones.

You may disagree with some of mine.

That's great.

It happens all the time with programmers.

Program is like to disagree with each other.

So do mention in the comments on this video.

If you disagree, if you have other coding commandments or best practices that you think should be included

here, I went for 10.

There are obviously loads more, but 10 is a good number when you're talking about commandments.

So commandment number one is a thy code shall read like English or Spanish or Italian or whatever language

you happen to write your code in.

Typically, people all over the world write in English, which is why I've written the rule like this,

and implicitly that should be without even having to include any comments.

I think that code should be self documenting where possible.

That means that the variable names and the function names and the class names should really explain

what this code is doing, which takes me onto point number two.

Thou shalt take time to name things well.

Naming things well is really hard as we will see a little bit in the next lecture.

And so you must take time to think very carefully about good names for things giving a good name to

something that is incredibly powerful.

It allows you to reason about it in a way that you couldn't when you didn't have a name for it.

Imagine trying to talk about a tree without the word tree.

If you were just talking about that big woody leafy thing all the time, you just wouldn't be able to

have a decent arboreal conversation.

So naming things is important and we should take time to do it.

It allows us to read the code easily.

It allows us to comprehend our code takes us on two point number three.

They classes shall do one thing by this.

We mean that they are at a consistent level of abstraction.

If you have got an audio class, an audio player, then it should only do things relating to playing

audio.

It should not do anything related to animation that is obviously outside of the remit of the one thing

that class should do.

Now, obviously, the levels of abstraction here can change.

You could have a class that's responsible for playing the entirety of your game.

Obviously, within that remit, it does a lot of things, but it probably forms out some of that work.

Similarly, you might have a class that is super, super narrow minded that just perhaps spawns an object

and that goes for functions.

Two functions should just do one thing you don't want to function that is this error message and then

do that.

You want functions that just do one thing within their level of abstraction.

Again, they'll usually be a lower level of abstraction than the classes they reside within, but that's

the important part.

Number four, thou shalt use as little state as possible will get into why this is a problem in the

next lecture.

Often, a source of bugs is that you've got a mutable state, things that can change, variables that

can change, and each variable that can change represents a different state of your program could be

in the.

All variables you have, it gets exponentially more states that your program can be in, and so these

are more states for your program to go wrong in.

So using less of that makes your program easier to reason about and less bug prone.

We'll talk a lot more about all of these points throughout the course.

So with this, just an overview at this stage, and we'll go into far more detail.

So don't worry if you don't understand everything at this stage.

Thou shalt not refactor before the third repetition.

This is point number five.

And essentially what it's saying is that we need to be able to see a pattern before we refactor for

that pattern.

If you've done something twice, it may not be a pattern yet.

It might not be something that needs a method taking out or a class creating or any of that stuff until

you've done something for the third time often, then you might find there is time to create a new function

to abstract that shared functionality or a new inheritance hierarchy.

Those kinds of things.

Usually you need to see a pattern emerging first, so don't do that too early.

Number six, thou shalt not use a static and global state again.

We'll see this in a couple of lectures.

Time it goes hand in hand with point number four, which is to use as little state as possible.

Global and static state is doubly bad because it's more state, but also it can be changed anywhere

and accessed anywhere in your program.

So it has a lot more possibility to go wrong and to make other things go wrong in your code.

Commandment seven thy classes shall be highly cohesive goes hand in hand with commandment.

Eight.

Thy classes shall be loosely coupled If you have never heard of these two terms before, I'm going to

go into detail on these in a couple of lectures time.

So hold your horses and we will understand it better than commandment.

Number nine, thou shalt use composition over inheritance.

You may have come across the idea of composition.

You almost certainly came across the idea of inheritance.

Inheritance is where a class is said to be is a something.

So for example, you might have a crocodile is an animal.

Those are the kind of is a relationship.

The composition is typically a has a relationship, a car has a wheel.

So you might have a car class, which has a wheel class.

And typically, we prefer to use composition in programming because it allows us for a lot more flexibility.

Again, will cover this a lot more in a couple of lectures time and find late tenth commandment.

Thou shalt follow the law of D�MONTRER.

I find this the kind of the least important of the commandments, but it is a useful guideline and as

we'll see later, I will indeed be calling it the guideline of D'Amato because I think it is a rule

that you will be breaking reasonably often, which is why I put it as the last commandment.

OK, so these are my ten coding commandments.

I'd be interested to know what your best practices are.

Please go and share them in the comments.

And we're going to be using these best programming principles to understand and evaluate the design

patterns that we will see later in the course.

But in the next couple of lectures, we're going to dive in to a few of these to try and unpack why

they are important.