Joe Armstrong, the principal inventor of Erlang, is quoted as saying: "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.".

So, what´s wrong with the gorilla? Or the banana? Or the concept of OO?

Hopefully nothing. Let me show you a different view on the concept to see, how you could benefit from Objects and classes.

...my first object was a burden

If you are a web developer, maybe the first time you needed to use objects was in react like this:

class Welcome extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}</h1>;
  }
}

React uses inheritance like water. Now they invented React Hooks to get rid of all sorcerer's apprentice they have called.

But, why in hell do we need classes to say hello?

Well, maybe because in react you do not get a banana without a gorilla (does he not even look a bit like Mark Zuckerberg?). But this is not a fault of OO, it is more a result of over-use of a concept, that does not apply very well to the task.

Do not use concepts, that do not help...

The concept of OO was introduced with simula in 1962 and reused and extended by other languages like smalltalk (1972). There have been different ideas about OO programming concepts, but I will refer to the class concept we use in C++, Delphi or Javascript today.

One important rule is: Do not use any programming concept, that does not help to solve your problem. So, If you want a banana, do not buy a Jungle. Buy a banana. print("Hello World");

As long as you write small programs with some hundred lines of code you will probably be fine to write some useful functions. print() is a function provided by the operation system, but you may which to add your own functions. Calculate something that is not existing as a function? Add new functionallity? You will add more and more functions and procedures and variables and will easily get lost in your self grown jungle of spaghetti code. Today, we call this approach "procedural programming", as the name "functional programming" is already occupied.

When your program grows, is gets harder and harder to pick up all the loose ends, but the real hell starts, if you try to change something general. Finally your code gets unmaintainable and it is easier to write it from new. Object Orientation is just about solving this situation. It is a way to organize your code.

Encapsulation

The first approach to prevent unwanted results is to keep the context small. Objects are a world in it´s own, they have their private variables and procedures nobody else can change. Objects help you to protect your code against you! Classes typically implement only a hand full of functions (or methods if you like) and it is eays to keep an overview.

Inheritance

Inheritance is probably the most misunderstood concept of Object Orientation. Systems like the Windows GDI are often designed as deep class hierarchies. If you digg into one of the GDI-Objects, it implements tousands of functions inherited from the whole class tree. But - is this a burden?

Technically, inheritance is elegant. A class implements just a small number of new methods, but can access all the methods of their parents. It is just a pointer to the class definition of the parent. So, inheritance gives you access to an ecosystem without the need to implement anything new. This makes inherited objects not heavy, but very lightweight.

There is a second situation where you may benefit from inheritance. Maybe you have a group of objects, that need a very similar ability. Let say, they need to store their state. You may write a global function, but then you need to deal with all the different properties. If all your objects are childres of one parent class, you can implement the persistence there and let all your objects inherit this ability.

Often enough, a parent class will be created for this special purpose. It is possible, that the parent itself just defines a general algorithm and some useless methods that have to be filled by the children. This parent would be called an "abstract class", as it is not instantiated at all.

In some languages like C++, a class can inherit from multiple parent. If you think about inheritance als "giving access to", this makes absolutely sense, as you might want to have different abilitites at the same time. Inheritance is not a way to access an object, it is a way to share the abilities of it´s class.

Abstraction

There is an important difference between a class and an object. A class defines all the properties and methods of an object, but is not a living thing. Classes are more like "templates". So, a class is more a fictional version of the objects, that are instantiated from a class. This is one level ob abstraction.

In OO, another level of abstraction exists. You may implement am algorithm on abstract properties, hence properties you do not know. You can implement a function add(), but let the child classes decide, which data type add can use.

If we talk about abstraction, usually the second definition in used.

Polymorphism

Usually, Polymorphism is the ability of a function to handle different data types. In OO, it can also be the ability to have the same method name in different levels of inheritans with different abilities. Both ways can be useful, but not generic vor the concept of OO

Summary

I hope, you might see, that there are situations, where OO can be a real life saver. But it does not apply in any situation. Sometimes, functional concepts may be more useful.

OO methods are most powerful on large applications with many tousand lines of code. The concept forces you to think about the way to organize your code and it gives you the tools, to make it better. In most cases it is a really hard work to find a good and future proof class hierarchie. This shoud bring you a quick return of investment in form of a better maintainable code. In moste cases you will just see, that things get much easier, if your decision was right.

Object Oriented Programming can be very powerful. But there is absolute no sense in using concepts, that do not make your life easier.