Encapsulate state and expose behavior when writing object-oriented code
Tags: coding, java, kotlin, c
Published: 2017-12-05 16:28:50

---
title: Encapsulate state and expose behavior when writing object-oriented code
published: true
description: 
tags: coding, java, kotlin, c# 
---

A-PIE. 

You ever heard of that? For some reason my mouth is watering.

![A delicious fresh-baked pie](https://thepracticaldev.s3.amazonaws.com/i/2i7wrncftg78xajwdwks.jpeg)

A-PIE is not only a delicious baked dessert with a flaky crust and a warm gooey inside, it's a little acronym/mnemonic to help remember the four most important principles of object-oriented programming (OOP):

- **A**bstraction.
- **P**olymorphism.
- **I**nheritance.
- **E**ncapsulation.

**Encapsulation** is what I want to talk about today. It seems like functional became the new exciting shiny thing and everyone forgot about OOP, even in OOP languages. Let's reset a little bit. If you write in an OOP language (which is a lot of them!), if OOP principles are baked into the design of your language, then one of the worst things you can do is forget them. That would be like holding a knife by the blade and trying to cut cheese with the handle. You're gonna get sliced!

Another way to say it is it's going to be like driving an '85 Honda Civic down the power line trail when there's a paved road right next to you. This is a story for another time, but a friend and I attempted this once and let me tell you from experience: it's not pretty unless you want to see some bent metal...

Sorry! Getting off track here. Let's get back to _encapsulation_.

So the concept of "data classes" has become quite vogue these days. [Kotlin has direct support for data classes](https://kotlinlang.org/docs/reference/data-classes.html) and Scala has _case classes._ These are JVM languages. Java has no direct equivalent, but it's interesting to note that both approaches are basically shortcut ways to create the classic _JavaBean_, which is a fancy word for a bag of data with public accessors and mutators.

C# gets at the same idea with _automatic properties_. If you look at the [documentation for automatic properties](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties), there's a prime example of the **fly in my ointment** today. In the example, a `Customer` class is defined, which is then mutated by code outside the class:

**Customer class**
```
// This class is mutable. Its data can be modified from
// outside the class.
class Customer
{
    // Auto-Impl Properties for trivial get and set
    public double TotalPurchases { get; set; }
    public string Name { get; set; }
    public int CustomerID { get; set; }

    // other code elided . . . 
}
```

**Program**:
```
class Program
{
    static void Main()
    {
        // Intialize a new object.
        Customer cust1 = new Customer ( 4987.63, "Northwind",90108 );

        //Modify a property
        cust1.TotalPurchases += 499.99;
    }
}
```

They even put a comment on there: _This class is mutable. Its data can be modified from outside the class._

Shame, shame, shame I know your name C#!!!!!!

This is simple **Object-Oriented 101!** When the goal is to track total purchases, expose that functionality as public behavior on the Customer class, and encapsulate the data needed to make the behavior possible. The code should look something like:

**Customer class**
```
// This class' data cannot be modified from outside the class.
class Customer
{
    private double TotalPurchases;
    private string Name;
    private int CustomerID;

    // other code elided . . . 

    public void AddPurchase( DollarAmount amt ) {
        TotalPurchase += amt;
    }
}
```

**Program**:
```
class Program
{
    static void Main()
    {
        Customer cust1 = new Customer ( 4987.63, "Northwind", 90108 );
        cust1.AddPurchase(499.99);
    }
}
```

See how the properties of the `Customer` class are now `private`, `private`, `private`?

That's right! You should **keep your privates private**. This is apparently not only _a lesson I have to keep teaching my two-year-old,_ but a _relevant_ and _timeless_ adage for programmers of all ages.

Now, there are all kinds of reasons for keeping your privates private. A big one is that this makes it easier for the program to evolve! It's very possible that we'll want to move on from tracking just a `DollarAmount` to something more in the future. We might perhaps want to store a whole list of transactions instead.

So I don't know about you, but I'd rather get a sharp poke in the eye than spend my afternoon tracking down all references to `TotalPurchases` and yanking them out of whatever tangled weeds another programmer lost them in. In a good OO design where we kept `TotalPurchases` private, it's a one-and-done change. I would simply update the innards of the `Customer` class and get all that evolution for free!

Of course, it's really _your choice._ No one can tell you how to write your code. If you don't think you're going to have trouble with "data classes" separate from "behavior classes" in your application, by all means make a good go at it. But trust me, even if it might be fun one time to see how it feels to stick your finger in a light socket, you're not gonna want to do it again. If I can help save you the trouble, then I'll feel like I did my job in writing this article. Best of luck!