 <p>You have a couple of choices. You can isolate the common functionality into a third object that <code>Class1</code> and <code>Class2</code> share (aggregation), or you can actually create a hierarchy of objects (inheritance). I'll talk about inheritance here.</p> <p>JavaScript doesn't have classes, it's a prototypical language. An object instance is "backed" by a <em>prototype</em> object. If you ask the instance for a property it doesn't have (and functions are attached to objects as properties), the JavaScript interpreter checks the prototype behind the object to see if <em>it</em> has the property (and if not, the prototype behind <em>that</em> object, etc., etc.). This is how prototypical inheritance works.</p> <p>JavaScript is an unusual prototypical language in that, until recently, there was no way to create an object and assign its prototype <em>directly</em>; you had to do it through constructor functions. If you're using class-based terminology, you're probably going to be more comfortable with constructor functions anyway. :-)</p> <p>Here's a basic inheritance setup (this is not how I would actually do this, more on that below):</p> <pre><code>// Constructs an Vehicle instance function Vehicle(owner) { this.owner = owner; } // Who's this Vehicle's owner? Vehicle.prototype.getOwner = function() { return this.owner; }; // Constructs a Car instance function Car(owner) { // Call super's initialization Vehicle.call(this, owner); // Our init this.wheels = 4; } // Assign the object that will "back" all Car instances, // then fix up the `constructor` property on it (otherwise // `instanceof` breaks). Car.prototype = new Vehicle(); Car.prototype.constructor = Car; // A function that drives the car Car.prototype.drive = function() { }; </code></pre> <p>Now we can use <code>Car</code> and get the features of <code>Vehicle</code>:</p> <pre><code>var c = new Car("T.J."); alert(c.getOwner()); // "T.J.", retrived via Vehicle.prototype.getOwner </code></pre> <p>The above is a bit awkward and it has a couple of issues with when things happen that can be tricky. It also has the problem that most of the functions are anonymous, and I don't like anonymous functions (function names <a href="http://blog.niftysnippets.org/2010/03/anonymouses-anonymous.html" rel="nofollow">help your tools help you</a>). It's also awkward to call your prototype's version of a function if you also have a copy of it (e.g., a "supercall"&nbsp;&mdash; not an uncommon operation with hierarchies). For that reason, you see a lot of "frameworks" for building hierarchies, usually using class-based terminology. Here's a list of some of them:</p> <ul> <li>The <code>Class</code> feature of <a href="http://prototypejs.org/" rel="nofollow">Prootype</a>, a general-purpose JavaScript library</li> <li>Dean Edwards' <a href="http://code.google.com/p/base2/" rel="nofollow">base2</a></li> <li>John Resig's <a href="http://ejohn.org/blog/simple-javascript-inheritance/" rel="nofollow">Simple JavaScript Inheritance</a> (Resig being the person who created jQuery)</li> <li>Er, um, <a href="http://blog.niftysnippets.org/2009/09/simple-efficient-supercalls-in.html" rel="nofollow">mine</a>&nbsp;&mdash; which as far as I know is being used by about three people. I did it because I had issues with decisions each of the above made. I will be updating it to not use class terminology (and actually releasing it as a tiny library, rather than just a blog post), because none of these adds classes to JavaScript, and acting as though they do misses the point of JavaScript prototypical model.</li> </ul> <p>Of those four, I'd recommend Resig's or mine. Resig's uses function decompilation (calling <code>toString</code>&nbsp; on function instances, which has never been standardized and doesn't work on some platforms), but it works even if function decompilation doesn't work, it's just slightly less efficient in that case.</p> <p>Before jumping on any of those, though, I encourage you to look at the <a href="http://javascript.crockford.com/prototypal.html" rel="nofollow">true prototypical approach</a> advocated by Douglas Crockford (of JSON fame, also a big wig at YUI). Crockford had a great deal of input on the <a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm" rel="nofollow">latest version of ECMAScript</a>, and some of his ideas (most notably <code>Object.create</code>) are now part of the latest standard and are finding their way into browsers. Using <code>Object.create</code>, you can <em>directly</em> assign a prototype to an object, without having a constructor function.</p> <p>I prefer constructor functions (with my syntactic help) for places where I need inheritance, but Crockford's approach is valid, useful, and gaining popularity. It's something you should know about and understand, and then choose when or whether to use.</p>