OOP Encapsulation aka Wrap it Up

Last time when we talked about objects, I mentioned that an object can be considered as a bundle of properties and behaviors. This time, we're going to take that idea even further and look at the concept of encapsulation.

Encapsulation

When we think of an object, real or imaginary, physical or code. The first thing we need to do is separate it from the rest of existence. What I mean, is that in order to create the concept of an object, let's just say a smartphone, you simultaneously create the concept of "not a smartphone". There is a distinction made between the objects that have the properties and behaviors of smartphones, and basically everything else.

This is just another way of saying that and object is a group of properties and behaviors, but the focus is in the grouping process.

The non-computer definition in the dictionary for Encapsulation is, "the action of enclosing something in or as if in a capsule". Obviously, that's not exactly what we want, but if you think about it, it's a lot closer than you might think. We might not be using a capsule per say, but we are definitely enclosing things.

In this case, the "capsule" is the idea of the object itself. You can think of the object as a capsule containing properties and behaviors. Which properties and behaviors are encapsulated are what define the object.

Hiding Data

When it comes to the properties of objects, usually it's considered poor design to interact with property values directly. It may not be obvious, but this is also a part of the concept of encapsulation.

For example, let's take a tree as our object. A tree has properties such as species, height, age, etc. Now, while a tree definitely has those properties, how can we, as people (aka separate objects) access those properties? We don't get to just know those things, we have to do something (look, measure, etc.) in order to gain access to those properties.

Also, remember that doing something is more like a behavior, or in the case of code, a method. So, we have to use methods in order to read or change the values of object properties.

class Tree

   def initialize( tree_params ) #tree_params is a hash
      @height = tree_params[:height]
      @species = tree_params[:height]
      @age = tree_params[:height]
   end


end

This makes sense in the real world, too. You don't get to just know the information in a book, you have to read it. You don't get to automatically know what color a car is, you have to look at it!

Getters and Setters

In the real world, we have lots of complex behaviors and actions that we can take when interacting with objects. If we want to know the age of the tree from earlier, for example, we might have to cut it down and count the rings. Or, we could measure the trunk diameter and do some science.

While methods in code can also be very complex, when it comes to accessing properties of other objects, we have much more power than in the physical world.

We can simply ask an object about a property, or tell it to change. It would be like going up to the tree, asking it's age, and then knowing it's 116 years old. Or, it would be like telling the tree to become a palm tree.

class Tree

   def initialize( tree_params ) #tree_params is a hash
      @height = tree_params[:height]
      @species = tree_params[:height]
      @age = tree_params[:height]
   end

   def get_age
     return @age
   end

   def set_age(age)
      @age = age
   end

   def set_species(species)
     @species = species
   end


# I used get_ and set_ in the method declarations to help
# illustrate getters v setters. 

end

In code, these methods are extremely common and are an important part of encapsulation. Methods that asking an object about it's properties are called "getters" (because they get the value from the object) and methods that tell that value to change (usually by directly giving a replacement value) are called "setters"

Encapsulation Conclusion

By restricting access to properties (and internal behaviors as well) through getters and setters, and by combing them into more complex behaviors, we are able to create object models that are useful and behave predictably.

From there, the fun can start