Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you just translate your Java code into JavaScript, you're going to be constantly fighting JavaScript's object model, which is prototype-based, not class-based. There are no private properties on objects, no final properties unless you're using an <a href="http://es5.github.com/" rel="noreferrer">ES5-compatible</a> engine (you haven't mentioned what your target runtime environment is; browsers aren't use ES5-compatible, it'll be another couple of years), no <em>classes</em> at all in fact.</p> <p>Instead, I recommend you thoroughly brief yourself on how object orientation actually works in JavaScript, and then build your application fully embracing how JavaScript does it. This is non-trivial, but rewarding.</p> <p>Some articles that may be of use. I start with closures because really understanding closures is absolutely essential to writing JavaScript, and most "private member" solutions rely on closures. Then I refer to a couple of articles by Douglas Crockford. Crockford is required reading if you're going to work in JavaScript, even if you end up disagreeing with some of his conclusions. Then I point to a couple of articles specifically addressing doing class-like things.</p> <ul> <li><a href="http://blog.niftysnippets.org/2008/02/closures-are-not-complicated.html" rel="noreferrer"><em>Closures are not complicated</em> - Me</a></li> <li><a href="http://javascript.crockford.com/prototypal.html" rel="noreferrer"><em>Prototypical inheritance in JavaScript</em> - Crockford</a></li> <li><a href="http://javascript.crockford.com/private.html" rel="noreferrer"><em>Private Members in JavaScript</em> - Crockford</a></li> <li><a href="http://blog.niftysnippets.org/2009/09/simple-efficient-supercalls-in.html" rel="noreferrer"><em>Simple, Efficient Supercalls in JavaScript</em> - Me</a> Includes syntactic sugar to make it easier to set up hierarchies of objects (it uses class-based terminology, but actually it's just prototypical inheritance), including calling "superclass" methods.</li> <li><a href="http://blog.niftysnippets.org/2009/09/private-methods-in-javascript.html" rel="noreferrer"><em>Private Members in JavaScript</em> - Me</a> Listing Crockford's solution and others</li> <li><a href="http://blog.niftysnippets.org/2008/03/mythical-methods.html" rel="noreferrer"><em>Mythical Methods</em> - Me</a></li> <li><a href="http://blog.niftysnippets.org/2008/04/you-must-remember-this.html" rel="noreferrer">You must remember <code>this</code> - Me</a></li> </ul> <p>Addressing some of your specific questions:</p> <blockquote> <p>what do you suggest to do to create class properties? Should I use getter/setters? I don't like to do this:</p> <p><code>myObj.prop = "hello"</code></p> <p>because I could use non existing properties, and it would be easy to mispell something..</p> </blockquote> <p>I don't, I prefer using <a href="http://en.wikipedia.org/wiki/Test-driven_development" rel="noreferrer">TDD</a> to ensure that if I do have a typo, it gets revealed in testing. (A good code-completing editor will also be helpful here, though <em>really</em> good JavaScript code-completing editors are thin on the ground.) But you're right that getters and setters in the Java sense (methods like <code>getFoo</code> and <code>setFoo</code>) <em>would</em> make it more obvious when you're creating/accessing a property that you haven't defined in advance (e.g., through a typo) by causing a runtime error, calling a function that doesn't exist. (I say "in the Java sense" because JavaScript as of ES5 has <a href="http://es5.github.com/#x8.10.4" rel="noreferrer">a different kind of "getters" and "setters"</a> that are transparent and wouldn't help with that.) So that's an argument for using them. If you do, you might look at using Google's <a href="http://code.google.com/closure/compiler/" rel="noreferrer">Closure compiler</a> for release builds, as it will inline them.</p> <blockquote> <p>How can I get javascript to be a bit more like java, with private...</p> </blockquote> <p>I've linked Crockford's article on private members, and my own which lists other ways. The very basic explanation of the Crockford model is: You use a variable in the context created by the call to your constructor function and a function created within that context (a closure) that has access to it, rather than an object property:</p> <pre><code>function Foo() { var bar; function Foo_setBar(b) { bar = b; } function Foo_getBar() { return bar; } this.setBar = Foo_setBar; this.getBar = Foo_getBar; } </code></pre> <p><code>bar</code> is not an object property, but the functions defined in the context with it have an enduring reference to it. This is totally fine if you're going to have a smallish number of <code>Foo</code> objects. If you're going to have thousands of <code>Foo</code> objects you might want to reconsider, because <em>each and every</em> <code>Foo</code> object has its own two functions (really genuinely different <code>Function</code> instances) for <code>Foo_getBar</code> and <code>Foo_setBar</code>.</p> <p>You'll frequently see the above written like this:</p> <pre><code>function Foo() { var bar; this.setBar = function(b) { bar = b; }; this.getBar = function() { return bar; }; } </code></pre> <p>Yes, it's briefer, but now the functions don't have names, and giving your functions names <a href="http://blog.niftysnippets.org/2010/03/anonymouses-anonymous.html" rel="noreferrer">helps your tools help you</a>.</p> <blockquote> <p>How can I get javascript to be a bit more like java, with...public final properties</p> </blockquote> <p>You can define a Java-style getter with no setter. Or if your target environment will be ES5-compliant (again, browsers aren't yet, it'll be another couple of years), you could use the new <a href="http://es5.github.com/#x15.2.3.6" rel="noreferrer"><code>Object.defineProperty</code></a> feature that allows you to set properties that cannot be written to.</p> <p>But my main point is to embrace the language and environment in which you're working. Learn it well, and you'll find that different patterns apply than in Java. Both are great languages (I use them both a lot), but they work differently and lead to different solutions.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload