Components of a Design Pattern

[00:00:00]
>> Maximiliano Firtman: So, components of a design pattern, a name, and again, yeah, we know there is a name, but the name is important to create vocabulary. So then, when we are saying, I'm going to do a singleton here, singleton is a design pattern. We all know, what we are talking about, I don't need to explain, what I'm doing., okay?

[00:00:19]
So that's the idea, so it has a name, it has a problem that tries to solve, okay? So there is a problem there, and we need to check actually if we do have that problem. There is a solution of course so an explanation saying okay, to solve this problem, one solution, is to do this and that okay?

[00:00:42]
We also have a context, because not every problem should be solved in the same way on different contexts. So, we are talking about just text here, so this is written somewhere, there is a context explaining, well, you should apply this solution to this problem, when the context looks like this.

[00:01:05]
Consequences, because not everything is shiny here, when you apply a design pattern, you will also get some consequences, positive or negative actually, and examples. So typically, we have an example, in one particular language, remember not every language is the same, or looks the same. So while some languages are pretty similar, I mean if you take Java and C sharp, with their differences, when we are talking about design patterns it's kind of the same thing.

[00:01:36]
So, when we go to JavaScript Script, that's a completely different story. So, why is this important for Vanilla JS project? So, with Vanilla JavaScript, we have complete freedom, that's good, but that's also a challenge, okay? That we can do whatever we want, and, if you have experience doing vanilla JavaScript project, you start simple, which is pretty good, it works, it's fast, but then you start adding more features.

[00:02:10]
You want to add some other ideas, and then you start finding some challenges, that then you get into a spaghetti code. You are actually coupling a lot of parts of your project in the same code and you start realizing hey, I don't like how this looks like. And then that's when you realize maybe I should have used a library, React or Angular or Vue or whatever, or next.JS.

[00:02:41]
And, well will see that understanding some design patterns, you can think about applying some ideas that are currently in some libraries and frameworks, but in Vanilla JavaScript as well. So, we need to set guidelines, that's the idea. So, the guidelines will actually let us improve reusability of our code and you will see that with the first lab, the first project that we will work, that's clear there.

[00:03:13]
Reusability, scalability, meaning when they start adding more features at some point, is like a monster, difficult to manage. Consistency, because on every part, on every, let's say, functionality of your web app, you're using a different pattern, a different code, if you don't have a guideline, if you are not following some rules.

[00:03:38]
Efficiency, I'm talking about developers experience here, I mean, you're efficient as a developer and also performance sometimes, when executing the web app. And debugging, debugging a vanilla JavaScript project, when, you're not following some guidelines and using some design patterns, might be a problem. So we will try, to solve these issues by applying some design patterns, okay?

[00:04:05]
Anyone, can create a design pattern, we can create one today, if we want to. We typically start with a blog post or an article published somewhere, where we are going to set a name, and we will explain the problem, okay? How we have been creating an app, we found this problem, and then we start thinking about the solution, and this is the solution.

[00:04:28]
And you explain the solution, and then you put some code sample there, and you publish it, and yeah, maybe no one is going to like your design pattern, which is possible, okay? It's for probable, but all design patterns stuff like that, but maybe the community will say that's a good idea, we will start implementing that.

[00:04:49]
And then maybe you will find the conference the next year that someone is creating a talk on that design pattern. Or maybe you are creating a talk for a conference, and that's how the design pattern life cycle starts, okay? There is no design pattern organization that defines, this is the approved design pattern okay?

[00:05:10]
This is just community based, these are just ideas, ideas and how to solve problems and, that's all, okay? Anyone can create a design pattern. And, this is probably the most important part, probably the only slide that you should remember from today's workshop, don't use design patterns just because it sounds cool, okay?

[00:05:31]
So, we shouldn't use design patterns because everyone is using it. So one of the most important part of design patterns, is that, we should check. If we do have that problem first, and we do have the context, that was defined with the design pattern, before saying I will use that design pattern.

[00:05:54]
Because if we don't have, we are adding, more problems, to our current problems, okay? This is not, on every project on everybody that's asking project, you need to always use these 15 design patterns. I'm not going tell you this today, there is no list of design patterns that you should always use.

[00:06:16]
It always depends on the project, on every project, on every problem that you have, you will sit down and say okay, I will solve this problem with this pattern, okay? That's the idea, so that's why you can get to failures using design patterns, over engineering. And also you will probably feel that we are getting there, in our first project, because we will start really simple.

[00:06:46]
That first project is not using any design pattern, and it's simple to understand, but you will see the promise that we have there. And then we will apply design patterns, and we will end up with the same behavior, but with better scalability and all the good stuff, but also you will feel that, I think that now it's over engineering.

[00:07:08]
So we need to find also the balance, okay? The balance where you feel comfortable, applying more design patterns. Every design pattern, well, sorry, not every design pattern, most design patterns. Are adding abstraction layers, on top of your code, which means more files, more components, more classes, okay? More code, in general, so that can lead to over engineering at one point.

[00:07:36]
Misapplication, that's what I said before that you are applying a design pattern that is not for your current problem, it's not solving your problem. Inflexibility, and that has to do sometimes with thinking that the design pattern is kind of a law, that you need to comply with, and you don't understand that this is just a recipe.

[00:08:01]
I mean if you are cooking and you are following a recipe, but you feel like something is not what you want, you can change the recipe. Of course, it can go, well, or bad, but you can change it, you have a flexibility to change. I mean it says six eggs, I say no, let's add four eggs, and maybe two ydx, you can, you have the flexibility to change the recipe.

[00:08:25]
The same happens here with design patterns, if you just follow what the document says, okay? You may end up with the wrong solution, learning cue for the team, is also something that can be a problem. I mean if you're working with a team, and they don't know about design patterns, they have to learn.

[00:08:45]
But the same happens with the library of course, right? Complexity, it gets more complex and you will see on the first lab that it can get more complex when you are applying design patterns, you have pros and cons. And performance overhead, because we have more components, more files to load, more classes to instantiate on the memory.

[00:09:09]
So, we have a performance overhead, sometimes it's not a big deal, or it's not really a small deal. It's not a deal at all, and sometimes it can be a problem, so it depends on the case. I mean if you're creating, time applications, that you are talking to live or dead hardware.

[00:09:27]
Yeah, probably you will try not to use a lot of design patterns that we will use today, but that's not typically a web app, right? So, also we have a definition known as the anti-pattern, when we say this is an anti-pattern, is that, you're applying a practice. It can be a design pattern, a recipe, a solution, that may initially seem beneficial, but at the end, it's leading to poor outcomes.

[00:09:56]
So, we need to try to get out of anti-patterns, so when someone is saying, hey, this is an anti-pattern. Don't do that, just think that it's just saying, I mean it feels like it's giving you some advantages, but actually no. So, even today, you probably know a lot of design patterns, even if you don't recognize them initially as that.

[00:10:23]
So you have been, working with web apps, with JavaScript, and you have been, dealing with some ideas. Even sometimes you have found those ideas, you created an object, with this format, and after seeing design patterns you realize I didn't know I was creating a factory. Maybe you didn't know about the name, the factory name, but you were actually applying the idea anyway, because it's just an idea, but now you have a name.

[00:10:50]
So then when you're talking with a colleague, you can now say that's a factory, I'm applying a factory there.