OOP is a hoax

I have heard many different introductions to object oriented programming, but today I read one of the worst:

This explanation is understandable when you already know how OOP works. But it’s also useless to explain the concept, because it only introduces technical terms without any context and motivation.

Usually an example would make things more clear, right? The example they provide is this:

Then it goes on with the source code, explanation of the syntax, the concept of inheritance and the concept of visibility.

Do you see why I consider this to be the worst first example of an OO class ever?

In which program would you create a class car with a property speed and a method to accelerate?

When you look at random job offers for programmers, most of the software that is created is merely data management; no matter if it’s offers and orders, customers and other users, articles and comments… in the end it’s about presenting the data that is already in the system, let the user browse and interact and create more data.

You can imagine plenty of systems that involve cars as data records, like a car rental system, ride sharing, workshop appointment planning etc. Each of those systems would need a class car to pass the objects around, but none of it would accelerate it.

What kind of software accelerates a car? The embedded code running in some component in a car? But why would that need a class to instantiate multiple different cars? It wouldn’t!

The only context I can think of where this class might make sense is a game or simulation that contains cars. But not only is this a rare edge case, also then the class car does not respresent a physical car in the real world; it would respresent a fictitiuos car in a simulated world. This adds an extra layer of abstraction, which makes it a bad example to explain the purpose of a concept to a beginner.

How does an author come up with an example that is more confusing than helping?

Well, I cannot read minds. But I remember the standard phrases

and

If you believe those sentences and you try to come up with a simple example, you may think of an arbitrary everyday object (car) and then look for something that classifies as behavior of that object (accelerate).

Makes sense?

I have bad news for you!

This is not how OOP is used in actual software.

All that kind of OOP examples of animals and their sounding behavior, students and their registering for classes behavior, bank accounts and their interest calculation behavior… are fake!

They sound persuasive when they are used to teach about the syntax of an OO language (you can actually write the classes that way) ore to teach you OOP class diagrams, because the diagrams look nice when you design you classes that way.
They are still wrong.

As I said, the state-plus-behavior classes may make sense in the context of games and programmimg frameworks, and I cannot judge other types of software that I don’t have a lot of experience in, like operating systems or graphics engines.

But in the wide field of business / data managing kind of software, you will typically find two different types of classes:

One type is the data container. It has a set of private properties and public accessors. It has constructors and utility functions like toString(), hashCode() and equals() in Java. But it does not have behavior!

The data container class is used to hold a record of data, that is read from somewhere and should be passed to somewhere else (e.g. user input to the database or data from a network call to display on the screen). This concept is not unique to OOP, it’s there in any procedural language and called struct or record or whatever. It bundles a set of data that belongs together.

Data transfer objects and JPA entities are these kind of data container. Don’t start to implement behavior in these classes!

The second type is pure behavior. It is a class with one or more public methods that take a certain input and provide a certain output, and in between there is logic. (We call that ‘business logic’ or ‘business rule’, even if it’s not about a business context in commercial sense, we consider the domain of the software its ‘business’.)

The business logic defines what the software does, how it behaves. Implementing the business logic means to define what happends to the input, how it’s processed, what is calculated, how is the result stored or presented. The data container classes are the input and output to the logic, and the logic is the whole purpose of the software.

In a typical architecure, the business logic is implemented stateless. That means, a specific input to the method of this class will always provide the same output, no matter how often you repeat it or if you use different instances of this class. The output only depends on the input, not on internal state.

This kind of logic class is often called a service or a use case. On the data access layer, you will find data access objects or repositories to communicate with the database or clients to communicate wit external systems; all of them fall into the second category.

Object oriented programming by the book asks you to bundle state and behavior into objects.

Practice asks you to cleanly separate state from behavior.

The book is a hoax.

Related posts:

Technology can not be blamed entirely if a crime helps it. The technology is simplified and simplifies the task. Therefore, we, as human beings, must rally the power of technology to make useful…

You can be taken off-guard by the ACT test, particularly the Math section. That is if you are not prepared. With all study tips and ACT practice tests out there, how do you get a good ACT Math score…