

Methods & Properties with Javascript OOP - flameorb
http://www.re-cycledair.com/methods-properties-with-javascript-oop

======
itsnotlupus
This is the slow, inefficient way of doing OOP in JS.

Pros:

1\. You don't have to understand JavaScript to use it

2\. You get to have "private" members

3\. You don't have to use "this". See point #1.

Cons:

1\. Object churn: Every "new" operation creates an object that you proceed to
immediately discard

2\. Speed: Object creation is slow.

3\. Maintenance: Object inheritance is quirky. Lack of "protected" members
ends up forcing you to rewrite your "private" members as "public" one,
negating pro #2.

4\. OOP: The "instanceof" operator won't work on your instanciated objects.
You'll need to define your own introspection mechanism to tell which instance
comes from which class.

My take:

\- It has a lot in common with the module pattern, commonly used to namespace
things.

\- It's okay to use it, or something like it, for objects that get relatively
few instances.

\- If you're going to ignore "this" in your constructor, don't use the "new"
operator to create your objects.

\- Don't use this pattern for something that gets instantiated a lot.

\- Think carefully before using this pattern if you intend to use any kind of
class inheritance with it.

------
pabloPXL
Well, although simpler and less error prone, the 'self' method is quite less
optimal than the prototype way. A quick test reveals that the first technique
consumes much more memory (100000 new instances pushed into an array):
<http://imgur.com/YVkny>

self: var a = []; function b(){ var c = {}; c.d = function(){}; return c };
for (var e = 0, f = 100000; e < f; e++) a.push(new b)

prototype: var a = []; function b(){ return this }; b.prototype.c =
function(){}; for (var d = 0, e = 100000; d < e; d++) a.push(new b)

------
wyuenho
It would nice if there was an article to summarize all the ways of emulating a
class in Javascript. Over the years I've seen a dozen different ways and I
never know what's the pros and cons of them, or at least the principals behind
them. All these different ways don't help me when I'm looking at someone
else's code. There are just way too many ways to do it.

~~~
cygx
While in principle, Javascript's object system is prototypal, in practice you
can use it as if it were class-based; in fact, before the addition of
Object.create() with ES5, you only could get proper prototypal inheritance
through non-standard extensions like __proto__ or a hack using temporary
constructors.

There's no syntactic support for class-based inheritance, so it's a bit
verbose, but not really complicated:

    
    
      function AClass(foo) {
          this.foo = foo;
      }
    
      // methods are shared between instances
      AClass.prototype.alertFoo = function() {
          alert(this.foo);
      };
    
      function ASubClass(foo, bar) {
          // call parent constructor
          AClass.call(this, foo);
          this.bar = bar;
      }
    
      // simulate inheritance via method aggregation
      for(var name in AClass.prototype) {
          if(AClass.prototype.hasOwnProperty(name))
              ASubClass.prototype[name] = AClass.prototype[name];
      }
    
      // alternatively, use proper inheritance
      ASubClass.prototype = Object.create(AClass.prototype);
    
      ASubClass.prototype.alertFooBar = function() {
          alert(this.foo + ' ' + this.bar);
      };
    

This is what I'd call the idiomatic way to implement classes in Javascript.

Instead of adding methods to the prototype, you can also add them to the
instance within the constructor. This way, you can simulate private members as
such methods close over the constructor's lexical scope -- but this comes with
a performance penalty.

Most custom class implementations just provide sugar over these patterns.

~~~
chmike
In your example cygx, this.foo is a public member variable. As you say, it is
possible to have private member variables but this implies some constrains.

The following example illustrate how one may have private and public members
as well as private and public methods and how to access them.

    
    
        function AClass(foo) 
        {
            this.foo = foo;  // public member variable
            var bar = "bar"; // private member variable
            function fun1()  // private method
            {
               bar = this.foo; // private and public var access
            }
            this.fun2 = function () // public privileged method
            {
               bar = this.foo; // private and public var access
            } 
        }
    

A public method defined with prototype doesn't allow to access private member
variables. This is the difference between privileged methods and public
methods. The privileged method can access private methods because of closure.

This is all very different from other OOP languages. I just add these for
clarification. It may be helpful to some readers.

By convention one may also add an underscore in front of private members and
function identifiers to make the difference clearly visible in the code.

Would Object.create also inherit private functions and members ?

~~~
cygx
_Would Object.create also inherit private functions and members ?_

No, it would not - these so-called private members and methods have nothing to
do with inheritance, but rather lexical closure.

However, as the super constructor is called, priviledged methods will be
present and still have access to the private variables.

See also <http://stackoverflow.com/a/1441692/48015> for a more comprehensive
overview over different access levels.

~~~
chmike
Thank you very much. It's the first time I see this pattern and a clear
specification. I used privileged methods everywhere instead of shared public
methods based on this article: <http://javascript.crockford.com/private.html>

The missing infos in the StackOverflow answer are how do one instantiate such
class and access it's methods and public and shared members ? var obj = new
MyObj() ? obj.publicSharedVar ?

------
chmike
I don't understand the benefit of this method using a self object compared to
the classical method using this which is so much simpler. This method doesn't
make it clearer for people with other OOP languages experience.

------
nihil_admirari
This is a terrible article illustrating a complete lack of understanding of
the JS prototype inheritance mechanism. But don't tell the author, he'd remove
your comment.

------
user2459
It's all about scope. What you should do is read about scope in javascript and
get to know it well. Then stuff like this will come naturally or you'll at
least understand why people program like this and that it's not just some
language peculiarity.

MDN:
[https://developer.mozilla.org/en/JavaScript/Reference/Functi...](https://developer.mozilla.org/en/JavaScript/Reference/Functions_and_function_scope)

short stack overflow: [http://stackoverflow.com/questions/500431/javascript-
variabl...](http://stackoverflow.com/questions/500431/javascript-variable-
scope)

------
Jebus
You are copying the code for each instance. Use prototype instead.

~~~
TazeTSchnitzel
Doesn't that break using variables owned by the constructor?

