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:
- Get list of people in the class.
- For each person on this list:
- Find the next class they are taking.
- Find the location of that class.
- Find the way to get from your classroom to the person’s next class.
- Tell the person how to get to their next class.
To do this would require the following procedures:
- A way of getting the list of people in the class
- A way of getting the schedule for each person in the class
- A program that gives someone directions from your classroom to any other classroom
- 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).
| This Object | Is Responsible For |
|---|---|
| Student |
|
| Classroom | Having a location |
| Direction giver | Given two classrooms, giving directions from one classroom to the other |
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:
- Start the control program.
- Instantiate the collection of students in the classroom.
- Tell the collection to have the students go to their next class.
- The collection tells each student to go to their next class.
- Each student:
- Finds where his next class is
- Determines how to get there
- Goes there
- Done.
Object-Oriented Terminology
Term |
Definition |
|---|---|
Abstract class |
Defines the methods and common attributes of a set of classes that are conceptually similar. Abstract classes are never instantiated. |
Attribute |
Data associated with an object (also called a data member). |
Class |
Blueprint of an object—defines the methods and data of an object of its type. |
Constructor |
Special method that is invoked when an object is created. |
Encapsulation |
Any kind of hiding. Objects encapsulate their data. Abstract classes encapsulate their derived concrete classes. |
Derived class |
A class that is specialized from a superclass. Contains all of the attributes and methods of the superclass but may also contain other attributes or dif-ferent method implementations. |
Destructor |
Special method that is invoked when an object is deleted. |
Functional decomposition |
A method of analysis in which a problem is broken into smaller and smaller functions. |
Inheritance |
The way that a class is specialized, used to relate derived classes from their abstractions. |
Instance |
A particular object of a class. |
Instantiation |
The process of creating an instance of a class.MemberEither data or method of a class. |
Method |
Functions that are associated with an object. |
Object |
An entity with responsibilities. A special, self-contained holder of both data and methods that operate on that data. An object’s data are protected from external objects. |
Polymorphism |
The ability of related objects to implement methods that are specialized to their type. |
Superclass |
A class from which other classes are derived. Contains the master definitions of attributes and methods that all derived classes will use (and possibly will override). |
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
…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.
Top comments (9)
Check out this old article I wrote about object oriented thinking way back in 2005. I guess it's still relevant and would help newcomers.
walk2rem.blogspot.com/2005/10/what...
Thanks Manoj, I was looking for good resources to learn about UML, this article has the important 5 concepts I was looking for.
Thx for the good words. Am happy you found it useful.
if you want to learn OOP stay away from classes..classes are just a mechanism to create objects. Focus on objects and their interactions first...then think about classes later on. Design pattern is too much about classes..A good book for OOP is OOP roles, responsibility design by Rebecca which focus on objects and their roles, then design pattern for flow control...after that you can pick up DCI to rethink about the use of classes (less important).
happy OOP, always !!!
Would also like to get the corresponding pseudo code of the 6 points below, say in c# that will help to relate it more precisely.
Start the control program.
Instantiate the collection of students in the classroom.
Tell the collection to have the students go to their next class.
The collection tells each student to go to their next class.
Each student:
Finds where his next class is
Determines how to get there
Goes there
Done.
Will do later today. (it's a rainy morning in the UAE 😁).
Some dude created a TypeScript Design Patterns course a long time ago. Includes the code and YouTube Videos explaining it. mertarauh.com/tutorials/typescript...
His videos are excellent. The code snippets are great too. Thanks for sharing :D
It would be nice to see in the form or code what you mentioned above in the article.
I enjoyed reading it. Thank you and All the best.