Object Oriented Programming : for self taught developers.
Tags: javascript, beginners, typescript, oop
Published: 2020-01-11 14:51:00

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).

| This Object      | Is Responsible For       |
| :--------------- | :----------------------- |
| Student          | <li>Knowing which classroom they are in Knowing which classroom they are to go to next.</li> <li>Going from one classroom to the next Instructor.</li><li> Telling people to go to next classroom </li> 
| 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:

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.

***

<p>
  <h2 align="center">Object-Oriented Terminology</h1>
</p>

| <h4>Term</h4>  | <h6>Definition</h6>                                                          |
| :------------: | :--------------------------------------------------------------------------- |
| <h4>Abstract class</h4> | <h6>Defines the methods and common attributes of a set of classes that are conceptually similar. Abstract classes are never instantiated.</h6>| 
| <h4>Attribute</h4>      | <h6>Data associated with an object (also called a data member).</h6>|
| <h4>Class</h4>          | <h6>Blueprint of an object—defines the methods and data of an object of its type.</h6>|
| <h4>Constructor</h4>    | <h6>Special method that is invoked when an object is created.</h6>|
| <h4>Encapsulation</h4>  | <h6>Any kind of hiding. Objects encapsulate their data. Abstract classes encapsulate their derived concrete classes.</h6>|
| <h4>Derived class</h4>  | <h6>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.</h6>|
| <h4>Destructor</h4>     | <h6>Special method that is invoked when an object is deleted.</h6>|
| <h4>Functional decomposition</h4> | <h6>A method of analysis in which a problem is broken into smaller and smaller functions.</h6>|
| <h4>Inheritance</h4>   | <h6>The way that a class is specialized, used to relate derived classes from their abstractions.</h6>| 
| <h4>Instance</h4>      | <h6>A particular object of a class.</h6>|
| <h4>Instantiation</h4> | <h6>The process of creating an instance of a class.MemberEither data or method of a class.</h6>|
| <h4>Method</h4>        | <h6>Functions that are associated with an object.</h6>|
| <h4>Object</h4>        | <h6>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.</h6>| 
| <h4>Polymorphism</h4>  | <h6>The ability of related objects to implement methods that are specialized to their type.</h6>|
| <h4>Superclass</h4>    | <h6>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).</h6>|

***

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.

{% github MidasXIV/Design-Patterns-in-TypeScript %}

**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`](https://g.co/kgs/U8LUDJ) Book by `Alan Shalloway` and `James R. Trott`.

***

Happy coding :D.

***