3 ms·
> Why is changing an integer to a class an improvement? Sorry, I should have said "extend" instead of "improve" which would have better captured my intent. My
by tcgv 6y ago
> Why is changing an integer to a class an improvement?
Sorry, I should have said "extend" instead of "improve" which would have better captured my intent. My bad.
> Within a class you have several entities that are managed by the class. I'm saying take away the management layer all together.
This is a central point in our disagreement, we have different strategies for handling this kind of business logic. From my OOP background I'm more comfortable abstracting the management logic required for running a jungle in a 'Jungle' class, which is the whole point of OOP. You prefer another approach, and that's all right.
> if you remove a banana you have to remove a gorilla too? What do you do? You edit the space station method to account for that.
Yes, if you have a requirement that in Space Stations the number of Gorillas should be proportional to the number of Bananas, you implement that specific behavior in the Space Station class.
> Suddenly the house class requires this too. How do you account for that in the house without copying your logic?
Ok, if more classes have the same requirement maybe it's not a specific behavior, but another abstraction, which could potentially be extract into a new component, mixin or an utility class.
> So Why not remove the concept of classes all together?
It's a design choice. I feel that OOP, when used properly, allows me to manage complex abstractions more easily.
> Not to mention that your style requires something called dependency injection which greatly complicates code.
Indeed, it requires dependency injection, along with all of the other SOLID [1] principles. But from my point of view it helps to manage and reduce complexity, not increase it, and I have even written about it in my blog [2] :)
> Why restrict the ability to reuse something? This is all a class does
Classes are intended to encapsulate behavior/knowledge, not to restrict the ability to reuse something. Even though you bring valid points to the conversation, I think you have a few misconceptions about the objectives of OOP. Here's another article I wrote describing what I believe to be the fundamental concept of OOP [3]
Lastly, I'm not here saying that OOP is better than Functional Programming. They are different things, both valid in their own domain (and also combined together in the case of OOP, which benefits from borrowing a few concepts from Functional Programming).
[1] https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID
[2] https://thomasvilhena.com/2019/07/integrating-third-party-modules https://thomasvilhena.com/2019/07/integrating-third-party-mo...
[3] https://thomasvilhena.com/2020/03/a-strategy-for-effective-system-modularization https://thomasvilhena.com/2020/03/a-strategy-for-effective-s...
- Geminidog 6y agoSure you can prefer OOP. But note your style requires additions and edits and refactoring to existing code. It also requires more code than typically needed. If that code is complex enough it could make refactoring a huge undertaking. The the non-oop style I illustrated there is no need for edits. All new features to code are basically plugins and additions no edits or refactoring needed. This is the ideal that modularity and re-usability strives for that typical OOP patterns fail to achieve. That is a concrete benefit outside of opinion. >I think you have a few misconceptions about the objectives of OOP. The objective of OOP has nothing to do with the actual consequences of it. You can state an objective for modularity and fail to achieve it. The simplicity of what I am saying is this. methods in OOP cannot be used outside of the context of an object. A function can be used everywhere. This is a concrete fact that methods are therefore less re-usable and less modular than pure functional combinators. >It's a design choice. I feel that OOP, when used properly, allows me to manage complex abstractions more easily. And my argument is that outside of your personal preference things are objectively worse as a result. There is logical proof that your choice is objectively less modular. Methods cannot be reused, unless you decide to take the entire jungle and inject it into another object just for the banana. Additionally: class Banana: int banana is objectively more complex than int banana It's redundant syntax when you encapsulate one entity under a class which is a concept designed to gorup multiple entities. >Ok, if more classes have the same requirement maybe it's not a specific behavior, but another abstraction, which could potentially be extract into a new component, mixin or an utility class. So you redesign your initial design. More edits and refactorings and assumptions until the code becomes so complex that one day you find you cannot do this. If you leave everything outside of classes you will find new features are just new additions to modular plug and play code. With OOP new features can end up being complete redesigns simply because the banana has to lug around the entire jungle and people end up needing to refactor the system so it doesn't do that. When a code base becomes large enough this is what most people end up doing refactoring logic that's tied up in a class so it can be used outside of the class. You can either make it a global function or tie it up into some other container like a mixin which leaves the problem of maybe one day a component of the mixin needs to be extracted.... They either do the above or they take on technical debt by replicating the logic elsewhere.