6 ms·
I really like Hadi's criticism of OO, and in fact I would like to hijack it and take it a few steps further, to paint what in my mind is a more realistic pictur
by sklivvz1971 13y ago
I really like Hadi's criticism of OO, and in fact I would like to hijack it and take it a few steps further, to paint what in my mind is a more realistic picture. Functional programming is only an alternative choice of paradigm. Expert programmers will use the best tool for the job and eschew the pointless search for the absolute best.
Why OO? Classes exist to decouple behaviors from data. In fact, their purpose is to think in terms of cohesive sets of behaviors instead of data-driven functions.
Does this apply to any possible case? No, it's a leaky abstraction.
Why FP? Functions exist to decouple behavior from other behavior. In fact, their purpose is to think in terms of completely decoupled sets of behaviors instead of cohesive functions.
Does this apply to any possible case? No, it's a leaky abstraction.
Why AOP? Aspects exist to decouple behaviors that apply across classes. In fact, their purpose is to think in terms of orthogonal sets of behaviors instead of hierarchical sets of behaviors.
Does this apply to any possible case? No, it's a leaky abstraction.
Why Procedural Programming? To separate the functionality of the application in separate behaviors. In fact, the purpose of procedures is to think in terms of behaviors instead of sequences of operations.
Does this apply to any possible case? No, it's a leaky abstraction.
Why Declarative Programming? To express solutions in terms of goals instead of behaviors. In fact, its purpose is to think in terms of desired state, not sequences or compositions of behaviors.
Does this apply to any possible case? No, it's a leaky abstraction.
Why Logic Programming? To explore the logical consequences of given facts, instead of focusing on behaviors or desired outcomes. In fact, its purpose is to find new truths starting from given truths.
Does this apply to any possible case? No, it's a leaky abstraction.
Why spaghetti code? Wait, no that's just crap ;-)
- weavejester 13y agoThe problem with this argument is that certain abstractions are more useful than others, particularly in certain problem domains. You rarely need a language with manual memory management when designing a web application, for instance.
- zachrose 13y agoWait, isn't that exactly the same "choose the right tool for the job" point that sklivvz1971 is making?
- weavejester 13y agoI'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 agoI 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 agoI 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.
- joe_the_user 13y agoThe problem with this argument is that certain abstractions are more useful than others Well, I think one should say the thing to keep in mind with this argument is... And "certain abstractions are more useful than others" should be certain abstractions should be used more often than others ... but you also still need to know how and when to use ... the less commonly needed ones, 'cause if you don't, they can still bite you.
- chc 13y ago> Why OO? Classes exist to decouple behaviors from data. This seems like the opposite of how it generally works. Classes tie behaviors to data. This is what people generally seem to mean when they talk about encapsulation in OO — the behavior and the data are bound together very well.
- cgag 13y agoYeah, I thought coupling data and behavior was more or less the definition of an object.
- Fargren 13y agoAs long as an object's behaviour remains the same, the data can change without any problem. That's one of the big selling points of OO.
- platz 13y agoSo, then is there some vocabulary that is lacking to describe the difference between these two ideas, but seem to use the same words?
- gnaritas 13y agoThey work together, by encapsulating the data internally, one is free to change its representation. It keeps the coupling to that data local, the objects methods.
- sklivvz1971 13y agoIf you have a datetime object you can stop thinking about the fact that it's internally implemented with e.g. ticks since the epoch. In fact, you don't care anymore what data it depends on, because you only depend on behaviors.
- weavejester 13y agoThat's more polymorphism than encapsulation.
- evincarofautumn 13y agoI will pick a minor nit: classes, as we know them from C++ and Java, are about coupling data with behaviour, not decoupling. You bind a specific data representation to an interface for working with that representation opaquely, in the hope that no one inadvertently depends on your innards. Most other languages do it with modules.
- sklivvz1971 13y agoEncapsulation makes sure the data is hidden away, and, in theory, is only accessible through methods, which may, or may not internally use the same data. For example this pseudoclass public class Sum1 { private int _a, _b; public Sum1(int a, b) { _a = a; _b = b; } public int ReturnResult() { return _a+_b; } } And this other pseudoclass public class Sum2 { private int _tot; public Sum2(int a, b) { _tot = a+b; } public int ReturnResult() { return _tot; } } Have the same behavior/functionality but depend on different internal data - in this sense the data has been decoupled from the functionality: one can treat the class as a black box - the coupling happens in the implementation of the class, but not anymore in the design of it.
- xerophtye 13y agoTo all the guys saying the example is bad code or is not complex enough. Well, of course! Think of this as a doodle to present a certain example. Quit complaining that it isn't to scale. He just means to show that OO lets us have the luxury of just caring about the functions we need to use to manipulate/use/access the data, without any regard to how it is internally stored.
- chongli 13y agoEncapsulation may hide the data away but it does not hide the effects of state. If an object contains mutable state, it is not referentially transparent. This makes the abstraction leaky, as users need to understand the possible states of an object lest it behave unpredictably.
- 13y ago
- FatalBaboon 13y agoI'd like to tie this to languages and their age. I feel like young languages have a tendency to advocate only one of those, and as they mature they engulf most or all of them. C# used to be all about OO, then it got FP (lambdas), and dynamism.. The extreme example could be Lisp, in which you can do pretty much any of the paradigms you mentioned.
- Sssnake 13y ago>Classes exist to decouple behaviors from data By tying them together? That isn't what decouple means. I have to ask, have you ever tried any sort of declarative programming? The fact that you list it, and the two main branches of it separately makes me think you haven't. You should really try it sometime, you might re-think the vague dismissal of all programming paradigms as equals.