Object Oriented Programming Pillar #1: Encapsulation

I was working with an IT person who was new to .Net and Object Oriented Programming (OOP). Since these were new concepts to my coworker, I thought they might be new to others as well and as such thought it’d be a good idea to spend a little time discussing them.

OOP has three basic concepts: Encapsulation, Inheritance, and Polymorphism. Let’s start today by going over the first, encapsulation. Encapsulation is a little like Las Vegas. What happens in a class, stays in a class.

Instead of reading the word encapsulation, instead substitute “self contained”. Your classes should be like a little black box. You can rewire the inside all you want, as long as the end results to the outside world look the same. Let’s look at an example, a simplified version of the classic employee class.

using System;

using System.Collections.Generic;

using System.Text;

 

namespace OOPDemo

{

  class Employee

  {

    private string _firstname;

    private string _lastname;

 

    public string FirstName

    {

      get

      {

        return _firstname;

      }

      set

      {

        _firstname = value;

      }

    }

 

    public string Lastname

    {

      get

      {

        return _lastname;

      }

      set

      {

        _lastname = value;

      }

    }

 

    public string FullName()

    {

      return _firstname + ” “ + _lastname;

    }

  }

}

 

I’ve kept it very simple, two properties and one method, FullName. Here’s a simple example of creating (aka instantiating) an employee object out of the employee class, loading it’s properties, then calling the FullName method.

 

      Employee emp1 = new Employee();

      emp1.FirstName = “Arcane”;

      emp1.Lastname = “Code”;

      MessageBox.Show(emp1.FullName(), “FullName Dialog”);

 

Now let’s suppose, for whatever reason we need to rewrite the FullName method. In my example, we’ll pretend like a new coding standard has emerged that says you can never return a calculated value (like we did in the first write) but instead place it into a variable before returning it. This allows us to view the final result in the method quite easily.

We can do so, without having to change the routine (above) that called it. Here’s a new version of FullName.

 

    public string FullName()

    {

      string returnValue;

      returnValue = _firstname + ” “ + _lastname;

      return returnValue;

    }

 

When you run the application again, it still works. The routine that creates the emp1 object doesn’t know, and doesn’t care how you wrote the FullName routine. As long as you don’t change the method’s signature, you are free to rewrite FullName to your hearts content. That’s the beauty of encapsulation.

Advertisement

One thought on “Object Oriented Programming Pillar #1: Encapsulation

  1. the word encapsulation, instead substitute self contained. Your classes should be like a little black box. You can rewire the inside all you want, as long as the end results to the outside world look the same….
    Thanks..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s