OOP Abstraction aka All You Need Are Stick Figures

I'm going to be honest, I still use stick figures 99% of the time I draw people.

It's not because I'm particularly bad at drawing (I've taken an art class or two), but for most of the diagrams or figures in which I need to represent a person, it's just not worth the effort trying to create a photorealistic person. As long as the audience understands it's a person, that's usually good enough.

2 legs, 2 arms, a torso and a head, and that's generally enough to get the idea of a "person" across. I may add extra details to specify gender or something, but only if I really have to.

Sure, I could worry about hairstyles, what the face looks like, hopes, dreams etc., but we don't need those things to visually understand an object is a person. We just need those few lines and a circle, arranged in a specific way.

Now I know this is supposed to be a technical post about Object Oriented Programming, not an art blog, but this is actually a perfect example of our next core concept in OOP: Abstraction!

The Devil is in the Details

The dictionary defines abstraction as:

abstraction
[ ab-strak-shuhn ]
noun
the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances.

*note this is actually the second definition on dictioary.com, but it's the useful one

In other words, we ignore all the details that makes up an individual, and focus only on the common properties and behaviors.

This should already sound familiar if you read the first two posts in this series, because that is exactly how we figure out what to include in our classes!

But abstraction goes even deeper than that. Or should I say shallower?

You see, since we're dealing with code, we're probably not going to be dealing with the objects visually. So even the details of what the object looks like, are probably unnecessary.

The only details. and therefore the only properties and behaviors, that we need to worry about are the ones that we're actually going to use!

For example, let's imagine we are going to use person objects in a program. These person objects are probably going to represent users, so let's abstract a person/user that might be used in a program.

We're probably not going to be looking at the person, so we can leave out anything related to the appearance of a person (number of legs, size, hair color, etc.)

Unless it's like a counseling program or something, we can probably leave out anything related to a person's internal state as well.

Actually, it'll be faster just to think about what details we do need, that all of our person/user objects will have in common.

One thing property that people have is a name. And it might be useful for our program so we can tell people apart.

class Person
    def initialize(name)
        @name = name
    end
end

Also, all the people in our program are going to do want to do something in our program, so that's a behavior detail they'll need.

class Person
    def initialize(name)
        @name = name
    end

    def do_something
        # does something in the program
    end

end

And you know what, I think that's it.

Just like with stick figures, we can add more stuff if we decide we need it, but as far as our app is concerned, a person can be as simple as "a thing, with a name, that does something".

Now that's abstract!

Conclusion

When it comes to coding, less is more. By abstracting away all the useless details from the real world, we can model just the things that are actually useful.