7 ms·

Writing OOP using OOP

105 points by kapilkaisare 13y ago

currywurst 13y ago
Isn't this the scenario that is going to be solved by ES6 'class' syntax sugar?
- jkrems 13y ago
  No, that will only allow to subclass "Object", not "Class". Also with ES6 you have to define the prototype all in once and you can't call `defineMethod` for each one, the ES6 sugar is more like just using `MyClass.prototype = Object.create(BaseClass.prototype, { /* properties */ });` today. Which the author apparently doesn't feel is even worth mentioning.
  - currywurst 13y ago
    But as I understand, the extension of Class was mainly to introduce a self-binding variant. I assumed that a proper class implementation would take that into account. And what is bad about defining the prototype at once? I don't see a great advantage to the defineMethod() style.
    - jkrems 13y ago
      Sorry, I was being sarcastic about the `defineMethod`-style. IMHO the author overvalues the class/inheritance part of OOP and discards the considerable risks posed by using it. For example in the case of the self-binding he misuses inheritance to express "a Class with SelfBinding" which is a strategy/trait relationship and inheritance is the absolutely wrong hammer for that screw. A simple function would be less intrusive, have less indirection, and be more flexible. EDIT: I'm not sure self-binding is part of ES6, to address your actual question. self-binding introduces a certain overhead to every function call, so I'm not even sure it would be a good thing if it would.
      - currywurst 13y ago
        :) thanks for clarifying.. And assuming one wants to express the problem in terms of objects, then the slight overhead might be worth being able to pass bound functions around, "without thinking about it"
michaelsbradley 13y ago
Joose[1] took these patterns about as far as anyone has (open source) as of several years ago; it's based on Moose[2] for Perl. When Bill Edney and Scott Shattuck finally release TIBET[3] upon the world (something like 15 years in the making), it will take "real OOP" for JavaScript to a whole new level. TIBET is basically a full-on Smalltalk system (including a kernel, images, modules) for JavaScript, but it's not a compile-to-JS kit; rather, it builds right on top of the language, kind of a "super library" for ultra heavy-duty browser based apps. [1] https://github.com/Joose/Joose https://github.com/Joose/Joose [2] http://search.cpan.org/~ether/Moose-2.1204/lib/Moose.pm http://search.cpan.org/~ether/Moose-2.1204/lib/Moose.pm [3] http://technicalpursuit.com/ http://technicalpursuit.com/
barrkel 13y ago
This is a sociological problem. The further up the abstraction hierarchy you customize things in languages that let you do this, the more differentiated your code is and - generally speaking - the more awkward it is to integrate with other people's code. Lisp and Smalltalk are at one extreme end of the scale here. They let you define rich DSLs. Unfortunately, application of their most powerful features to any given problem domain typically results in a custom language specific to that domain - so much so that you lose much of the benefits of sharing a language with other programmers. Understanding what's going on takes much more work, because you need to understand more of the system before its gestalt becomes clear. DSLs are excellent when they're applied to problem domains that are otherwise very clumsy to express, when the problem is widespread, when it doesn't intermix too deeply with other domains (i.e. the abstraction is mostly self-contained), and when there is a critical mass of programmers using it - enough that understanding the system at its own level of abstraction is enough for most people. But when you apply the same techniques to relatively humdrum problems like object construction, function binding etc., it's best if the language or its standard library has a reasonable approach and everybody uses it. Developing your own ad-hoc language around class construction means that everyone coming into your code needs to understand it before they can truly understand what the code is doing. It's a barrier to understanding, and the pros of customization need to be substantially higher than the costs of subtlety. In short, it's usually better to be explicit.
- camus2 13y ago
  totally agree. Take ExtJs core, it's a good exemple of over abstracting everything. But JS is also guilty,guilty of providing "weak" and loose structures.If JS had classes(like ES6),nobody would create all these complicated frameworks to build them.
  - _pmf_ 13y ago
    > If JS had classes(like ES6),nobody would create all these complicated frameworks to build them. Having classes does not solve the meta-programming issue, which is what most frameworks additionally provide. Look at the Java world for an example that classes don't prevent the proliferation of frameworks.
Jare 13y ago
I generally prefer to KISS than to OOPOOP, but if you are building a large, sophisticated framework for large, long-term projects with large, stable teams, then yeah, it is a good idea to turn your patterns and structural standards into semi-custom languages within the language.
Myrmornis 13y ago
The basic proposition of OO is that objects encapsulate their private state. I'd say the most basic proposition is that you solve problems by representing the nouns in the problem domain as objects in software. You could have a version of OOP that doesn't involve hiding internal state.
- weland 13y ago
  > You could have a version of OOP that doesn't involve hiding internal state. I think that would make writing sentences with those nouns somewhat difficult.
  - seanmcdirmid 13y ago
    Right. The basic tenets of OO are (1) identity and (2) encapsulation. Many would also throw in messaging.
- kybernetikos 13y ago
  > You could have a version of OOP that doesn't involve hiding internal state. That is in fact the default form of OOP in javascript.
irahul 13y ago
I prefer to keep things simple. https://gist.github.com/rahulkmr/9482010 https://gist.github.com/rahulkmr/9482010 It makes working with teams easier.
- jrub 13y ago
  In the case of User.getName, why do you re-define that method just to call the prototype's method? Doesn't creating the object from the parent prototype bring that getName method to the User object for free? Or, were you demonstrating the method overriding + calling to parent use case?
  - irahul 13y ago
    > Or, were you demonstrating the method overriding + calling to parent use case? Yep. This gist is what I run co-workers through for demonstrating OOP in JS.
VeejayRampay 13y ago
Very nice article. Though, syntax highlighting would really add to readability of the snippets. Good job though.
userbinator 13y ago
But if we do buy the proposition that OO is a good idea for our domain, shouldn’t we ask ourselves why we aren’t using it for our classes? "If X is a good thing, why aren't we using more X?" No. I've seen horribly convoluted and overly complex code written as a result of following this sort of dogma with things like design patterns. OOP can be incredibly useful when applied correctly, but don't think that it's a panacea or that "OOP-ness" is somehow directly correlated with code quality. Layers of abstraction and encapsulation are very good at hiding bugs too, and IMHO they're overrated.
otikik 13y ago
I like it as a theoretical exercise. I would not use it in production.
rubysucks 13y ago
Oh my goodness. There are so many problems with this. 1. Giving the code to someone else to maintain is going to be a nightmare. You'll have to spend so much time explaining each iteration of abstraction. 2. You have spent so much valuable time abstracting and at the end of it, getting little functionality for your troubles. 3. You are attempting to skew the very nature of Javascript. It was designed the way it is for a reason. Meddling with this is going to result in a multitude of unforeseen problems, such as performance and debugging issues. Solving a lot of these problems is going to require thorough testing and absolving layers of abstraction. Theoretically, these ideas are cool. They look good in a GitHub repo. But in the real world, there's simply no place for this.

105 points by kapilkaisare 13y ago

currywurst 13y ago

Isn't this the scenario that is going to be solved by ES6 'class' syntax sugar?

jkrems 13y ago
No, that will only allow to subclass "Object", not "Class". Also with ES6 you have to define the prototype all in once and you can't call `defineMethod` for each one, the ES6 sugar is more like just using `MyClass.prototype = Object.create(BaseClass.prototype, { /* properties */ });` today. Which the author apparently doesn't feel is even worth mentioning.
- currywurst 13y ago
  But as I understand, the extension of Class was mainly to introduce a self-binding variant. I assumed that a proper class implementation would take that into account. And what is bad about defining the prototype at once? I don't see a great advantage to the defineMethod() style.
  - jkrems 13y ago
    Sorry, I was being sarcastic about the `defineMethod`-style. IMHO the author overvalues the class/inheritance part of OOP and discards the considerable risks posed by using it. For example in the case of the self-binding he misuses inheritance to express "a Class with SelfBinding" which is a strategy/trait relationship and inheritance is the absolutely wrong hammer for that screw. A simple function would be less intrusive, have less indirection, and be more flexible. EDIT: I'm not sure self-binding is part of ES6, to address your actual question. self-binding introduces a certain overhead to every function call, so I'm not even sure it would be a good thing if it would.
    - currywurst 13y ago
      :) thanks for clarifying.. And assuming one wants to express the problem in terms of objects, then the slight overhead might be worth being able to pass bound functions around, "without thinking about it"

michaelsbradley 13y ago

Joose[1] took these patterns about as far as anyone has (open source) as of several years ago; it's based on Moose[2] for Perl. When Bill Edney and Scott Shattuck finally release TIBET[3] upon the world (something like 15 years in the making), it will take "real OOP" for JavaScript to a whole new level. TIBET is basically a full-on Smalltalk system (including a kernel, images, modules) for JavaScript, but it's not a compile-to-JS kit; rather, it builds right on top of the language, kind of a "super library" for ultra heavy-duty browser based apps. [1] https://github.com/Joose/Joose https://github.com/Joose/Joose [2] http://search.cpan.org/~ether/Moose-2.1204/lib/Moose.pm http://search.cpan.org/~ether/Moose-2.1204/lib/Moose.pm [3] http://technicalpursuit.com/ http://technicalpursuit.com/

barrkel 13y ago

This is a sociological problem. The further up the abstraction hierarchy you customize things in languages that let you do this, the more differentiated your code is and - generally speaking - the more awkward it is to integrate with other people's code. Lisp and Smalltalk are at one extreme end of the scale here. They let you define rich DSLs. Unfortunately, application of their most powerful features to any given problem domain typically results in a custom language specific to that domain - so much so that you lose much of the benefits of sharing a language with other programmers. Understanding what's going on takes much more work, because you need to understand more of the system before its gestalt becomes clear. DSLs are excellent when they're applied to problem domains that are otherwise very clumsy to express, when the problem is widespread, when it doesn't intermix too deeply with other domains (i.e. the abstraction is mostly self-contained), and when there is a critical mass of programmers using it - enough that understanding the system at its own level of abstraction is enough for most people. But when you apply the same techniques to relatively humdrum problems like object construction, function binding etc., it's best if the language or its standard library has a reasonable approach and everybody uses it. Developing your own ad-hoc language around class construction means that everyone coming into your code needs to understand it before they can truly understand what the code is doing. It's a barrier to understanding, and the pros of customization need to be substantially higher than the costs of subtlety. In short, it's usually better to be explicit.

camus2 13y ago
totally agree. Take ExtJs core, it's a good exemple of over abstracting everything. But JS is also guilty,guilty of providing "weak" and loose structures.If JS had classes(like ES6),nobody would create all these complicated frameworks to build them.
- _pmf_ 13y ago
  > If JS had classes(like ES6),nobody would create all these complicated frameworks to build them. Having classes does not solve the meta-programming issue, which is what most frameworks additionally provide. Look at the Java world for an example that classes don't prevent the proliferation of frameworks.

Jare 13y ago

I generally prefer to KISS than to OOPOOP, but if you are building a large, sophisticated framework for large, long-term projects with large, stable teams, then yeah, it is a good idea to turn your patterns and structural standards into semi-custom languages within the language.

Myrmornis 13y ago

The basic proposition of OO is that objects encapsulate their private state. I'd say the most basic proposition is that you solve problems by representing the nouns in the problem domain as objects in software. You could have a version of OOP that doesn't involve hiding internal state.

weland 13y ago
> You could have a version of OOP that doesn't involve hiding internal state. I think that would make writing sentences with those nouns somewhat difficult.
- seanmcdirmid 13y ago
  Right. The basic tenets of OO are (1) identity and (2) encapsulation. Many would also throw in messaging.
kybernetikos 13y ago
> You could have a version of OOP that doesn't involve hiding internal state. That is in fact the default form of OOP in javascript.

irahul 13y ago

I prefer to keep things simple. https://gist.github.com/rahulkmr/9482010 https://gist.github.com/rahulkmr/9482010 It makes working with teams easier.

jrub 13y ago
In the case of User.getName, why do you re-define that method just to call the prototype's method? Doesn't creating the object from the parent prototype bring that getName method to the User object for free? Or, were you demonstrating the method overriding + calling to parent use case?
- irahul 13y ago
  > Or, were you demonstrating the method overriding + calling to parent use case? Yep. This gist is what I run co-workers through for demonstrating OOP in JS.

VeejayRampay 13y ago

Very nice article. Though, syntax highlighting would really add to readability of the snippets. Good job though.

userbinator 13y ago

But if we do buy the proposition that OO is a good idea for our domain, shouldn’t we ask ourselves why we aren’t using it for our classes? "If X is a good thing, why aren't we using more X?" No. I've seen horribly convoluted and overly complex code written as a result of following this sort of dogma with things like design patterns. OOP can be incredibly useful when applied correctly, but don't think that it's a panacea or that "OOP-ness" is somehow directly correlated with code quality. Layers of abstraction and encapsulation are very good at hiding bugs too, and IMHO they're overrated.

otikik 13y ago

I like it as a theoretical exercise. I would not use it in production.

rubysucks 13y ago

Oh my goodness. There are so many problems with this. 1. Giving the code to someone else to maintain is going to be a nightmare. You'll have to spend so much time explaining each iteration of abstraction. 2. You have spent so much valuable time abstracting and at the end of it, getting little functionality for your troubles. 3. You are attempting to skew the very nature of Javascript. It was designed the way it is for a reason. Meddling with this is going to result in a multitude of unforeseen problems, such as performance and debugging issues. Solving a lot of these problems is going to require thorough testing and absolving layers of abstraction. Theoretically, these ideas are cool. They look good in a GitHub repo. But in the real world, there's simply no place for this.