I really don't get why the concept of a class upsets so many people, even experienced programmers as in this case. A class is a very lightweight container. Complaining about classes feels to me like complaining about having to use files to contain code.
Classes will give you no benefit if all you do in them is to declare "public static" methods. In OOP, you embrace abstraction and polymorphism. If you don't, there is no benefit. It's like using functional programming without immutability or pure functions - it makes no sense.
The reason why people are arguing so much about OOP and so little about other paradigms (e.g. functional programming) is that the benefit of OOP is much more subtle and less apparent as other paradigms. A good OOP design starts to pay off when you are dealing with large applications, large teams and numerous cross-cutting business requirements. That's why Java and C# are the most popular languages for application servers.
Modularity, abstraction, encapsulation, composition and polymorphism are the core ideas of OOP. Can you build software without them? Sure. Can you do all these things without an OOP language? Sure. OOP is an idea, a concept - not a language or an implementation. If you look at the linux kernel source code, I'm sure you will find plenty of these concepts, even though it's implemented in C.
Thanks for your input. I perfectly agree with you. But i feel that some people have misunderstood me. I wasn't asking the benefits of using OOP at all, just the benefits of exagerating with it.
Like, let's take for instance, the idea of a car. One might create a class Car with all it needs, while many others would create class Car + class SteeringWheel: derived from Car + class Wheels: Car + class Engine: Car + class OnlyThePlayButtonFromTheRadioPlayer: Car and so on and so forth.
I would say it really depends on the use case. If you are dealing with, say, an E-Bay like second hand shop, then modeling the steering wheel of a car as a separate class is definitly overkill. But if you are writing software for a car manufacturer, then it could be totally fine.
I'm not saying that this overkill never happens. Sadly it happens all too often. However, there are two things to consider here:
1) OOP does neither protect you from, nor does it encourage, over-engineering. You can over-engineer a C program, a Haskell program, you name it.
2) An experienced software engineer will not overdo it with classes - and in particular inheritance - when there is no need for it. The most over-engineered code I've seen is coming from junior developers and students. More experienced programmers tend to be pragmatic about it, and that's a good thing. Thankfully, we have very powerful refactoring tools these days. So even if your initial solution turns out to scale badly (e.g. maybe you used an Enum that you now have to constantly expand) you don't have to stick with it forever, you refactor the problematic part into a more elaborate solution. When people come looking at this code afterwards, they may think that it is over-engineered. But they were not aware of all the cases which caused you to refactor the "simple" code in the first place. It's often easy to call a solution over-engineered by looking at it for 5 minutes. But to give a definitive answer requires a very deep dive into all the use cases.
There is also a very large "gray zone" here where it isn't always clear at all if an abstraction is necessary or not. Some people would say that, for example, the Spring Framework is a total overkill in this regard. As somebody who uses a very large portion of it in my day-to-day work, I would argue that it is perfectly on point.
I really don't get why the concept of a class upsets so many people, even experienced programmers as in this case. A class is a very lightweight container. Complaining about classes feels to me like complaining about having to use files to contain code.
Classes will give you no benefit if all you do in them is to declare "public static" methods. In OOP, you embrace abstraction and polymorphism. If you don't, there is no benefit. It's like using functional programming without immutability or pure functions - it makes no sense.
The reason why people are arguing so much about OOP and so little about other paradigms (e.g. functional programming) is that the benefit of OOP is much more subtle and less apparent as other paradigms. A good OOP design starts to pay off when you are dealing with large applications, large teams and numerous cross-cutting business requirements. That's why Java and C# are the most popular languages for application servers.
Modularity, abstraction, encapsulation, composition and polymorphism are the core ideas of OOP. Can you build software without them? Sure. Can you do all these things without an OOP language? Sure. OOP is an idea, a concept - not a language or an implementation. If you look at the linux kernel source code, I'm sure you will find plenty of these concepts, even though it's implemented in C.
Thanks for your input. I perfectly agree with you. But i feel that some people have misunderstood me. I wasn't asking the benefits of using OOP at all, just the benefits of exagerating with it.
Like, let's take for instance, the idea of a car. One might create a class Car with all it needs, while many others would create class Car + class SteeringWheel: derived from Car + class Wheels: Car + class Engine: Car + class OnlyThePlayButtonFromTheRadioPlayer: Car and so on and so forth.
That's what i'm questioning.
Oh I see, I didn't get that part - sorry.
I would say it really depends on the use case. If you are dealing with, say, an E-Bay like second hand shop, then modeling the steering wheel of a car as a separate class is definitly overkill. But if you are writing software for a car manufacturer, then it could be totally fine.
I'm not saying that this overkill never happens. Sadly it happens all too often. However, there are two things to consider here:
1) OOP does neither protect you from, nor does it encourage, over-engineering. You can over-engineer a C program, a Haskell program, you name it.
2) An experienced software engineer will not overdo it with classes - and in particular inheritance - when there is no need for it. The most over-engineered code I've seen is coming from junior developers and students. More experienced programmers tend to be pragmatic about it, and that's a good thing. Thankfully, we have very powerful refactoring tools these days. So even if your initial solution turns out to scale badly (e.g. maybe you used an Enum that you now have to constantly expand) you don't have to stick with it forever, you refactor the problematic part into a more elaborate solution. When people come looking at this code afterwards, they may think that it is over-engineered. But they were not aware of all the cases which caused you to refactor the "simple" code in the first place. It's often easy to call a solution over-engineered by looking at it for 5 minutes. But to give a definitive answer requires a very deep dive into all the use cases.
There is also a very large "gray zone" here where it isn't always clear at all if an abstraction is necessary or not. Some people would say that, for example, the Spring Framework is a total overkill in this regard. As somebody who uses a very large portion of it in my day-to-day work, I would argue that it is perfectly on point.
And sometimes your program just needs to do enough things to warrant the number of classes.
Yes, I agree with this. It's important to strike a balance between the extensibility of the program and the mental overhead of numerous classes.