4 ms·

> The issues with inheritance based OOP Inheritance is just one of multiple facets of safe code reuse in OOP. Aggregation, composition, encapsulation are as ar

> The issues with inheritance based OOP Inheritance is just one of multiple facets of safe code reuse in OOP. Aggregation, composition, encapsulation are as are much as fundamental notions in OOP as inheritance. So i think reducing OOP in general, and java in particular to "inheritance based OOP" is a miss characterization > are that it fits very few problems well, that it usually causes lots of problems and that many programming languages only have inheritance based OOP in their toolbox. Do you have any objective way to measure that ? > Patterns like abstract visitor factories are hacks to express situations that cannot be expressed in an obvious way. But isnt that the reason to have a pattern ? An easy way to expression a non obvious recurring situation ?

lomnakkus 9y ago
> Aggregation, composition, encapsulation are as are much as fundamental notions in OOP as inheritance. You say that as if these things are not just as easily expressed in FP -- if not even easier. Aggregation is just records-of-records. Encapsulation is just "abstract data types", e.g. ML modules with abstract members, or non-exported data constructors in Haskell. Another option would be simply closing over whatever you're trying to hide. Another option would be existential types. (There's some overlap among all of these.) Composition... well, actually I'm not sure what exactly you mean by "composition" in the context of OO. Can you explain what you mean?
- bushin 9y ago
  Reminds me of PHP CEO's tweet: "If you had bad experiences with scrum you just did scrum wrong. If you had good experiences making software you just accidentally did scrum".
- soulbadguy 9y ago
  > You say that as if these things are not just as easily expressed in FP No, that's what you read. What i said what was i wrote... OOP is bigger than inheritance. > -- if not even easier. Again, this kind of statement really sound like empty FP propaganda to me. > Encapsulation is just "abstract data types", e.g. ML modules with abstract members, or non-exported data constructors in Haskell. Another option would be simply closing over whatever you're trying to hide. Another option would be existential types. (There's some overlap among all of these.) Or "abstract data types" is just Encapsulation...
  - lomnakkus 9y ago
    > No, that's what you read. I think you may have misunderstood my intent. I was just trying to say "FP can do these things too". > Again, this kind of statement really sound like empty FP propaganda to me. Right, so any type of even very modest support for X is "empty X propaganda". Can we please assume at least a modicum of good faith here? > Or "abstract data types" is just Encapsulation... Oh, so "semantics" it is then. Oh, well. FWIW, I think I'm right in saying that ADTs were invented quite a bit before OOP & "Encapsulation". I notice that you also didn't answer my question of what Composition actually means in OOP. Do you have an answer? I promise, I wasn't being facetious.
- catnaroek 9y ago
  > ML modules with abstract members So true! Sadly, most programmers' idea of an “abstract data type” is a class. :-p
  - lomnakkus 9y ago
    Booyakasha! :)
- seanmcdirmid 9y ago
  OOP is simply programming with objects. You can do that in a language of functions, you can also program with functions with a language of objects.
  - lomnakkus 9y ago
    Define "objects", please.
    - seanmcdirmid 9y ago
      That's easy, the word is well defined in the dictionary: a person or thing to which a specified action or feeling is directed. Some people try to call objects entities and claim they are doing something else, but they are just doing the same thing with different words.
      - lomnakkus 9y ago
        Uh, how does that relate to the semantics of the language? (Formally, not dictionarily.) EDIT: I was being a bit facetious, but we were discussing programming languages, so maybe not that much of a stretch...?
dyarosla 9y ago
None of those things are necessarily fundamental notions in OOP so much as they are core constructs in many OOP languages. It's quite trivial to find multiple examples for why inheritance causes far more problems in many cases than when using composition- rigid class hierarchies and fragile superclasses are some such examples (problems: extendability/maintainability and high coupling). Patterns are ways to semi-cleanly work within an OOP design, but you'll find that it's often the case that a lot of verbosity needs to come along for the ride- working towards solving how to structure class hierarchies more than solving the actual problems those classes are meant to solve. There's a reason why composition is preferred over inheritance. There's also good reason why some programmers will take it to the extreme and say that it ALWAYS causes more problems. Some languages lack of providing an appropriate aggregation alternative generally keeps inheritance alive. Some people will hold onto their positive notions about inheritance too, and that's fine, but there's a reason why many people advocate strongly against it (and why some modern language designers skip it altogether!)
- euyyn 9y ago
  > Some languages lack of providing an appropriate aggregation alternative generally keeps inheritance alive. I might not be understanding well, but are you talking of languages that happen to have no _composition_? But do have inheritance? Sounds like those with inheritance are a strict subset of those with composition (which in turn would be all but fringe languages).
  - dyarosla 9y ago
    No I'm talking about a lack of language constructs that make composition a pain and inheritance a quick fix: forwarding. Inheritance is often used improperly because writing forwarding methods to delegates is a pain. IS-A/HAS-A goes OUT-A the window: in many cases ushers developers to adopt it because it requires less typing.
- soulbadguy 9y ago
  It seems to me that you are just explaining what the parent was saying. My point is not inheritance is good/bad or usefull, my point was that OOP doesn't imply inheritance it's just one of the many ways OOP languages reuse code.
legulere 9y ago
Aggregation and composition are almost the same, are not distinguished in e.g. Java and exist in pretty much every rogramming language regardless if they are object-oriented. Inheritance is presented everywhere as the go-to method for structuring everything in languages supporting inheritance. The whole java class library consists of huge class hierarchies. Every non-trivial java code base I have seen is heavily infested with inheritance. Inheritance together with other forms of polymorphism are the biggest differentiator to structural programming in e.g. C. Inheritance is everything else but safe: you have to check if you broke the behavior of all methods and public fields you are inheriting. How often do you go through all classes you are inheriting from? Sometimes you cannot even fix this with overriding methods: You can easily construct a cut off ellipsoid from a regular ellipsoid, but then it stops being a quadric surface invalidating your nice class hierarchy. And you cannot change the class hierarchy because half of your codebase depends on it. Patterns are like neat useful tricks. Like how to open a bottle with a hammer. Pretty nice to open your beer at the end of the day in a workshop. If you work in a bar and you constantly have to use tricks to use your hammer for your work you should probably rethink if a hammer is the right main tool for you.
- dragonwriter 9y ago
  > Inheritance is presented everywhere as the go-to method for structuring everything in languages supporting inheritance. No, it's not. Many places recommend restraint in use of inheritance (and in languages that support only single inheritance, there are sharp limits to what it can do to start with.)
- ridiculous_fish 9y ago
  > Inheritance is presented everywhere as the go-to method for structuring everything in languages supporting inheritance. The whole java class library consists of huge class hierarchies. That conclusion holds if your primary experience is Java: the Java class library is widely believed to have abused inheritance. However other languages have avoided that trap. Apple's Cocoa frameworks in ObjC do use inheritance but also delegation, notifications, etc. Also Swift supports inheritance, but here we see Lattner describing inheritance as a "tool in our toolbox," not as the "go-to method for structuring everything." > Inheritance is everything else but safe: you have to check if you broke the behavior of all methods and public fields you are inheriting. Designing a class interface intended to be inherited is like any other API design exercise. Your API commits to invariants, and it's the client programmer's responsibility to follow them; if they do the class should not be broken. If you find yourself checking "all methods and public fields," either the API is bad or you've misunderstood it. Again, it's just one API design tool. Sometimes the alternative to inheritance is just an ad-hoc, bug-ridden re-implementation of inheritance.

lomnakkus 9y ago

> Aggregation, composition, encapsulation are as are much as fundamental notions in OOP as inheritance. You say that as if these things are not just as easily expressed in FP -- if not even easier. Aggregation is just records-of-records. Encapsulation is just "abstract data types", e.g. ML modules with abstract members, or non-exported data constructors in Haskell. Another option would be simply closing over whatever you're trying to hide. Another option would be existential types. (There's some overlap among all of these.) Composition... well, actually I'm not sure what exactly you mean by "composition" in the context of OO. Can you explain what you mean?

bushin 9y ago
Reminds me of PHP CEO's tweet: "If you had bad experiences with scrum you just did scrum wrong. If you had good experiences making software you just accidentally did scrum".
soulbadguy 9y ago
> You say that as if these things are not just as easily expressed in FP No, that's what you read. What i said what was i wrote... OOP is bigger than inheritance. > -- if not even easier. Again, this kind of statement really sound like empty FP propaganda to me. > Encapsulation is just "abstract data types", e.g. ML modules with abstract members, or non-exported data constructors in Haskell. Another option would be simply closing over whatever you're trying to hide. Another option would be existential types. (There's some overlap among all of these.) Or "abstract data types" is just Encapsulation...
- lomnakkus 9y ago
  > No, that's what you read. I think you may have misunderstood my intent. I was just trying to say "FP can do these things too". > Again, this kind of statement really sound like empty FP propaganda to me. Right, so any type of even very modest support for X is "empty X propaganda". Can we please assume at least a modicum of good faith here? > Or "abstract data types" is just Encapsulation... Oh, so "semantics" it is then. Oh, well. FWIW, I think I'm right in saying that ADTs were invented quite a bit before OOP & "Encapsulation". I notice that you also didn't answer my question of what Composition actually means in OOP. Do you have an answer? I promise, I wasn't being facetious.
catnaroek 9y ago
> ML modules with abstract members So true! Sadly, most programmers' idea of an “abstract data type” is a class. :-p
- lomnakkus 9y ago
  Booyakasha! :)
seanmcdirmid 9y ago
OOP is simply programming with objects. You can do that in a language of functions, you can also program with functions with a language of objects.
- lomnakkus 9y ago
  Define "objects", please.
  - seanmcdirmid 9y ago
    That's easy, the word is well defined in the dictionary: a person or thing to which a specified action or feeling is directed. Some people try to call objects entities and claim they are doing something else, but they are just doing the same thing with different words.
    - lomnakkus 9y ago
      Uh, how does that relate to the semantics of the language? (Formally, not dictionarily.) EDIT: I was being a bit facetious, but we were discussing programming languages, so maybe not that much of a stretch...?

dyarosla 9y ago

None of those things are necessarily fundamental notions in OOP so much as they are core constructs in many OOP languages. It's quite trivial to find multiple examples for why inheritance causes far more problems in many cases than when using composition- rigid class hierarchies and fragile superclasses are some such examples (problems: extendability/maintainability and high coupling). Patterns are ways to semi-cleanly work within an OOP design, but you'll find that it's often the case that a lot of verbosity needs to come along for the ride- working towards solving how to structure class hierarchies more than solving the actual problems those classes are meant to solve. There's a reason why composition is preferred over inheritance. There's also good reason why some programmers will take it to the extreme and say that it ALWAYS causes more problems. Some languages lack of providing an appropriate aggregation alternative generally keeps inheritance alive. Some people will hold onto their positive notions about inheritance too, and that's fine, but there's a reason why many people advocate strongly against it (and why some modern language designers skip it altogether!)

euyyn 9y ago
> Some languages lack of providing an appropriate aggregation alternative generally keeps inheritance alive. I might not be understanding well, but are you talking of languages that happen to have no _composition_? But do have inheritance? Sounds like those with inheritance are a strict subset of those with composition (which in turn would be all but fringe languages).
- dyarosla 9y ago
  No I'm talking about a lack of language constructs that make composition a pain and inheritance a quick fix: forwarding. Inheritance is often used improperly because writing forwarding methods to delegates is a pain. IS-A/HAS-A goes OUT-A the window: in many cases ushers developers to adopt it because it requires less typing.
soulbadguy 9y ago
It seems to me that you are just explaining what the parent was saying. My point is not inheritance is good/bad or usefull, my point was that OOP doesn't imply inheritance it's just one of the many ways OOP languages reuse code.

legulere 9y ago

Aggregation and composition are almost the same, are not distinguished in e.g. Java and exist in pretty much every rogramming language regardless if they are object-oriented. Inheritance is presented everywhere as the go-to method for structuring everything in languages supporting inheritance. The whole java class library consists of huge class hierarchies. Every non-trivial java code base I have seen is heavily infested with inheritance. Inheritance together with other forms of polymorphism are the biggest differentiator to structural programming in e.g. C. Inheritance is everything else but safe: you have to check if you broke the behavior of all methods and public fields you are inheriting. How often do you go through all classes you are inheriting from? Sometimes you cannot even fix this with overriding methods: You can easily construct a cut off ellipsoid from a regular ellipsoid, but then it stops being a quadric surface invalidating your nice class hierarchy. And you cannot change the class hierarchy because half of your codebase depends on it. Patterns are like neat useful tricks. Like how to open a bottle with a hammer. Pretty nice to open your beer at the end of the day in a workshop. If you work in a bar and you constantly have to use tricks to use your hammer for your work you should probably rethink if a hammer is the right main tool for you.

dragonwriter 9y ago
> Inheritance is presented everywhere as the go-to method for structuring everything in languages supporting inheritance. No, it's not. Many places recommend restraint in use of inheritance (and in languages that support only single inheritance, there are sharp limits to what it can do to start with.)
ridiculous_fish 9y ago
> Inheritance is presented everywhere as the go-to method for structuring everything in languages supporting inheritance. The whole java class library consists of huge class hierarchies. That conclusion holds if your primary experience is Java: the Java class library is widely believed to have abused inheritance. However other languages have avoided that trap. Apple's Cocoa frameworks in ObjC do use inheritance but also delegation, notifications, etc. Also Swift supports inheritance, but here we see Lattner describing inheritance as a "tool in our toolbox," not as the "go-to method for structuring everything." > Inheritance is everything else but safe: you have to check if you broke the behavior of all methods and public fields you are inheriting. Designing a class interface intended to be inherited is like any other API design exercise. Your API commits to invariants, and it's the client programmer's responsibility to follow them; if they do the class should not be broken. If you find yourself checking "all methods and public fields," either the API is bad or you've misunderstood it. Again, it's just one API design tool. Sometimes the alternative to inheritance is just an ad-hoc, bug-ridden re-implementation of inheritance.