In a Nutshell: Object-Oriented Programming Explained

In this article, we’ll take a look at the purpose of Object-Oriented Programming using an easy to understand example.

We’ll model a simple line item in a sales order. To start with, let’s define the SalesOrderLine class as:

And here is a code snippet that constructs and initialises a new SalesOrderLine:

It’s written in C# and is using a C# shorthand notation. However, please don’t let that turn you off if you are not a C# developer. The point of this article applies to any object-oriented programming language.

Here is another way of expressing this code without the shorthand notation:

Is there anything wrong here?

I think that there is a problem with this code — and it’s a biggie.

Let’s look at one more example. In the same application, another instance of SalesOrderLine is created and initialised. Here it is:

One problem we can identify with this last code snippet is that the programmer responsible forgot to set the formula for the Subtotal.

In general, the line items on a sales order have a subtotal value that is the result of multiplying the unit price by the quantity.

Unfortunately, in our last code snippet, the Subtotal for the SalesOrderLine instance is always initialised to 0. That’s a defect that could result in unexpected and significant consequences; Customers might receive free goods and services. Ouch!

We proceed to remedy this bug with an easy fix: Include the formula for the Subtotal when creating and initialising this instance of the SalesOrderLine, like so:

All good, right? Or is it?

Doesn’t it seem inefficient at best, and plain error-prone at worst, that we have to keep writing out the Subtotal formula whenever we are creating an instance of a SalesOrderLine?

That is not object-oriented programming; It’s procedural programming with an object-oriented language — What a waste!

With proper object-oriented programming, we can do so much better.

Here is an improved definition of SalesOrderLine:

And here is how it is called using the constructor:

What’s changed? Why is it better?

1. Read-Only Property — The Subtotal value is now a read-only property that calculates itself from the current values of UnitPrice and Quantity. Read-only means that we can’t set it; nor do we want to set this value.
2. Self-Management of State — The relationship between Subtotal, Quantity and UnitPrice is always the same. Quantity multiplied by UnitPrice equals the Subtotal. By introducing this constraint, this formula, on the Subtotal, its value is always correct.
3. Less Responsibility for Callers — If the object manages more of its state, then that correspondingly means that the calling code, the code that creates and uses SalesOrderLine objects, can be more straightforward. Why? Because it can be ignorant of SalesOrderLine inner workings. It can concentrate on accomplishing its responsibilities without having to concern itself with responsibilities that rightfully belong to other objects.

Conclusion

Object-oriented languages like C++, Jave or C# provide code reuse through objects that encapsulate and manage their own state. With the help of an example, we turned procedural code into object-oriented code.

If you enjoyed this article, please leave some claps — and a bunch of claps if you loved it! :) Thank you kindly.

Join my email list to fast-track your software engineering career.

When signing up, you’ll get my guide, ‘The Road to Master Progammer’, containing 3 powerful ideas to help you shorten your journey to expert programmer.