5 ms·

>Object oriented programming, polymorphism in particular, is essential to nearly any large, complex software system. Without it, decoupling different system com

by andai 3y ago

>Object oriented programming, polymorphism in particular, is essential to nearly any large, complex software system. Without it, decoupling different system components is difficult. (Update in 2017: I no longer agree with this statement.) The author doesn't seem to elaborate on this. I was taught OOP in university and then promptly learned that it's frowned upon in performance sensitive code, which is my main interest in programming. (And that it apparently doesn't even achieve its stated goal of making the code easier to understand -- I've certainly had the experience of wading through a deep inheritance hierarchy (or call stack) looking for the "actual code that actually runs"...) I'd love to hear an elaboration on that idea (OOP is essential for decoupling components) and its counterargument (decoupling can apparently be done just fine without OOP?).

tus666 3y ago
> is essential to nearly any large, complex software system > in performance sensitive code Those two things are not the same.
- billforsternz 3y ago
  The question you're responding too already makes it clear those things are quite different, perhaps even orthogonal.
randomdata 3y ago
Central to OOP is message passing between objects. Few languages utilize message passing, so it seems you can decouple components without OOP just fine.
- andai 3y ago
  >Few languages utilize message passing Yet most of them call themselves object-oriented! I'm reminded of the Alan Kay quote, "I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind."
  - alex_smart 3y ago
    Is Smalltalk’s message passing really all that different from methods from other OOP languages? Seems like quite an arbitrary distinction to me.
    - randomdata 3y ago
      All OOP languages use message passing, but perhaps you mean languages with objects that are not oriented? While not completely identical to Smalltalk's message passing design, the Qt project once went to all the trouble of building their own compiler just to be able to graft message passing onto C++. I think that goes to show that there really is a difference – otherwise, why not use the standard constructs C++ offered? Whether or not that difference makes for better software is debatable. It does seem that at one time it did lend itself exceptionally well to GUI programming. NeXTSTEP/macOS/iOS also would never have been what they are without OOP. But we've also learned some programming tricks along the way, so it may not even shine there anymore. Swift, for example, has given up on OOP (except where @objc mode is enabled) and it seems like it manages to do quite well with GUIs (granted, having @objc mode to fall back on clouds that somewhat).
      - alex_smart 3y ago
        I mean that, to me, the difference between message passing and method calling is not significant enough to say that these languages are following different programming paradigms - like you say OOP vs languages with objects. Afaict the difference between Smalltalk and Objective-C style message passing and Java and C# style method calling is purely syntactic.
        randomdata 3y ago
        > Afaict the difference between Smalltalk and Objective-C style message passing and Java and C# style method calling is purely syntactic. doesNotUnderstand:/forwardInvocation: isn't different? That is not just syntactical. How would you even begin to orient your objects without like functionality? I agree that if you squint really hard they look the same. But if we say "they are all the same", what are you trying to communicate when you say OOP? Virtually all programming languages we use have objects. You may as well drop the OO and just use "programming". It would communicate the same intent.
WalterBright 3y ago
I've also seen template hierarchies so deep it was a major effort trying to figure out which template did anything besides forward to another template.
- DontchaKnowit 3y ago
  Ugh yes. This has beeb my experience with Java code in large corporate projects. Just endless layers of seemingly pointless abstraction
  - mpweiher 3y ago
    Yep, that's because indirection is a necessary tradeoff for implementing OO systems in languages that don't fully support it, which surprisingly includes all current OO languages. People then get confused and think that indirection is the point. It's not. It would be better if the indirection weren't needed and we could express more than just procedural abstraction in our PLs.
whatsakandr 3y ago
I've found OOP can increase coupling. I actually have this problem at work. Say I have class A and B. I could write `int x = A:FunctionOfAandB(B b)`, but in this case. So now A depends on B. It would be much preferable to have free function of A and B. A and B are no longer dependent on each other, just the function to compute the result dependent on A and B. IMO: The real thing of value OOP provides is calling with object.method. A lot of OOP code looks like `void obj.mutate()`. If you pulled that to what's really happening in "procedural" syntax, `mutate(obj)`, that exposes it for the bad code it is.
- andai 3y ago
  >The real thing of value OOP provides is calling with object.method. A lot of OOP code looks like `void obj.mutate()`. If you pulled that to what's really happening in "procedural" syntax, `mutate(obj)`, that exposes it for the bad code it is. I'm confused here, are you saying there is value in the object.method() syntax? D language for example has Uniform Function Call Syntax[0] where f(x) can be written as x.f() (I missed this syntax in C, and tried to approximate it by putting functions in structs, but you still have to pass the caller as an arg so it ends up being player.update(player) which looks stupid, so at that point player_update(player) seems an acceptable alternative) Later you say obj.mutate() is bad code, are you referring only to methods which mutate the object? [0] https://tour.dlang.org/tour/en/gems/uniform-function-call-syntax-ufcs https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...
- deleted 3y ago
  [deleted]
_dain_ 3y ago
This video has a pretty good breakdown of how the "encapsulation" and "decoupling" promised by OOP is mostly a mirage: https://youtu.be/QM1iUe6IofM?si=4GrOhZ31esd7rDSN&t=1089 https://youtu.be/QM1iUe6IofM?si=4GrOhZ31esd7rDSN&t=1089
rramadass 3y ago
> I'd love to hear an elaboration on that idea (OOP is essential for decoupling components) and its counterargument (decoupling can apparently be done just fine without OOP?). When programmers faced the "Software Crisis" in the 1960s (https://en.wikipedia.org/wiki/Software_crisis https://en.wikipedia.org/wiki/Software_crisis) the idea of "Software as Components" was born as the solution (https://en.wikipedia.org/wiki/Component-based_software_engineering https://en.wikipedia.org/wiki/Component-based_software_engin...). This was a direct result of research on "Separation of Concerns/Information Hiding/Modularization/Structured Programming" design requirements. The idea was to make it similar to how "Components" were used in the Hardware Industry where you could substitute different components across different products/product families and all can be developed independently but used in a drop-in/plug-and-play manner to build up an entire System. OOD/OOP turned out to be a natural architecture for Components since they provided the necessary support for the above-mentioned design requirements. There are two aspects to this architecture a) Source/Language level b) Binary/Usage level. The latter was the "holy grail" and people invented complete binary runtime architectures like COM/DCOM/CORBA/etc.(eg. https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model) with language-neutral interfaces defined via a IDL (https://en.wikipedia.org/wiki/Interface_description_language https://en.wikipedia.org/wiki/Interface_description_language). You could now have binary software components publish well defined interfaces which clients could call at runtime to discover and use services. The OO idea of encapsulation of data+procedures in a single "Object" keeps the model clean. But note that OO itself is merely a way of composing/structuring procedural code with a strong emphasis on a certain method of architecting the whole System. Thus OOD/OOP helps greatly in designing systems where components can be kept well decoupled and extensible. The same can be done in a non-OO way (depending on your definition of OO) but is much harder. The design requirements mentioned above have to be satisfied whichever path you take. The role of a OO language merely facilitates the ease with which you can/cannot architect such a System.

by andai 3y ago

tus666 3y ago

> is essential to nearly any large, complex software system > in performance sensitive code Those two things are not the same.

billforsternz 3y ago
The question you're responding too already makes it clear those things are quite different, perhaps even orthogonal.

randomdata 3y ago

Central to OOP is message passing between objects. Few languages utilize message passing, so it seems you can decouple components without OOP just fine.

andai 3y ago
>Few languages utilize message passing Yet most of them call themselves object-oriented! I'm reminded of the Alan Kay quote, "I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind."
- alex_smart 3y ago
  Is Smalltalk’s message passing really all that different from methods from other OOP languages? Seems like quite an arbitrary distinction to me.
  - randomdata 3y ago
    All OOP languages use message passing, but perhaps you mean languages with objects that are not oriented? While not completely identical to Smalltalk's message passing design, the Qt project once went to all the trouble of building their own compiler just to be able to graft message passing onto C++. I think that goes to show that there really is a difference – otherwise, why not use the standard constructs C++ offered? Whether or not that difference makes for better software is debatable. It does seem that at one time it did lend itself exceptionally well to GUI programming. NeXTSTEP/macOS/iOS also would never have been what they are without OOP. But we've also learned some programming tricks along the way, so it may not even shine there anymore. Swift, for example, has given up on OOP (except where @objc mode is enabled) and it seems like it manages to do quite well with GUIs (granted, having @objc mode to fall back on clouds that somewhat).
    - alex_smart 3y ago
      I mean that, to me, the difference between message passing and method calling is not significant enough to say that these languages are following different programming paradigms - like you say OOP vs languages with objects. Afaict the difference between Smalltalk and Objective-C style message passing and Java and C# style method calling is purely syntactic.
      - randomdata 3y ago
        > Afaict the difference between Smalltalk and Objective-C style message passing and Java and C# style method calling is purely syntactic. doesNotUnderstand:/forwardInvocation: isn't different? That is not just syntactical. How would you even begin to orient your objects without like functionality? I agree that if you squint really hard they look the same. But if we say "they are all the same", what are you trying to communicate when you say OOP? Virtually all programming languages we use have objects. You may as well drop the OO and just use "programming". It would communicate the same intent.

WalterBright 3y ago

I've also seen template hierarchies so deep it was a major effort trying to figure out which template did anything besides forward to another template.

DontchaKnowit 3y ago
Ugh yes. This has beeb my experience with Java code in large corporate projects. Just endless layers of seemingly pointless abstraction
- mpweiher 3y ago
  Yep, that's because indirection is a necessary tradeoff for implementing OO systems in languages that don't fully support it, which surprisingly includes all current OO languages. People then get confused and think that indirection is the point. It's not. It would be better if the indirection weren't needed and we could express more than just procedural abstraction in our PLs.

whatsakandr 3y ago

I've found OOP can increase coupling. I actually have this problem at work. Say I have class A and B. I could write `int x = A:FunctionOfAandB(B b)`, but in this case. So now A depends on B. It would be much preferable to have free function of A and B. A and B are no longer dependent on each other, just the function to compute the result dependent on A and B. IMO: The real thing of value OOP provides is calling with object.method. A lot of OOP code looks like `void obj.mutate()`. If you pulled that to what's really happening in "procedural" syntax, `mutate(obj)`, that exposes it for the bad code it is.

andai 3y ago
>The real thing of value OOP provides is calling with object.method. A lot of OOP code looks like `void obj.mutate()`. If you pulled that to what's really happening in "procedural" syntax, `mutate(obj)`, that exposes it for the bad code it is. I'm confused here, are you saying there is value in the object.method() syntax? D language for example has Uniform Function Call Syntax[0] where f(x) can be written as x.f() (I missed this syntax in C, and tried to approximate it by putting functions in structs, but you still have to pass the caller as an arg so it ends up being player.update(player) which looks stupid, so at that point player_update(player) seems an acceptable alternative) Later you say obj.mutate() is bad code, are you referring only to methods which mutate the object? [0] https://tour.dlang.org/tour/en/gems/uniform-function-call-syntax-ufcs https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...
deleted 3y ago
[deleted]

_dain_ 3y ago

This video has a pretty good breakdown of how the "encapsulation" and "decoupling" promised by OOP is mostly a mirage: https://youtu.be/QM1iUe6IofM?si=4GrOhZ31esd7rDSN&t=1089 https://youtu.be/QM1iUe6IofM?si=4GrOhZ31esd7rDSN&t=1089

rramadass 3y ago

> I'd love to hear an elaboration on that idea (OOP is essential for decoupling components) and its counterargument (decoupling can apparently be done just fine without OOP?). When programmers faced the "Software Crisis" in the 1960s (https://en.wikipedia.org/wiki/Software_crisis https://en.wikipedia.org/wiki/Software_crisis) the idea of "Software as Components" was born as the solution (https://en.wikipedia.org/wiki/Component-based_software_engineering https://en.wikipedia.org/wiki/Component-based_software_engin...). This was a direct result of research on "Separation of Concerns/Information Hiding/Modularization/Structured Programming" design requirements. The idea was to make it similar to how "Components" were used in the Hardware Industry where you could substitute different components across different products/product families and all can be developed independently but used in a drop-in/plug-and-play manner to build up an entire System. OOD/OOP turned out to be a natural architecture for Components since they provided the necessary support for the above-mentioned design requirements. There are two aspects to this architecture a) Source/Language level b) Binary/Usage level. The latter was the "holy grail" and people invented complete binary runtime architectures like COM/DCOM/CORBA/etc.(eg. https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model) with language-neutral interfaces defined via a IDL (https://en.wikipedia.org/wiki/Interface_description_language https://en.wikipedia.org/wiki/Interface_description_language). You could now have binary software components publish well defined interfaces which clients could call at runtime to discover and use services. The OO idea of encapsulation of data+procedures in a single "Object" keeps the model clean. But note that OO itself is merely a way of composing/structuring procedural code with a strong emphasis on a certain method of architecting the whole System. Thus OOD/OOP helps greatly in designing systems where components can be kept well decoupled and extensible. The same can be done in a non-OO way (depending on your definition of OO) but is much harder. The design requirements mentioned above have to be satisfied whichever path you take. The role of a OO language merely facilitates the ease with which you can/cannot architect such a System.