6 ms·

There are no real OO principles. Ask ten people and you will get ten different answers. OO is defined by the languages and tools claiming to implement it, and t

by corty 5y ago

There are no real OO principles. Ask ten people and you will get ten different answers. OO is defined by the languages and tools claiming to implement it, and the set of principles derived from those is inconsistent and contradictory.

mytailorisrich 5y ago
It's obviously not so. There are OO principles, which are indeed well-known, and each OO language has its own take on how to implement them. It's not even needed to use an OO language to follow OO design principles. My day job is pure C and we follow OO principles as much as practical.
- jerf 5y ago
  You conspicuously don't actually name any OO principles. If you did I'm sure we could find "OO" languages that don't conform to them. My personal definition of OO has been backed down to directly connecting some concept of "method" to a data structure, and some form of polymorphism of those methods depending on what data structure you pass in to some function/method. You may note this is incredibly weak, but it does have the virtue of usefully distinguishing between two sets of languages, and that those two sets will have real differences in how you program them. Beyond that it's hard to create a definition of OO that has the second property; you may be able to split the world into "languages that implement OO visibility rules (private, protected, public) and those that don't", but you'll fail the second criterion, in that languages that just leave everything public aren't meaningfully different to program in than ones that implement the visibility rules. I could create several different sets of "OO principles", which wouldn't be mutually exclusive necessarily but certainly would be distinguishable. Especially the distinction between the silly principle that OO objects should somehow reflect real-world entities, which was the major failure in 1980s/1990s OO principles and has, mercifully, all but died in the modern era but most certainly was at one point an "OO principle", and any of the several sets of OO principles I could name that actually function in the real world.
  - mytailorisrich 5y ago
    Well, this is HN so I did not want to sound condescending by stating the obvious. OO Programming 101, OO principles: encapsulation, abstraction, inheritance, polymorphism, SOLID. Whatever a specific language adheres to and how is beside the point.
    - jhgb 5y ago
      That must be some kind of "new OOP", since the "old OOP" is messaging, local retention, and protection and hiding of state-process, and extreme late-binding of all things. At least according to Alan Kay, who wrote this verbatim. To wit, encapsulation and abstraction existed outside of OOP (for example, Modula had it before), inheritance is not a necessary feature for OOP (Self doesn't have it), and the O in SOLID doesn't apply to Smalltalk and Self.
      - mytailorisrich 5y ago
        That's standard OOP as it stands today (versus the 60s when Alan Kay coined the term). Alan Kay considers that inheritance and polymorphism are not essential, fine. He does consider encapsulation essential, though. Specific languages have their own take, fine. The point being is that there are well-known OO principles. Claiming otherwise is either disingenuous or ignorant.
        jhgb 5y ago
        > versus the 60s when Alan Kay coined the term It was in the 70s, and his description that I quoted is from the 2000s. > Alan Kay considers that inheritance and polymorphism are not essential, fine. Polymorphism is a logical outcome of his requirements. So in a purely logical sense it is essential, although I imagine that saying that might be a little bit like saying that CO2 is essential for a campfire (as in that you can't get a campfire without emitting CO2, even though that is strictly a matter of consequences). > He does consider encapsulation essential, though. Yes, because biological cells are encapsulated. > there are well-known OO principles. Claiming otherwise is either disingenuous or ignorant. There surely are some "well-known principles" but whether the "known" in that phrase has the same meaning as in "knowledge" (justified true belief at a first approximation) seems debatable.
simiones 5y ago
I think that, while most people can't really articulate this well enough, there is a pretty good common understanding of what style of programming is OO: it's a style of programming where code is quite deeply tied to data, especially modifications of persistent state (encapsulation), and where subtyping is commonly used to model program behavior (interfaces, inheritance, virtual dispatch, polymorphism). This would mostly contrast with procedural code, where code and data are much more separate - procedures often manipulate and pass around complex data structures -, and subtyping is not commonly used for program behavior; instead, flow control is usually explicit (e.g. switch()'ing on an enum value). It is also commonly contrasted to Functional Programming, where data is also loosely tied to code, with functions often reading (but usually not modifying) deep parts of complex data structures; and where higher order functions and sum types are used to achieve dynamic dispatch.

by corty 5y ago

mytailorisrich 5y ago

It's obviously not so. There are OO principles, which are indeed well-known, and each OO language has its own take on how to implement them. It's not even needed to use an OO language to follow OO design principles. My day job is pure C and we follow OO principles as much as practical.

jerf 5y ago
You conspicuously don't actually name any OO principles. If you did I'm sure we could find "OO" languages that don't conform to them. My personal definition of OO has been backed down to directly connecting some concept of "method" to a data structure, and some form of polymorphism of those methods depending on what data structure you pass in to some function/method. You may note this is incredibly weak, but it does have the virtue of usefully distinguishing between two sets of languages, and that those two sets will have real differences in how you program them. Beyond that it's hard to create a definition of OO that has the second property; you may be able to split the world into "languages that implement OO visibility rules (private, protected, public) and those that don't", but you'll fail the second criterion, in that languages that just leave everything public aren't meaningfully different to program in than ones that implement the visibility rules. I could create several different sets of "OO principles", which wouldn't be mutually exclusive necessarily but certainly would be distinguishable. Especially the distinction between the silly principle that OO objects should somehow reflect real-world entities, which was the major failure in 1980s/1990s OO principles and has, mercifully, all but died in the modern era but most certainly was at one point an "OO principle", and any of the several sets of OO principles I could name that actually function in the real world.
- mytailorisrich 5y ago
  Well, this is HN so I did not want to sound condescending by stating the obvious. OO Programming 101, OO principles: encapsulation, abstraction, inheritance, polymorphism, SOLID. Whatever a specific language adheres to and how is beside the point.
  - jhgb 5y ago
    That must be some kind of "new OOP", since the "old OOP" is messaging, local retention, and protection and hiding of state-process, and extreme late-binding of all things. At least according to Alan Kay, who wrote this verbatim. To wit, encapsulation and abstraction existed outside of OOP (for example, Modula had it before), inheritance is not a necessary feature for OOP (Self doesn't have it), and the O in SOLID doesn't apply to Smalltalk and Self.
    - mytailorisrich 5y ago
      That's standard OOP as it stands today (versus the 60s when Alan Kay coined the term). Alan Kay considers that inheritance and polymorphism are not essential, fine. He does consider encapsulation essential, though. Specific languages have their own take, fine. The point being is that there are well-known OO principles. Claiming otherwise is either disingenuous or ignorant.
      - jhgb 5y ago
        > versus the 60s when Alan Kay coined the term It was in the 70s, and his description that I quoted is from the 2000s. > Alan Kay considers that inheritance and polymorphism are not essential, fine. Polymorphism is a logical outcome of his requirements. So in a purely logical sense it is essential, although I imagine that saying that might be a little bit like saying that CO2 is essential for a campfire (as in that you can't get a campfire without emitting CO2, even though that is strictly a matter of consequences). > He does consider encapsulation essential, though. Yes, because biological cells are encapsulated. > there are well-known OO principles. Claiming otherwise is either disingenuous or ignorant. There surely are some "well-known principles" but whether the "known" in that phrase has the same meaning as in "knowledge" (justified true belief at a first approximation) seems debatable.

simiones 5y ago

I think that, while most people can't really articulate this well enough, there is a pretty good common understanding of what style of programming is OO: it's a style of programming where code is quite deeply tied to data, especially modifications of persistent state (encapsulation), and where subtyping is commonly used to model program behavior (interfaces, inheritance, virtual dispatch, polymorphism). This would mostly contrast with procedural code, where code and data are much more separate - procedures often manipulate and pass around complex data structures -, and subtyping is not commonly used for program behavior; instead, flow control is usually explicit (e.g. switch()'ing on an enum value). It is also commonly contrasted to Functional Programming, where data is also loosely tied to code, with functions often reading (but usually not modifying) deep parts of complex data structures; and where higher order functions and sum types are used to achieve dynamic dispatch.