I´m not pretty sure If I would agree to all of your statemens.
First of all: There have been different approaches to OOP. Using messages was the way, smalltalk organized the object communication, but smalltalk was one of the first OO approaches ever. So, you can hardly say, it is the "modern approach". Objects in C++ or Delphi use method calls as the first way of communication. Many big applications implement a meassaging system, but this is not a core concept of the programming language. You could easily implement such an event system without objects. I do not think it is not defining the OO concept at all, if you use method calls or messages.
Secondly, things have nothing to do with objects. Not in the way, the "internet of things" does. OOP is about creating objects from classes. A class defines the behavoir of an object, while the object defines its own state. Classes can be derived from each other to inherit the structure and behavoir of a parent class. So I would agree that one core concept of OOP is to avoid redundancy. Every function should only be implemented once in a hierarchy.
The concept of "single responsibility" is shurely important. But you should be precise in the difference between classes and objects. A method should only be defined once in a class hierarchy, but there is absolutely no problem to have as many objects as you like. Many people new to OOP have problems to see the difference between classes and objects, so it is important to be clear in an explanation.
s = struggle
The real hard point in OOP is to build a class hierarchy, that is future poof. Making bad decisions in an early state of the design will be very hard to correct. I found myself several times to go two steps back because I found, that a decision was not good.
On the other hand, OOP allows to build your own abstraction layers to whatever tool you will need. If you cover your database interaction inside an object, it will be very easy to switch to another database, as you only need to change the covering class.
So, in my experience it is always a bit more effort to use OOP, and you should have good reasons to use it. On a long term, it often pays back, but not in any case. My rules of thumb are:
There is no good reason to use classes, if you will have only one object of this type
Building classes and modules will pay back, if you think you can use your classes somewhere else. So - try to be not too specific with your solution.
On a long term you will forget about the details of your program. Classes with well defined interfaces will help you to maintain your code.
Try to make your class methods fool-proof. You will be the fool that uses the class some time later.
Use comments wherever possible. Otherwise you will have to decode your code to find out, what it was made for. Class interfaces need special attention to describe all methods and their parameters in a way, other people could use your class.
Overall I like to see more people gaining interest in OOP methods. They can be a real life saver for larger projects, as they allow to reduce the size of your problem, so that it finally fit´s into one brain!
Thank you for your post!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I´m not pretty sure If I would agree to all of your statemens.
First of all: There have been different approaches to OOP. Using messages was the way, smalltalk organized the object communication, but smalltalk was one of the first OO approaches ever. So, you can hardly say, it is the "modern approach". Objects in C++ or Delphi use method calls as the first way of communication. Many big applications implement a meassaging system, but this is not a core concept of the programming language. You could easily implement such an event system without objects. I do not think it is not defining the OO concept at all, if you use method calls or messages.
Secondly, things have nothing to do with objects. Not in the way, the "internet of things" does. OOP is about creating objects from classes. A class defines the behavoir of an object, while the object defines its own state. Classes can be derived from each other to inherit the structure and behavoir of a parent class. So I would agree that one core concept of OOP is to avoid redundancy. Every function should only be implemented once in a hierarchy.
The concept of "single responsibility" is shurely important. But you should be precise in the difference between classes and objects. A method should only be defined once in a class hierarchy, but there is absolutely no problem to have as many objects as you like. Many people new to OOP have problems to see the difference between classes and objects, so it is important to be clear in an explanation.
s = struggle
The real hard point in OOP is to build a class hierarchy, that is future poof. Making bad decisions in an early state of the design will be very hard to correct. I found myself several times to go two steps back because I found, that a decision was not good.
On the other hand, OOP allows to build your own abstraction layers to whatever tool you will need. If you cover your database interaction inside an object, it will be very easy to switch to another database, as you only need to change the covering class.
So, in my experience it is always a bit more effort to use OOP, and you should have good reasons to use it. On a long term, it often pays back, but not in any case. My rules of thumb are:
Overall I like to see more people gaining interest in OOP methods. They can be a real life saver for larger projects, as they allow to reduce the size of your problem, so that it finally fit´s into one brain!
Thank you for your post!