5 ms·

Don't confuse object oriented concepts and philosophies with implementation. The two are quite different. There's also no single definition of OOP because it h

Don't confuse object oriented concepts and philosophies with implementation. The two are quite different. There's also no single definition of OOP because it has evolved over the years. Start here: http://www.c2.com/cgi/wiki?DefinitionsForOo http://www.c2.com/cgi/wiki?DefinitionsForOo It's important to learn the ideas before you get tied to an implementation.

loup-vaillant 16y ago
Thank you very much for the link. What exactly do you mean by "implementation"? I didn't talk about any specific language or framework.
- spooneybarger 16y ago
  OOP is a concept. How it gets implemented changes to concept. For example, some OOP systems using message passing, others do not. Some have single inheritance, some multiple, some use traits, some mixins. Some are class based, others like self are prototype based.
  - loup-vaillant 16y ago
    Then, what is the common concept between all these implementations? What makes you decide that one piece of code is OO, while another is not? Is the line clear or fuzzy? Do most programmers more or less agree on this line? In other words, what do you mean when you say "OO"? I've read the c2.com wiki page Terry linked to. From what I saw, some programmers would say that C++ is OO¹ and Erlang is not, while others would say the exact opposite! This strongly suggest that the term has become mostly meaningless. Yet you seem to think that it hasn't. Hence my questions. [1] By "X is OO", I mean "X encourages OO programming"
    - spooneybarger 16y ago
      Its fuzzy like when people discuss 'capitalism'. Note the semantic arguments that break out on HN when 'capitalism' is referenced. I don't think OO is a meaningless concept, I think arguing about what is and isn't OO in terms of implementation is. OO is a way of doing things. I can do OO in C. I've known people who hated C++ so much they did OO in C. Seriously. I know people who think that Java's polymorphism is so bastardize that you can't call Java an OO language. Still through all that, there are the some basic ideas that people agree on for what OO is. OO is not a good term to use if you want precision, it is a nice one if you want to quickly convey an idea where the specifics of an implementation aren't that important to the point at hand.
      - loup-vaillant 16y ago
        I think I understand now. Sorry, but I'll have to be blunt. I promise I don't mean to insult you, but I feel that clarity is more important that politeness here. You recognize the existence of rather precise (though contradictory) definitions of OO. You probably have a preference for one of them. Yet, you have "chosen to believe" that there is a concept that most programmer agree to call "OO". Of course, you are unable to put such a concept in writing (or you would have done so by now). Therefore, you dismiss actual definitions of OO as "implementations", saying that the "concept" is above that. The advantage of such a line of thinking is that you don't actually disagree with anyone. The problem is that you hardly say anything when you utter "OO". I may be wrong. But if you want to convince me, you'll have to write a definition of this OO "concept" you're talking about. Or a sketch. Or at least tell me that it will take too much space and effort.
    - terrywilcox 16y ago
      I rarely see programmers agree on anything. We're very argumentative. I've worked with people who insist their code is object oriented because it's written in Java, even though it's all classes full of static methods with no instance variables. I wouldn't call that object oriented, but they would. So yes, the term is becoming meaningless. The concepts are being ignored. That doesn't make them invalid, it just means we have more educating to do.
- terrywilcox 16y ago
  Object Orientation is a design philosophy, not a concrete process or mechanism. Its major principle is encapsulation; things outside of me don't need to know about my internal workings, just my external appearance. This leads to abstraction; if I externally appear just like that other guy, things outside of me can pretend we're the same even if we have different internal workings. Beyond those concepts, we begin to get into implementation. Classes, inheritance, and polymorphism are implementation. You can apply OO principles without them. They just happen to be the traditional face of OO. That may be why you're struggling to find a definition that makes sense. Too often we use the implementation to discuss the philosophy. Don't get hung up on a definition. It's like trying to define love, art, or pornography. Keep asking and arguing about it though. That's a good way to learn it.
  - loup-vaillant 16y ago
    OK, but if I admit your principles as OO, then a functional language with modules and parametric polymorphism is OO (Haskell and Ocaml come to mind). Your definition seems reasonable, but following it means that giving any language reasonable facilities for low coupling and code reuse makes it OO. I'm fine with that, but such a broad term can't be useful in technical discussions.
    - terrywilcox 16y ago
      I think you'll find that the basic principles of good design are shared between most design philosophies. Reducing coupling and increasing cohesion spring to mind. Stop thinking in terms of whether a language claims to be object oriented and start thinking in terms of how you'd apply object oriented principles to the language. The language is merely a tool, sometimes with support for a specific implementation of object orientation. How you use that tool is up to you.
      - loup-vaillant 16y ago
        I did start with the techniques, then checked if the languages supported them. My ideas are a lot clearer than you seem to think. Thanks to you and the others, I now have resolved my confusion: "OO" doesn't technically mean anything significant, but nevertheless carries a strong emotional load (positive or negative, depending on the reader). That tends to end useful discussion and to encourage religious flame-wars. I now consider "OO" taboo, along with sentences like "just a tool". I now believe that most programmers did fall in the trap I spoke of in my original post, but this trap appears to be less obvious than I thought. Now about what implements what: Coupling reduction is implemented by encapsulation. There's no other way. Any technique that reduces coupling is a form of encapsulation. Any language that supports coupling reduction supports encapsulation. Encapsulation is supported by 3 features: functions, modules, and classes. Let's not talk about functions, whose presence don't differentiate. So, to support encapsulation (and therefore coupling reduction), a language needs either modules or classes. Code reuse is achieved with functions and abstraction as you defined it. I don't know any other way, short of writing a DSL or using a whole program. As before, let's not talk about functions themselves. Therefore, any language that supports code reuse supports abstraction. Abstraction means I can interact the same way with two "things" if they are of the same type. Well, I think that by "guy", you meant "something with embedded behaviour", and not just dead data, like integers or arrays. Such a thing is necessarily a closure. Closures can be achieved by 3 mechanisms: subtype polymorphism (interfaces, mixins…), duck typing, and first class functions (which are isomorphic to duck typed mono-method objects). I said "parametric polymorphism" earlier, but it isn't actually needed. So, to supports abstraction (and therefore code reuse), a language must have either subtype polymorphism or first class functions. Now Back to OO. To support OO, a language must support encapsulation and abstraction. I've established that it's the same as saying that it must support coupling reduction and code reuse. And intuitively, a language that doesn't support either of them isn't worth using. Therefore any modern language should support OO. Now, supporting OO is not the same as being OO. To be OO in my book, a language must actually strongly encourage the frequent use of encapsulation and abstraction. As it happens, most modern languages do. Almost all have either modules or classes. And when they do, they strongly encourage you to use them systematically, if they do not flatly mandate it like Java. Likewise, almost all have either subtype polymorphism, duck typing, or first class functions. And when they do, they strongly encourage their frequent use. Which means that almost every modern language strongly encourages the frequent use of all the necessary OO features. In other words, almost every modern language is OO. C++ and Java are OO because of their classes and subtype polymorphism. Ocaml and Haskell are OO because of their module system and their first class functions. You probably didn't intend to qualify those last two as OO (I don't, and they don't claim to be), but they fit your definition nevertheless.

loup-vaillant 16y ago

Thank you very much for the link. What exactly do you mean by "implementation"? I didn't talk about any specific language or framework.

spooneybarger 16y ago
OOP is a concept. How it gets implemented changes to concept. For example, some OOP systems using message passing, others do not. Some have single inheritance, some multiple, some use traits, some mixins. Some are class based, others like self are prototype based.
- loup-vaillant 16y ago
  Then, what is the common concept between all these implementations? What makes you decide that one piece of code is OO, while another is not? Is the line clear or fuzzy? Do most programmers more or less agree on this line? In other words, what do you mean when you say "OO"? I've read the c2.com wiki page Terry linked to. From what I saw, some programmers would say that C++ is OO¹ and Erlang is not, while others would say the exact opposite! This strongly suggest that the term has become mostly meaningless. Yet you seem to think that it hasn't. Hence my questions. [1] By "X is OO", I mean "X encourages OO programming"
  - spooneybarger 16y ago
    Its fuzzy like when people discuss 'capitalism'. Note the semantic arguments that break out on HN when 'capitalism' is referenced. I don't think OO is a meaningless concept, I think arguing about what is and isn't OO in terms of implementation is. OO is a way of doing things. I can do OO in C. I've known people who hated C++ so much they did OO in C. Seriously. I know people who think that Java's polymorphism is so bastardize that you can't call Java an OO language. Still through all that, there are the some basic ideas that people agree on for what OO is. OO is not a good term to use if you want precision, it is a nice one if you want to quickly convey an idea where the specifics of an implementation aren't that important to the point at hand.
    - loup-vaillant 16y ago
      I think I understand now. Sorry, but I'll have to be blunt. I promise I don't mean to insult you, but I feel that clarity is more important that politeness here. You recognize the existence of rather precise (though contradictory) definitions of OO. You probably have a preference for one of them. Yet, you have "chosen to believe" that there is a concept that most programmer agree to call "OO". Of course, you are unable to put such a concept in writing (or you would have done so by now). Therefore, you dismiss actual definitions of OO as "implementations", saying that the "concept" is above that. The advantage of such a line of thinking is that you don't actually disagree with anyone. The problem is that you hardly say anything when you utter "OO". I may be wrong. But if you want to convince me, you'll have to write a definition of this OO "concept" you're talking about. Or a sketch. Or at least tell me that it will take too much space and effort.
  - terrywilcox 16y ago
    I rarely see programmers agree on anything. We're very argumentative. I've worked with people who insist their code is object oriented because it's written in Java, even though it's all classes full of static methods with no instance variables. I wouldn't call that object oriented, but they would. So yes, the term is becoming meaningless. The concepts are being ignored. That doesn't make them invalid, it just means we have more educating to do.
terrywilcox 16y ago
Object Orientation is a design philosophy, not a concrete process or mechanism. Its major principle is encapsulation; things outside of me don't need to know about my internal workings, just my external appearance. This leads to abstraction; if I externally appear just like that other guy, things outside of me can pretend we're the same even if we have different internal workings. Beyond those concepts, we begin to get into implementation. Classes, inheritance, and polymorphism are implementation. You can apply OO principles without them. They just happen to be the traditional face of OO. That may be why you're struggling to find a definition that makes sense. Too often we use the implementation to discuss the philosophy. Don't get hung up on a definition. It's like trying to define love, art, or pornography. Keep asking and arguing about it though. That's a good way to learn it.
- loup-vaillant 16y ago
  OK, but if I admit your principles as OO, then a functional language with modules and parametric polymorphism is OO (Haskell and Ocaml come to mind). Your definition seems reasonable, but following it means that giving any language reasonable facilities for low coupling and code reuse makes it OO. I'm fine with that, but such a broad term can't be useful in technical discussions.
  - terrywilcox 16y ago
    I think you'll find that the basic principles of good design are shared between most design philosophies. Reducing coupling and increasing cohesion spring to mind. Stop thinking in terms of whether a language claims to be object oriented and start thinking in terms of how you'd apply object oriented principles to the language. The language is merely a tool, sometimes with support for a specific implementation of object orientation. How you use that tool is up to you.
    - loup-vaillant 16y ago
      I did start with the techniques, then checked if the languages supported them. My ideas are a lot clearer than you seem to think. Thanks to you and the others, I now have resolved my confusion: "OO" doesn't technically mean anything significant, but nevertheless carries a strong emotional load (positive or negative, depending on the reader). That tends to end useful discussion and to encourage religious flame-wars. I now consider "OO" taboo, along with sentences like "just a tool". I now believe that most programmers did fall in the trap I spoke of in my original post, but this trap appears to be less obvious than I thought. Now about what implements what: Coupling reduction is implemented by encapsulation. There's no other way. Any technique that reduces coupling is a form of encapsulation. Any language that supports coupling reduction supports encapsulation. Encapsulation is supported by 3 features: functions, modules, and classes. Let's not talk about functions, whose presence don't differentiate. So, to support encapsulation (and therefore coupling reduction), a language needs either modules or classes. Code reuse is achieved with functions and abstraction as you defined it. I don't know any other way, short of writing a DSL or using a whole program. As before, let's not talk about functions themselves. Therefore, any language that supports code reuse supports abstraction. Abstraction means I can interact the same way with two "things" if they are of the same type. Well, I think that by "guy", you meant "something with embedded behaviour", and not just dead data, like integers or arrays. Such a thing is necessarily a closure. Closures can be achieved by 3 mechanisms: subtype polymorphism (interfaces, mixins…), duck typing, and first class functions (which are isomorphic to duck typed mono-method objects). I said "parametric polymorphism" earlier, but it isn't actually needed. So, to supports abstraction (and therefore code reuse), a language must have either subtype polymorphism or first class functions. Now Back to OO. To support OO, a language must support encapsulation and abstraction. I've established that it's the same as saying that it must support coupling reduction and code reuse. And intuitively, a language that doesn't support either of them isn't worth using. Therefore any modern language should support OO. Now, supporting OO is not the same as being OO. To be OO in my book, a language must actually strongly encourage the frequent use of encapsulation and abstraction. As it happens, most modern languages do. Almost all have either modules or classes. And when they do, they strongly encourage you to use them systematically, if they do not flatly mandate it like Java. Likewise, almost all have either subtype polymorphism, duck typing, or first class functions. And when they do, they strongly encourage their frequent use. Which means that almost every modern language strongly encourages the frequent use of all the necessary OO features. In other words, almost every modern language is OO. C++ and Java are OO because of their classes and subtype polymorphism. Ocaml and Haskell are OO because of their module system and their first class functions. You probably didn't intend to qualify those last two as OO (I don't, and they don't claim to be), but they fit your definition nevertheless.