5 ms·

Another solution is to eliminate classes and only use structs or similar plain objects. Makes mocking and testing functions much easier. At this point I see no

Another solution is to eliminate classes and only use structs or similar plain objects. Makes mocking and testing functions much easier. At this point I see no reason for OOP whatsoever and consider it a big mistake.

adlpz 4y ago
I agree with OOP not being needed at all, but I don't agree on this being an alternative to dependency injection. However you structure it, there will always be "glue code" that ties the nice inmutable code with the outside-interacting bits, and if you want to unit test those, dependency injection (with functions or state, not classes or instances) is still the way to go.
- mrloba 4y ago
  True, but there might not be a big need for unit testing the glue code. By its very name it doesn't contain much logic to test. Integration tests are more valuable in this case.
sanderjd 4y ago
This seems totally orthogonal to me. Using a totally non-OOP functional style, you can either instantiate state within a function or pass it in from the calling context, which is the same trade-off that dependency injection targets.
- monero-xmr 4y ago
  If you work on a legacy code base with tens of many millions of lines of code, the non-OOP will be a better code base. My opinion.
  - sanderjd 4y ago
    I wasn't disagreeing (or agreeing) with that opinion. It's just orthogonal to whether or not dependency injection is a useful approach.
optymizer 4y ago
Getting rid of data abstraction and encapsulation is throwing the baby with the bath water. The abstract concept of OOP (messages between complex objects, as defined by Alan Kay) is an attempt at mimicking biological systems. Most modern languages implement data abstraction, but call it OOP, where they encapsulate some functionality with the data it operates on. Really helped with varying data formats in the AirForce in the 60s, apparently. There isn't anything wrong with this abstract concept either - it's a way of structuring a solution, with trade-offs. Support for unit testing and mocking has little to do with OOP, and everything to do with the underling platform. Both C++ and Java, for example, do not have a special runtime mode where arbitrary replacement of code or data could occur. This is necessary for mocking functionality that is considered implementation detail and hidden by design. The hidden part is great for production code, not great for testing. For example, if an object in java has a field like 'private final HttpClient client = new CurlBasedHttpClient();' this code is essentially untestable because there is no way in Java to tell the JVM "during testing, when this class instantiates an HttpClient, use my MockHttpClient". Kotlin fixed some of that with MockK, which can mock the constructor of a Kotlin object, and you can return your mock implementation when the constructor is invoked. Clearly, it's a platform issue. There could be a world where you could replace any object in the stdlib or any method or field with a mock version. JavaScript is much more flexible in that regard, which is why unit testing js code is much easier. The root of it all stems from the fact that unit tests need to change some implementation details of the world around the object, but production code should not be able to, in order to get all the benefits of encapsulation. If you get rid of modern OOP, you are swinging the pendulum in the opposite direction, where your tests are easy to write on any platform, because everything is open and easily accessible, but your code will suffer from issues that creep up when structures are open and easily accessible, such as increased coupling and reduced cohesion.
- monero-xmr 4y ago
  I believe that combining state and functionality - the root of OOP - is a mistake. Tons of programming patterns and concepts exist to solve this fundamental mistake. When you stop using classes all of your code becomes so much cleaner, easier to reason about, test, debug, and so on. You can never create only pure functions in the real world but you get closer to this ideal. I stand by my statement that OOP is totally unnecessary.
deleted 4y ago
[deleted]
alpaca128 4y ago
OOP tends to encourage thinking in more abstract ways than is often necessary imho. I feel like learning a language with only structs had a positive effect on my coding ability (as someone who more or less started with Java). The few times I had to use Java afterwards I felt the same - all OOP features were unnecessary or at least didn't feel like the most straightforward approach. Nowadays I never use classes in Python, JS etc., it's just not needed - and in the case of Python it makes JSON insanely cumbersome.

adlpz 4y ago

I agree with OOP not being needed at all, but I don't agree on this being an alternative to dependency injection. However you structure it, there will always be "glue code" that ties the nice inmutable code with the outside-interacting bits, and if you want to unit test those, dependency injection (with functions or state, not classes or instances) is still the way to go.

mrloba 4y ago
True, but there might not be a big need for unit testing the glue code. By its very name it doesn't contain much logic to test. Integration tests are more valuable in this case.

sanderjd 4y ago

This seems totally orthogonal to me. Using a totally non-OOP functional style, you can either instantiate state within a function or pass it in from the calling context, which is the same trade-off that dependency injection targets.

monero-xmr 4y ago
If you work on a legacy code base with tens of many millions of lines of code, the non-OOP will be a better code base. My opinion.
- sanderjd 4y ago
  I wasn't disagreeing (or agreeing) with that opinion. It's just orthogonal to whether or not dependency injection is a useful approach.

optymizer 4y ago

Getting rid of data abstraction and encapsulation is throwing the baby with the bath water. The abstract concept of OOP (messages between complex objects, as defined by Alan Kay) is an attempt at mimicking biological systems. Most modern languages implement data abstraction, but call it OOP, where they encapsulate some functionality with the data it operates on. Really helped with varying data formats in the AirForce in the 60s, apparently. There isn't anything wrong with this abstract concept either - it's a way of structuring a solution, with trade-offs. Support for unit testing and mocking has little to do with OOP, and everything to do with the underling platform. Both C++ and Java, for example, do not have a special runtime mode where arbitrary replacement of code or data could occur. This is necessary for mocking functionality that is considered implementation detail and hidden by design. The hidden part is great for production code, not great for testing. For example, if an object in java has a field like 'private final HttpClient client = new CurlBasedHttpClient();' this code is essentially untestable because there is no way in Java to tell the JVM "during testing, when this class instantiates an HttpClient, use my MockHttpClient". Kotlin fixed some of that with MockK, which can mock the constructor of a Kotlin object, and you can return your mock implementation when the constructor is invoked. Clearly, it's a platform issue. There could be a world where you could replace any object in the stdlib or any method or field with a mock version. JavaScript is much more flexible in that regard, which is why unit testing js code is much easier. The root of it all stems from the fact that unit tests need to change some implementation details of the world around the object, but production code should not be able to, in order to get all the benefits of encapsulation. If you get rid of modern OOP, you are swinging the pendulum in the opposite direction, where your tests are easy to write on any platform, because everything is open and easily accessible, but your code will suffer from issues that creep up when structures are open and easily accessible, such as increased coupling and reduced cohesion.

monero-xmr 4y ago
I believe that combining state and functionality - the root of OOP - is a mistake. Tons of programming patterns and concepts exist to solve this fundamental mistake. When you stop using classes all of your code becomes so much cleaner, easier to reason about, test, debug, and so on. You can never create only pure functions in the real world but you get closer to this ideal. I stand by my statement that OOP is totally unnecessary.

deleted 4y ago

[deleted]

alpaca128 4y ago

OOP tends to encourage thinking in more abstract ways than is often necessary imho. I feel like learning a language with only structs had a positive effect on my coding ability (as someone who more or less started with Java). The few times I had to use Java afterwards I felt the same - all OOP features were unnecessary or at least didn't feel like the most straightforward approach. Nowadays I never use classes in Python, JS etc., it's just not needed - and in the case of Python it makes JSON insanely cumbersome.