Hey guys so I've been reading about design patterns and I had a lot of difficultly picking it up.
I later realized it might be because my primary language of choice is JavaScript which is a functional programming language.
Even though JavaScript did provide classes in ES6 update, I personally never got around using it and now that I have finally switched to TypeScript I had an inventive to learn about Object Oriented Programming.

So in a nutshell the first step to learning Design Patterns would be to understand Object Oriented Programming. So here's a short excerpt which made me realize what is Object in Object Oriented Programming and i think this would make a great start to my next series which is going to be about "Design Patterns in TypeScript". ( GitHub repo link at the bottom of the article )

How do people do things ?

Let’s say that you were an instructor at a conference. People in your class had another class to attend following yours, but didn’t know where it was located. One of your responsibilities is to make sure everyone knows how to get to their next class.

If you were to follow a structured programming approach, you might do the following:

1. Get list of people in the class.
2. For each person on this list:
   1. Find the next class they are taking.
   2. Find the location of that class.
   3. Find the way to get from your classroom to the person’s next class.
   4. Tell the person how to get to their next class.

To do this would require the following procedures:

1. A way of getting the list of people in the class
2. A way of getting the schedule for each person in the class
3. A program that gives someone directions from your classroom to any other classroom
4. A control program that works for each person in the class and does the required steps for each person

Doubtful you’d follow this approach

I doubt that you would actually follow this approach. Instead, you would probably post directions to go from this classroom to the other classrooms and then tell everyone in the class, “I have posted the locations of the classes following this in the back of the room, as well as the locations of the other classrooms. Please use them to goto your next classroom.” You would expect that everyone would know what their next class was, that they could find the classroom they were to go to from the list, and could then follow the directions for going to the classrooms themselves.

What is the difference between these approaches?

• In the first one—giving explicit directions to everyone — you have to pay close attention to a lot of details. No one other than you is responsible for anything. You will go crazy!

• In the second case, you give general instructions and then expect that each person will figure out how to do the task him-self or herself.

Shifting responsibility from yourself to individuals . . .

The biggest difference is this shift of responsibility. In the first case, you are responsible for everything; in the second case, students are responsible for their own behavior. In both cases, the same things must be implemented, but the organization is very different.

What is the impact of this?

To see the effect of this reorganization of responsibilities, let’s see what happens when some new requirements are specified.

Suppose I am now told to give special instructions to graduate students who are assisting at the conference. Perhaps they need to collect course evaluations and take them to the conference office before they can go to the next class. In the first case, I would have to modify the control program to distinguish the graduate students from the undergraduates, and then give special instructions to the graduate students. It’s possible that I would have to modify this program considerably.

However, in the second case—where people are responsible for themselves. I would just have to write an additional routine for graduate students to follow. The control program would still just say, “Go to your next class.” Each person would simply follow the instructions appropriate for himself or herself.

Why the difference?

This is a significant difference for the control program. In one case,it would have to be modified every time there was a new category of students with special instructions that they might be expected to follow. In the other one, new categories of students have to be responsible for themselves.

There are three different things going on that make this happen.
They are:

• The people are responsible for themselves, instead of the control program being responsible for them. (Note that to accomplish this, a person must also be aware of what type of student he or she is.)
• The control program can talk to different types of people (graduate students and regular students) as if they were exactly the same.
• The control program does not need to know about any special steps that students might need to take when moving from class to class.

The Object-Oriented Paradigm

The object-oriented paradigm is centered on the concept of the object. Everything is focused on objects. I write code organized around objects, not functions.
The advantage of using objects is that I can define things that are responsible for themselves.
Objects inherently know what type they are. The data in an object allow it to know what state it is in and the code in the object allows it to function properly (that is, do what it is supposed to do).

In this case, the objects were identified by looking at the entities in the problem domain. I identified the responsibilities (or methods)for each object by looking at what these entities need to do. This is consistent with the technique of finding objects by looking for the nouns in the requirements and finding methods by looking for verbs, this technique to be quite limiting. but, it is a way to get us started.

The best way to think about what an object is, is to think of it as something with responsibilities. A good design rule is that objects should be responsible for themselves and should have those responsibilities clearly defined. This is why I say one of the responsibilities of a student object is knowing how to go from one classroom to the next.

Working with objects in the example.

Writing the “Go to the next classroom” example using an object-oriented approach is much simpler. The program would look like this:

1. Start the control program.
2. Instantiate the collection of students in the classroom.
3. Tell the collection to have the students go to their next class.
4. The collection tells each student to go to their next class.
5. Each student:
   1. Finds where his next class is
   2. Determines how to get there
   3. Goes there
6. Done.

Object-Oriented Terminology

Here's the GitHub repo I've begun to maintain regarding my learning experience of Design Patterns. It would be awesome to have some contributions in terms of setting up issue templates and what not as I don't have experience doing so.

MidasXIV / Design-Patterns-in-TypeScript

Elements of Reusable Object-Oriented Software

Design Patterns in TypeScript

Creational Design Patterns | Structural Design Patterns | Behavioral Design Patterns

In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

---

This article assumes you are reasonably proficient in at least one object-oriented programming language, and you should have some experience in object-oriented design as well. You definitely shouldn't have to rush to the nearest dictionary the moment we mention "types" and "polymorphism," or "interface" as opposed to "implementation / inheritance”
But I'll try to keep the literature as simple as possible.

Don't worry if you don’t understand

…

View on GitHub

Note : the only intent of this article is to raise awareness about the book and maybe point to concepts self taught programmers maybe unaware of.

This is a short excerpt from the book Design Patterns Explained Book by Alan Shalloway and James R. Trott.

Happy coding :D.