Once we understand the concept of Software Objects taking physical real life examples as I explained in previous Article, then we need to dive into their characteristics and behavior before we can effectively write Object Oriented Programs.


Object Oriented Programming (abbreviated as OOP) has 4 base principles:

  • Encapsulation
  • Abstraction
  • Inheritance
  • Polymorphism



If we take a look at Mary's Lunch Box, it contains these "Objects":

Water Bottle

The Apple "Object" contains these Properties:

    Object Name: "Apple"
    Object Color: "Red"
    Object Type: "Food"
    Object has Seeds? "Yes"
    Object Need to be refrigerated? "No"

The Sandwich is an "Object" made of another "Objects" and also it has its own "Properties":

Object "Sandwich":

    Object "Ham":
        Name: "Honey Ham"
        Type: "Food"
        Need to be refrigerated? "Yes"
        Total Amount: 10
        Unit of Measure: Slice
    Object "Bread":
        Name: "Full Grain Bread"
        Type: "Food"
        Need to be refrigerated? "No"
        Total Amount: 25
        Unit of Measure: Slice
    Object "Cheese":
        Name: "Cheddar Cheese"
        Type: "Food"
        Need to be refrigerated? "Yes"
        Total Amount: 12
        Unit of Measure: Slice
    Object "Lettuce":
        Object Name: "Iceberg Lettuce"
        Object Color: "Green"
        Object Type: "Food"
        Object has Seeds? "No"
        Total Amount: 50
        Unit of Measure: Portion
    Ham Slices Count: "Not Defined Yet"
    Bread Slices Count: "Not Defined Yet"
    Cheese Slices Count: "Not Defined Yet"
    Has Mayo?: "Not Defined Yet"


In OOP we call "Encapsulation" to the characteristic of an "Object" of containing "Properties", "Methods" or even other "Objects". 

OOP is about writing code using "Objects" to "Encapsulate" pieces of "Data" or fragments of "Code" in a well organized manner, so we can easily have access to these from anywhere in the Program.



If you think from Mary's stand point, she wants to get her Lunch Box out of her Backpack, and eat the food her Mom packed for her. She needs to execute these actions for eating the Sandwich:

- Get "Object" Lunch Box
- Open "Object" Lunch Box
- Get "Object" Sandwich
- Eat "Object" Sandwich

All the "Properties" and "Methods" used for making the "Object" Sandwich are not needed by Mary to eat the Sandwich, so all of them can be hidden or "Abstracted" in the "Object" Sandwich itself.

In most OOP Languages we declare these "Abstractions" using the word "private" and them are only accessible by the "Object" itself or we declare them as "protected" so them can be accessible to the object itself or their children.

 Because the purpose of OOP is to have code well organized and accessible everywhere, we use the concept of "Abstraction" to prevent misuse of "Objects'" "Properties" and "Methods" giving the Program consistency and integrity.



Mary's Mom packed her today a Banana and an Apple along with the Sandwich in her Lunch Box. Other days she packs other fruits, such like a Peach, a Pear, a Plum, a Tangerine, etc. Each of these Fruit "Objects" are having many of their "Properties" and "Methods" common to each other. So to not repeat many times the same "Property" or "Method" we place them in a Fruit "Object" that becomes the "Parent" and all fruits like the Apple and the Banana become the "Children". This way, the children may have only "Properties" or "Methods" that are exclusive to each one and have a "Parent" "Object" that shares the common "Properties" and "Methods" with them.

In most OOP Languages we declare a "Parent" using the word "extends", for example: "Object" Banana "extends" "Object" Fruit.



The Apple and the Banana that Mary carries in her Lunch Box are both Fruits and we can make these as Children of the "Object" Fruit. We can use something called "Interface" that is like a Blue Print that says which "Methods" and "Properties" an "Object" has to "Implement" to be part of this "Interface".

Lets say we declare the "Interface" Fruits that says that all "Objects" "implementing" it must have a "Method" called "getFruitName".

interface Fruits
   function getFruitName();

This way if we declare:

class Fruit implements Fruits

class Apple extends Fruit

class Banana extends Fruit


we know that all these has to have the "Method" called "getFruitName" regardless of which lines of code each one has within this "Method". These Apple and Banana "Objects" may use the "getFruitName" "Method" that its "Parent" must have or may "Override" it implementing their own "getFruitName" "Method".

So, in other part of the code we could have something like:

getTheSnacks(Fruits $fruit)
   print $fruit->getFruitName();

 We can pass to the "Method" "getTheSnacks" any $fruit "Object" that is "implementing" the "Fruits interface" and "getFruitName" will be there from it because we know it must be there, no matter the code that each fruit "Object" is using within its own implementation of the  "getFruitName" "Method".

Understanding these 4 OOP principles may take some time and lot of practice working with OOP programs, but is crucial for writing Enterprise Class Software Applications.