6 ms·

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 d

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.
- optymizer 4y ago
  You can believe that the world is flat, announce that boldly and stand by your statement. It doesn't mean it's true in reality, only that it's true in your mind. Edit: This is more blunt than I intended it to be. For what it's worth, I happen to agree with you in principle, but I also think you're taking the roof off the car here and boldly claiming that the experience is so much better in the summer. What about winter? What about when it rains? What are the trade-offs? Not mentioning the downsides means that you either haven't found them, haven't thought about them or are intentionally omitting them from the discussion.
  - rramadass 4y ago
    No need to tone it down; You were right in calling out the GP. To dismiss the whole of OOD/OOP so cavalierly just goes to show they don't know what they are talking about. Much of the success of Modern Software is directly due to the wholesale adoption of OOD/OOP in the last few decades.
    - monero-xmr 4y ago
      OOP is successful despite of itself. My point is it’s just an inferior way of programming and there is no reason to use it other than legions of OOP programmers who take it as gospel. Obviously this is an opinion but it’s informed by lots of experience in new and legacy code bases.
      - rramadass 4y ago
        To be blunt, you are stating "opinions" without any basis in facts; hence it is hard to take you seriously. Separation of Concerns, Modularization, Reusability, Type Hierarchies, Type Composition, Interface contract-based programming, Frameworks etc. were all made mainstream by OOD/OOP. These are things taken for granted by programmers today. As somebody who has been doing OOD/OOP since the early nineties i can tell you it was the single biggest reason for the explosion of Software in the past few decades. As a concrete example, early in my career i had programmed in C using the Windows API; both 16-bit and Win32 (Thank you Charles Petzold). It was difficult, tedious and a lot of work. And then Microsoft introduced MFC (Microsoft Foundation Classes) Framework with Visual C++ IDE. With a few clicks of the wizard, i had a complete skeleton application with a lot of hard work already done for you. That was a revelation for me on the power of OOD/OOP. Things i had slaved over in Win32 was now at the fingertips of every noob who could type. The same revelation happened (but not to the same extent) when i moved from Xlib to Motif on Unix platforms. I had pointed you to Bertrand Meyer's book OOSC2 (in my other comment) as the book to read to understand OOD/OOP. Another great book to study is Barbara Liskov and John Guttag's Program Development in Java: Abstraction, Specification, and Object-Oriented Design.
Olreich 4y ago
Recursion is an obfuscated way to run a loop with a stack. At first it seems like magic, and makes things so much easier. When trying to replicate it the first time actually using a loop and stack it’s really hard to get right. But by the time you’ve done it two or three times, it’s as easy as breathing. Similar, OOP is an obfuscated way to run a function with a context. The first time you separate the data in the context from an object, it’ll be hard to get it right and make it easier than to just use Objects and Methods. But once you’ve done it two or three times, it’s as easy as breathing. You can optimize loading the context to be better than copying a bunch of unaligned data in lots of ways, but polymorphism is a common way to get there.
taffer 4y ago
OOP does not have a monopoly on abstraction and encapsulation. What OOP does, namely object-level encapsulation, is just a very extreme way of structuring code around mutable state. IMO the better alternative is to avoid mutable state as much as possible and keep data and code separate. Code structured as pure functions is easy to test and encapsulation can be done at the module level.
- optymizer 4y ago
  My point is that improving the state of unit testing has little to do with OOP, and everything to do with the environment that the code runs in.
- kagakuninja 4y ago
  OOP does not require mutable state. OOP has its origins in imperative languages, and so in the past OOP often involved poor management of mutable state. I am a Scala programmer, and our code mixes OO and FP. Almost all of our classes are completely immutable. In the end, you will always need to encapsulate data and functions in some manner. The FP approach involves module systems, but as I understand it, objects in Scala actually provide a better module system than found in pure FP languages.

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.

optymizer 4y ago
You can believe that the world is flat, announce that boldly and stand by your statement. It doesn't mean it's true in reality, only that it's true in your mind. Edit: This is more blunt than I intended it to be. For what it's worth, I happen to agree with you in principle, but I also think you're taking the roof off the car here and boldly claiming that the experience is so much better in the summer. What about winter? What about when it rains? What are the trade-offs? Not mentioning the downsides means that you either haven't found them, haven't thought about them or are intentionally omitting them from the discussion.
- rramadass 4y ago
  No need to tone it down; You were right in calling out the GP. To dismiss the whole of OOD/OOP so cavalierly just goes to show they don't know what they are talking about. Much of the success of Modern Software is directly due to the wholesale adoption of OOD/OOP in the last few decades.
  - monero-xmr 4y ago
    OOP is successful despite of itself. My point is it’s just an inferior way of programming and there is no reason to use it other than legions of OOP programmers who take it as gospel. Obviously this is an opinion but it’s informed by lots of experience in new and legacy code bases.
    - rramadass 4y ago
      To be blunt, you are stating "opinions" without any basis in facts; hence it is hard to take you seriously. Separation of Concerns, Modularization, Reusability, Type Hierarchies, Type Composition, Interface contract-based programming, Frameworks etc. were all made mainstream by OOD/OOP. These are things taken for granted by programmers today. As somebody who has been doing OOD/OOP since the early nineties i can tell you it was the single biggest reason for the explosion of Software in the past few decades. As a concrete example, early in my career i had programmed in C using the Windows API; both 16-bit and Win32 (Thank you Charles Petzold). It was difficult, tedious and a lot of work. And then Microsoft introduced MFC (Microsoft Foundation Classes) Framework with Visual C++ IDE. With a few clicks of the wizard, i had a complete skeleton application with a lot of hard work already done for you. That was a revelation for me on the power of OOD/OOP. Things i had slaved over in Win32 was now at the fingertips of every noob who could type. The same revelation happened (but not to the same extent) when i moved from Xlib to Motif on Unix platforms. I had pointed you to Bertrand Meyer's book OOSC2 (in my other comment) as the book to read to understand OOD/OOP. Another great book to study is Barbara Liskov and John Guttag's Program Development in Java: Abstraction, Specification, and Object-Oriented Design.

Olreich 4y ago

Recursion is an obfuscated way to run a loop with a stack. At first it seems like magic, and makes things so much easier. When trying to replicate it the first time actually using a loop and stack it’s really hard to get right. But by the time you’ve done it two or three times, it’s as easy as breathing. Similar, OOP is an obfuscated way to run a function with a context. The first time you separate the data in the context from an object, it’ll be hard to get it right and make it easier than to just use Objects and Methods. But once you’ve done it two or three times, it’s as easy as breathing. You can optimize loading the context to be better than copying a bunch of unaligned data in lots of ways, but polymorphism is a common way to get there.

taffer 4y ago

OOP does not have a monopoly on abstraction and encapsulation. What OOP does, namely object-level encapsulation, is just a very extreme way of structuring code around mutable state. IMO the better alternative is to avoid mutable state as much as possible and keep data and code separate. Code structured as pure functions is easy to test and encapsulation can be done at the module level.

optymizer 4y ago
My point is that improving the state of unit testing has little to do with OOP, and everything to do with the environment that the code runs in.
kagakuninja 4y ago
OOP does not require mutable state. OOP has its origins in imperative languages, and so in the past OOP often involved poor management of mutable state. I am a Scala programmer, and our code mixes OO and FP. Almost all of our classes are completely immutable. In the end, you will always need to encapsulate data and functions in some manner. The FP approach involves module systems, but as I understand it, objects in Scala actually provide a better module system than found in pure FP languages.