Friday, September 7, 2012

Object Oriented Programming Analogy

I have started to learn Object Oriented Programming. It seems like it was really a long cycle because there is something about Procedural Programming that totally is different from Obejct Oriented Programming. Most human thinks in a procedural way. For example:

  • What are the steps in cooking? 
  • What are the steps in creating a site? 
  • What are the steps to gain muscles? 
  • What are the ways to get healthy?
  • How to drive a car, and so on...

Steps and ways rules the world. But not really...

If you're going to think about it deeper, Industrialism says a lot about Object Oriented Programming. People will only be able to communicate efficiently if they are in one company where each people play different roles. In Object Oriented Programming, one class is considered one employee. One method is considered one skill or one process. One package is considered one company.

A manager for instance thinks about the goal first. Let us say the goal is to create a computer. Then, he asks the questions: What are the things that he needs to build a computer? Well, he needs people! One person to receive and order the parts, one person to construct or assemble the computer, and one person to check if the quality of the computer is well built.

Person/Employees can be considered one class in a project. If we are going to build using Object Oriented Programming, we should think like a manager.

  1. The Person/Employee/Class that receives the order, for instance, has these methods that will make sure that: 
    • the order is completely defined when it orders an item. 
    • As soon as it receives the orders, it will make sure that the quantity is correct
    • it will make sure that the quality is correct
    • it will also make sure that the precision of what the order was is correct. 
    • It will return an error otherwise.
  2. The Person/Employee/Class that will assemble the order will make sure that the
    • parts of a computer are complete before it starts building the computer.
    • Part by part and layer by layer it will build the computer, both software and hardware. 
    • It then puts the computer for checking.
  3. The Person/Employee/Class that will act as the Quality assurance should be the one to. 
    • Check if the assembled computer is acceptable, 
    • There are certain limits that the Quality Assurance needs to check, 
      • such as: the right casing precision measurement without gaps in between layers when attached together, 
      • checking if the computer turns on, 
      • and checking if the computer was loaded with the right Operating Sytem successfully without any errors.

Note: I have arranged the Class and Methods above wherein the Class is in a numbered list, and Methods in a bulleted list.

Without all of these three Person/Employee/Class, the goal is never achieved, because they do not communicate. They cannot create a computer.

Note also, that a Person/Employee/Class may be substituted with other Companies/Packages' Person/Employee/Class that may have a different Skill/Process/Method.

Sometimes, once you come back after a month or weeks of programming, some method is already forgotten, you'll have a hard time puzzling what you wrote.

So there are few things that you are going to need to consider to program efficiently with Object Oriented Programming:

  • First thing is to imagine the goal.
  • Second is to make a flow of how each object will communicate.
  • Third thing is to make sure that you understand one Skill/Process/Info/Method
  • Last is to make sure that you finish or understand one flow of steps, not just part of a flow, before forgetting it entirely.
Another Way:
Another way of looking at object oriented programming could be just as simple as methods are equivalent to functions. In PHP for instance, mysql_query() function can be similar to mysql->query() method. The only difference would be that using mysql->query() method for a different class can be extended or replaced to do something else if it does not belong to 'mysql' class anymore. Just like a flow of Skill/Process/Method can vary to every Person/Employee/Class.

No comments: