4 ms·

I'm saying it's not a useful comparison. Some tools are more capable generally, and applicable to more problem domains. For instance, I'm sure there must exist

I'm saying it's not a useful comparison. Some tools are more capable generally, and applicable to more problem domains. For instance, I'm sure there must exist problems that require inheritance, polymorphism, encapsulation and implicit state mutation, but those are such weirdly specific requirements that I don't think OOP is applicable in most of the cases where it's in use.

xerophtye 13y ago
I am guessing you have a JS background (i may be wrong. You may be thrice my experience and capability in languages of my choice). Either way, IMO those requirements aren't that weird. When you have VERY VERY huge software, this stuff comes in very handy. I love different, non-OO languages for the magic they bring to the table, but that doesn't mean i'd discredit OO languages. I agree that some paradigms are more useful then others. Its rare to use declarative and logic based languages. (i assume declrative here means where u declare a goal without regard to how to achieve the goal). But OO is still pretty much needed in a ton of cases. So i wouldn't bunch it into the "less used" category. Heck web development benefits greatly from this stuff too! My current webproject is in JSP! yay java!
- weavejester 13y ago
  I tend to use Clojure on a day-to-day basis. The functionality that OOP groups into classes is separated out into individual tools in Clojure, so you have a tool for inheritance, a tool for polymorphism, and so forth. When you use the tools of OOP separately, you start to appreciate how little you actually need them. A program in a functional programming language will use very little mutation. Polymorphism is a little more common, but not by much. Inheritance is practically never useful - I've only seen one case where it's ever been used outside a OOP language. I have yet to find a case where I'd need all three tools simultaneously. Encapsulation is also something that seems to have far more disadvantages than advantages. It sounds like a nice idea, hiding your data structures behind an API that doesn't need to change, except in practice it doesn't save much refactoring, and you lose all the benefits with working with data.
michaelt 13y ago
Let's say you want to store some data. Mostly in your final application you'll be writing to a database, but you'd like to keep the option of writing to different types of storage (files on disk, amazon S3, memory for testing). Polymorphism lets your database storage object present the same interface as your file storage object. Pretty useful if you want to be able to substitute them! Encapsulation lets you make sure at compile-time that you haven't accessed anything specific to a particular implementation. If someone else maintains that part of the system, it also lets them mark interface parts that won't change between versions and some implementation parts that may change between versions. Implicit state mutation lets you open the file (or create the file or establish the database connection pool) on the first attempt to access, letting multiple implementations present the same interface even when different things are going on in the background. Inheritance is useful if you have multiple objects - maybe you have one for reading inputs, one for storing work-in-progress, one for writing outputs - and you want to reduce code duplication by sharing implementation details. (IMHO this is one of the less useful ones) TLDR: Use it to unit test your database access.
- weavejester 13y ago
  That's just polymorphism. You don't need to encapsulate the connection data, you don't need to cache implicitly (what's wrong with an explicit memoize?), and inheritance isn't necessary for sharing implementation details. To be more specific in my criticisms, it's not that polymorphism or event inheritance aren't useful tools. It's more that OOP inextricably ties these concepts together, making it hard to reason about them separately. Your comment demonstrates this, I think. All the functionality you describe would be implemented in a functional language with polymorphism and higher-order functions, but because an OOP language binds these concepts so tightly together, it's hard to distinguish between them when thinking about a OO design.
  - michaelt 13y ago
    If not for encapsulation, how do you denote those parts of the interface which you commit to keeping stable and those parts of the interface that are for internal use only?

xerophtye 13y ago

I am guessing you have a JS background (i may be wrong. You may be thrice my experience and capability in languages of my choice). Either way, IMO those requirements aren't that weird. When you have VERY VERY huge software, this stuff comes in very handy. I love different, non-OO languages for the magic they bring to the table, but that doesn't mean i'd discredit OO languages. I agree that some paradigms are more useful then others. Its rare to use declarative and logic based languages. (i assume declrative here means where u declare a goal without regard to how to achieve the goal). But OO is still pretty much needed in a ton of cases. So i wouldn't bunch it into the "less used" category. Heck web development benefits greatly from this stuff too! My current webproject is in JSP! yay java!

weavejester 13y ago
I tend to use Clojure on a day-to-day basis. The functionality that OOP groups into classes is separated out into individual tools in Clojure, so you have a tool for inheritance, a tool for polymorphism, and so forth. When you use the tools of OOP separately, you start to appreciate how little you actually need them. A program in a functional programming language will use very little mutation. Polymorphism is a little more common, but not by much. Inheritance is practically never useful - I've only seen one case where it's ever been used outside a OOP language. I have yet to find a case where I'd need all three tools simultaneously. Encapsulation is also something that seems to have far more disadvantages than advantages. It sounds like a nice idea, hiding your data structures behind an API that doesn't need to change, except in practice it doesn't save much refactoring, and you lose all the benefits with working with data.

michaelt 13y ago

Let's say you want to store some data. Mostly in your final application you'll be writing to a database, but you'd like to keep the option of writing to different types of storage (files on disk, amazon S3, memory for testing). Polymorphism lets your database storage object present the same interface as your file storage object. Pretty useful if you want to be able to substitute them! Encapsulation lets you make sure at compile-time that you haven't accessed anything specific to a particular implementation. If someone else maintains that part of the system, it also lets them mark interface parts that won't change between versions and some implementation parts that may change between versions. Implicit state mutation lets you open the file (or create the file or establish the database connection pool) on the first attempt to access, letting multiple implementations present the same interface even when different things are going on in the background. Inheritance is useful if you have multiple objects - maybe you have one for reading inputs, one for storing work-in-progress, one for writing outputs - and you want to reduce code duplication by sharing implementation details. (IMHO this is one of the less useful ones) TLDR: Use it to unit test your database access.

weavejester 13y ago
That's just polymorphism. You don't need to encapsulate the connection data, you don't need to cache implicitly (what's wrong with an explicit memoize?), and inheritance isn't necessary for sharing implementation details. To be more specific in my criticisms, it's not that polymorphism or event inheritance aren't useful tools. It's more that OOP inextricably ties these concepts together, making it hard to reason about them separately. Your comment demonstrates this, I think. All the functionality you describe would be implemented in a functional language with polymorphism and higher-order functions, but because an OOP language binds these concepts so tightly together, it's hard to distinguish between them when thinking about a OO design.
- michaelt 13y ago
  If not for encapsulation, how do you denote those parts of the interface which you commit to keeping stable and those parts of the interface that are for internal use only?