The javascript prototype-based object-oriented programming style is interesting, but there are a lot of situations where you need the ability to create objects from a class.
For instance in a vector drawing application, the workspace will usually be empty at the beginning of the drawing : I cannot create a new "line" from an existing one. More generally, every situation where objects are being dynamically created require the use of classes.
I've read a lot of tutorials and the book "Javascript : the good parts", but yet it seems to me that there is no way to define classes that respect 1) encapsulation and 2) efficient member methods declaration (I mean : member methods that are being defined once, and shared among every class instances).
To define private variables, closures are being used :
function ClassA()
{
var value = 1;
this.getValue = function()
{
return value;
}
}
The problem here is that every instance of "ClassA" will have its own copy of the member function "getValue", which is not efficient.
To define member functions efficiently, prototype is being used :
function ClassB()
{
this.value = 1;
}
ClassB.prototype.getValue = function()
{
return this.value;
}
The problem here is that the member variable "value" is public.
I don't think that this issue can be solved easily, since "private" variables need to be defined DURING object creation (so that the object can have access to its context of creation, without exposing thoses values) whereas prototype-based member functions definition has to be done AFTER object creation, so that prototype makes sense ("this.prototype" does not exists, I've checked).
Or am I missing something ?
EDIT :
First of all, thank you for your interesting answers.
I just wanted to add a little precision to my initial message :
What I really want to do is to have 1) private variables (encapsulation is good, because people only have access to what they need) and 2) efficient member methods declaration (avoid copies).
It seems that simple private variables declaration can really only be achieved via closure in javascript, that's essentially why I focused on the class based approach. If there is a way to achieve simple private variables declaration with a prototype based approach, that's okay for me, I'm not a fierce class-based approach proponnent.
After reading the answers, it seems like the simple solution is to forget about privates, and use a special coding conventions to detter other programmers from accessing "private" variables directly...
And I agree, my title / first sentence was misleading regarding the issue I wanted to discuss here.
Shh, come here! Wanna hear a secret?
Classical inheritance is a tested and tried approach.
It is useful to implement it in JavaScript often. Classes are a nice concept to have and having templates for modeling our world after objects is awesome.
Classical inheritance is just a pattern. It's perfectly OK to implement classical inheritance in JavaScript if it's the pattern you need for your use case.
Prototypical inheritance focuses on sharing functionality and that's awesome (dinasaur drumstick awesome), but in some cases you want to share a data-scheme and not functionality. That's a problem prototypical inheritance does not address at all.
So, you're telling me classes are not evil like everyone keeps telling me?
No, they are not. What the JS community frowns upon is not the concept of classes, it's limiting yourself to just classes for code reuse. Just like the language does not enforce strong or static typing, it doesn't enforce schemes on object structure.
In fact, behind the scene clever implementations of the language can turn your normal objects to something resembling classical inheritance classes.
So, how do classes work in JavaScript
Well, you really only need a constructor:
function getVehicle(engine){
return { engine : engine };
}
var v = getVehicle("V6");
v.engine;//v6
We now have a vehicle class. We didn't need to define a Vehicle class explicitly using a special keyword. Now, some people don't like to do things this way and are used to the more classical way. For this JS provides (silly imho) syntactic sugar by doing:
function Vehicle(engine){
this.engine = engine;
}
var v = new Vehicle("V6");
v.engine;//v6
That's the same thing as the example above for the most part.
So, what are we still missing?
Inheritance and private members.
What if I told you basic subtyping is very simple in JavaScript?
JavaScript's notion of typing is different than what we're used to in other languages. What does it mean to be a sub-type of some type in JS?
var a = {x:5};
var b = {x:3,y:3};
Is the type of b a sub type of the type of a? Let's say if it is according to (strong) behavioral subtyping (the LSP):
<<<< Begin technical part
Contravariance of method arguments in the subtype - Is fully preserved in this sort of inheritance.
Covariance of return types in the subtype - Is fully preserved in this sort of inheritance.
No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype. - Is fully preserved in this sort of inheritance.
Also,
Preconditions cannot be strengthened in a subtype.
Postconditions cannot be weakened in a subtype.
Invariants of the supertype must be preserved in a subtype.
The history rule
All of these are again, are up to us to keep. We can keep them as tightly or loosly as we want, we don't have to, but we surely can.
So matter of fact, as long as we abide to these rules above when implementing our inheritance, we're fully implementing strong behavioral subtyping, which is a very powerful form of subtyping (see note*).
>>>>> End technical part
Trivially, one can also see that structural subtyping holds.
How would this apply to our Car example?
function getCar(typeOfCar){
var v = getVehicle("CarEngine");
v.typeOfCar = typeOfCar;
return v;
}
v = getCar("Honda");
v.typeOfCar;//Honda;
v.engine;//CarEngine
Not too hard, was it? What about private members?
function getVehicle(engine){
var secret = "Hello"
return {
engine : engine,
getSecret : function() {
return secret;
}
};
}
See, secret is a closure variable. It's perfectly "private", it works differently than privates in languages like Java, but it's impossible to access from the outside.
What about having privates in functions?
Ah! That's a great question.
If we want to use a private variable in a function we share on the prototype we need to firrst understand how JS closures and functions work.
In JavaScript functions are first class. This means you can pass functions around.
function getPerson(name){
var greeting = "Hello " + name;
return {
greet : function() {
return greeting;
}
};
}
var a = getPerson("thomasc");
a.greet(); //Hello thomasc
So far so good, but we can pass that function bounded to a around to other objects! This lets you do very loose decoupling which is awesome.
var b = a.greet;
b(); //Hello thomasc
Wait! How did b know the person's name is thomasc? That's just the magic of closures. Pretty awesome huh?
You might be worried about performance. Let me tell you how I learned to stop worrying and started to love the optimizing JIT.
In practice, having copies of functions like that is not a big issue. Functions in javascript are all about well, functionality! Closures are an awesome concept, once you grasp and master them you see it's well worth it, and the performance hit really isn't that meaningful. JS is getting faster every day, don't worry about these sort of performance issues.
If you think it's complicated, the following is also very legitimate. A common contract with other developers simply says "If my variable starts with _ don't touch it, we are both consenting adults". This would look something like:
function getPerson(name){
var greeter = {
greet : function() {
return "Hello" +greeter._name;
}
};
greeter._name = name;
return greeter;
}
Or in classical style
function Person(name){
this._name = name;
this.greet = function(){
return "Hello "+this._name;
}
}
Or if you'd like to cache the function on the prototype instead of instantiate copies:
function Person(name){
this._name = name;
}
Person.prototype.greet = function(){
return "Hello "+this._name;
}
So, to sum it up:
You can use classical inheritance patterns, they are useful for sharing types of data
You should also use prototypical inheritance, it is just as potent, and much more in cases you want to share functionality.
TheifMaster pretty much nailed it. Having privates private is really not a big deal as one might think in JavaScript, as long as your code defines a clear interface this should not be problematic at all. We're all concenting adults here :)
*The clever reader might think: Huh? Weren't you tricking me there with the history rule? I mean, property access isn't encapsulated.
I say no, I was not. Even if you don't explicitly encapsulate the fields as private, you can simply define your contract in a way that does not access them. Often like TheifMaster suggested with _. Also, I think the history rule is not that big of a deal in a lot of such scenarios as long as we're not changing the way property access treats properties of the parent object. Again, it's up to us.
I don't want to be discouraging since you seem to be a fairly new member of StackOverflow, however I'm going to have to be a little in your face and say that it's a really bad idea to try to implement classical inheritance in JavaScript.
Note: When I say that it's a bad idea to implement classical inheritance in JavaScript I mean that trying to simulate actual classes, interfaces, access modifiers, etc. in JavaScript is a bad idea. Nevertheless, classical inheritance as a design pattern in JavaScript is useful as it's just syntactic sugar for prototypal inheritance (e.g. maximally minimal classes). I use this design pattern in my code all the time (a la augment).
JavaScript is a prototypal object-oriented programming language. Not a classical object-oriented programming language. Sure, you can implement classical inheritance on top of JavaScript but before you do keep the following things in mind:
You're going against the spirit of the language, which means that you'll be faced with problems. Lots of problems - performance, readability, maintainability, etc.
You don't need classes. Thomas, I know that you truly believe that you need classes but trust me on this. You don't.
For your sake I'll provide two answers to this question. The first one will show you how to do classical inheritance in JavaScript. The second one (which I recommend) will teach you to embrace prototypal inheritance.
Classical Inheritance in JavaScript
Most programmers start with trying to implement classical inheritance in JavaScript. Even JavaScript Gurus like Douglas Crockford tried to implement classical inheritance in JavaScript. I too tried to implement classical inheritance in JavaScript.
First I created a library called Clockwork and then augment. However I wouldn't recommend you to use either of these libraries because they go against the spirit of JavaScript. The truth is that I was still an amateur JavaScript programmer when I wrote these classical inheritance libraries.
The only reason I mention this is because everyone is an amateur at some point of time, and although I would prefer that you didn't use classical inheritance patterns in JavaScript, I can't expect you to understand why prototypal inheritance matters just yet.
You can't learn how to cycle without falling down a few times. I believe you're still in the learning phase with respect to prototypal inheritance. Your need for classical inheritance is like the training wheels on cycles.
Nevertheless, training wheels are important. If you want there are some classical inheritance libraries out there which should make you more comfortable writing code in JavaScript. One such library is jTypes. Just remember to take off the training wheels when you are confident of your skills as a JavaScript programmer.
Note: Personally I don't like jTypes one bit.
Prototypal Inheritance in JavaScript
I'm writing this section as a milestone for you so that you can come back later and know what to do next when you are ready to learn about true prototypal inheritance.
First of all the following line is wrong:
The javascript prototype-based object-oriented programming style is interesting, but there are a lot of situations where you need the ability to create objects from a class.
This is wrong because:
You will never need to create objects from a class in JavaScript.
There is no way to create a class in JavaScript.
Yes it's possible to simulate classical inheritance in JavaScript. However you're still inheriting properties from objects and not classes. For example, ECMAScript Harmony classes are just syntactic sugar for the classical pattern of prototypal inheritance.
In the same context the example you gave is also wrong:
For instance in a vector drawing application, the workspace will usually be empty at the beginning of the drawing : I cannot create a new "line" from an existing one. More generally, every situation where objects are being dynamically created require the use of classes.
Yes you can create a new line from an existing one even though the workspace is empty in the beginning. What you need to understand is that the line is not actually drawn though.
var line = {
x1: 0,
y1: 0,
x2: 0,
y2: 0,
draw: function () {
// drawing logic
},
create: function (x1, y1, x2, y2) {
var line = Object.create(this);
line.x1 = x1;
line.y1 = y1;
line.x2 = x2;
line.y2 = y2;
return line;
}
};
Now you can draw your the above line by simply calling line.draw or else you could create a new line from it:
var line2 = line.create(0, 0, 0, 100);
var line3 = line.create(0, 100, 100, 100);
var line4 = line.create(100, 100, 100, 0);
var line5 = line.create(100, 0, 0, 0);
line2.draw();
line3.draw();
line4.draw();
line5.draw();
The lines line2, line3, line4 and line5 form a 100x100 square when drawn.
Conclusion
So you see you really don't need classes in JavaScript. Objects are enough. Encapsulation can be easily achieved using functions.
That being said you can't have public functions of each instance access the private state of the object without each instance having its own set of public functions.
This is not a problem however because:
You don't really need private state. You may think that you do, but you really don't.
If you really want to make a variable private then as ThiefMaster mentioned just prefix the variable name with an underscore and tell your users not to mess with it.
Aight, here's my attempt at solving this particular issue, although I think following conventions it's a better approach, ie. prefix your variables with _. Here I just keep track of the instances in an array, they can then be removed with a _destroy method. I'm sure this can be improved but hopefully it will give you some ideas:
var Class = (function ClassModule() {
var private = []; // array of objects of private variables
function Class(value) {
this._init();
this._set('value', value);
}
Class.prototype = {
// create new instance
_init: function() {
this.instance = private.length;
private.push({ instance: this.instance });
},
// get private variable
_get: function(prop) {
return private[this.instance][prop];
},
// set private variable
_set: function(prop, value) {
return private[this.instance][prop] = value;
},
// remove private variables
_destroy: function() {
delete private[this.instance];
},
getValue: function() {
return this._get('value');
}
};
return Class;
}());
var a = new Class('foo');
var b = new Class('baz');
console.log(a.getValue()); //=> foo
console.log(b.getValue()); //=> baz
a._destroy();
console.log(b.getValue()); //=> baz
You don't need private/public at runtime. These are enforceable statically. Any project complex enough to enforce private properties are not used outside will have a build/pre-process step, which you can use
to verify the fact. Even languages with syntax for private/public have a way to access private at runtime.
As for defining class-based objects, the constructor+prototype you are using is the simplest and most efficient way. Any kind of additional wizardry will
be more complex and less performant.
Although you can cache prototype so you don't have to repeat ClassB.prototype. all the time:
//in node.js you can leave the wrapper function out
var ClassB = (function() {
var method = ClassB.prototype;
function ClassB( value ) {
this._value = value;
}
method.getValue = function() {
return this._value;
};
method.setValue = function( value ) {
this._value = value;
};
return ClassB;
})();
The above does not require any library and you can easily create a macro for it.
Also, in this case even a regex is enough to verify
that "private" properties are used correctly. Run /([a-zA-Z$_-][a-zA-Z0-9$_-]*)\._.+/g through the file and see that the first match
is always this. http://jsfiddle.net/7gumy/
It's impossible as far as I know without other instances influencing the value, so if it's a constant you're still good by wrapping it in a function like this:
(function( context ) {
'use strict';
var SOME_CONSTANT = 'Hello World';
var SomeObject = function() {};
SomeObject.prototype.sayHello = function() {
console.log(SOME_CONSTANT);
};
context.SomeObject = SomeObject;
})( this );
var someInstance = new SomeObject();
someInstance.sayHello();
The best you could do is annotate that a property shouldn't be touched by using an underscore like this._value instead of this.value.
Note that private functions are possible by hiding them in a function:
(function( context ) {
'use strict';
var SomeObject = function() {};
var getMessage = function() {
return 'Hello World';
};
SomeObject.prototype.sayHello = function() {
console.log(getMessage());
};
context.SomeObject = SomeObject;
})( this );
var someInstance = new SomeObject();
someInstance.sayHello();
Here is an example of 2 'Classes' extending and interacting with each other: http://jsfiddle.net/TV3H3/
If you really want private entities on a per instance basis, but still want to inherit your methods, you could use the following set-up:
var Bundle = (function(){
var local = {}, constructor = function(){
if ( this instanceof constructor ) {
local[(this.id = constructor.id++)] = {
data: 123
};
}
};
constructor.id = 0;
constructor.prototype.exampleMethod = function(){
return local[this.id].data;
}
return constructor;
})();
Now if you create a new Bundle, the data value is locked away inside:
var a = new Bundle(); console.log( a.exampleMethod() ); /// 123
However you now get into the debate as to whether you should truly have private values in JavaScript. As far as I've found it's always better for those that may need to extend your code—even yourself—to have open access to everything.
There are also hidden downsides to the above pattern, besides not being so readable, or being clunky to access "private" values. One fact is that every single instance of Bundle will retain a reference to the local object. This could mean—for example—if you created thousands of Bundles, and deleted all but one of them, the data held in local would not be garbage collected for all Bundles ever created. You'd have to include some deconstruction code to fix that... basically making things more complicated.
So I'd recommend dropping the idea of private entities / properties, whichever pattern you decide to go for... object-based or constructor. The benefit of JavaScript is that all these different approaches are possible—it's no-where-near as clear cut as class-based languages—which some could argue makes things confusing, but I like the freedom JavaScript lends towards being quick and expressive.
with regards this statement in your question:
For instance in a vector drawing application, the workspace will usually be empty at the beginning of the drawing : I cannot create a new "line" from an existing one. More generally, every situation where objects are being dynamically created require the use of classes.
You seem to be under the misunderstanding that objects in Javascript can only be made by cloning existing objects, which would backtrack to the problem of "okay but what about the very first object? that can't be made by cloning an existing object because there aren't any existing objects."
However you can make objects from scratch, and the syntax for that is as simple as var object = {}
I mean, that's the simplest possible object, an empty object. More useful of course would be an object with stuff in it:
var object = {
name: "Thing",
value: 0,
method: function() {
return true;
}
}
and so on, and now you're off to the races!
There are cleverer people than I answering this question, but I wanted to note one part in particular that you just edited in - the private variable part.
You can simulate this using closures; an awesome construct which allows a function to have it's own environment. You could do this:
var line = (function() {
var length = 0;
return {
setLen : function (newLen) {
length = newLen;
},
getLen : function () {
return length;
}
};
}());
This will set line to be an object with the setLen and getLen methods, but you'll have no way of manually accessing length without using those methods.
Related
I have always been fascinated by the notion of "prototype" in javascript, and I have used that to model business domains. But I have not used javascript for actual programming until quite recently. So now I am wondering how to really make use thinking in prototypes rather than classes. Recently javascript gained syntactic sugar with class ... extends { constructor() { ... } ... } and all that stuff that makes javascript appear more like Java. But it detracts away from the prototype orientation.
My question is, if my following intuitions jive and what I should read on if I am not interested in just reproducing Java in the browser (got decades of Java under my belt) but rather, how to really use the prototype paradigm.
First thing that I have always admired but never understood is why a class in javascript is implemented as a function?
> new (function(x) { this.foo = x; })(99)
< { foo: 99 }
It is so cool, but why is that? What's the deep philosophy behind calling new on a function, and effectively saying "a class is nothing but a constructor function". What if I call this function without new? Then this is whatever global object and it really doesn't make sense to add foo onto this, or does it? I bet it makes profound sense, but I just don't understand it.
Next there is the question whether I can build a system without ever calling constructors. This is where the prototype oriented programming comes along, which I apply to real business object modeling.
For example, I have a plan for a car,
car = {
type: "sedan",
material: "aluminum"
}
which essentially is a model of the car, that is, there is some mapping between the model and a real car. Let's say my plan says it has an aluminum body, then any real world instance of this car also has an aluminum body.
myCar = { plate: "FR-AS-2345" }
myCar.__proto__ = car
so now I can query:
> myCar.plate
< 'FR-AS-2345'
> myCar.type
< 'sedan'
Philosophically, what is a "real car" with respect to an information system anyway? Whether we describe the class of aluminum sedans or my car that's parked just outside, there is always a mapping of real world to information structure. And so, the structure of these car models are no different whether I define a universal aluminum sedan or my particular car.
Where this is really neat is in specification refinement. For example, I can say:
redCar = { color: "red" }
redCar.__proto__ = car
And if my car is actually red:
myCar.__proto__ = redCar
But I could also do something even cooler:
carsLikeMine = { plate = undefined }
carsLikeMine.__proto__ = myCar
so I was able to create a "class" from an instance, saying "just like mine but (of course) with an undefined license plate.
You get the gist. I could use
myCar.__proto__ = redCar
but I could also say
Object.setPrototypeOf(myCar, redCar)
which should I use?
And isn't there some easier way to do that? I was hoping I could somehow use the new operator:
yourCar = new carsLikeMine
but of course that doesn't work. However, I am sitting here pondering why not? I know formally the object is not a "constructor" function which new expects (what makes functions a "constructor" anyway, as I can apply the new operator on any function?) But why should there not be a simple operator some notation where I could say:
yourCar = new extend(carsLikeMine, { plate: "TÜ-PS-1234" })
Oh, so I can make my own prototype inheritance function:
function extend(prototype, object) {
// perhaps better also clone object first to prevent side-effect
const newObject = {}
Object.assign(newObject);
newObject.__proto__ = prototype;
return newObject;
}
Why am I the only one making such an extend function? Someone else must have long done this? This whole world of prototype oriented programming must have been explored and charted with all the "no entry" signs posted long ago. What should I read to get on top of that?
And finally, notice that in this prototype approach we do not call "constructors", so any programming that relies on constructors to create valid initialized objects is gone. Should I be concerned about this, or should one just learn to program without relying on constructors? (They are anyway unreliable, because javascript inherently does not protect its objects from change (and neither does Java once you learn to use reflection, I have set private variables on Java objects before).
I'd like to start by saying that I understand that JavaScript is a Classless language. My background is in Java, C++, and Objective-C which are all classic OOP languages that support Classes.
I'm expanding into Web Development and have been experimenting with JavaScript and learning its Patterns. Right now I'm working with the Constructor Pattern that simulates Classes with in JavaScript.
So this is my "practice" class:
function Car( model, year, miles ) {
this.model = model;
this.year = year;
this.miles = miles;
var privateVarTest = 10;
this.getPrivateVarTest = function() {
return privateVarTest;
}
this.setPrivateVarTest = function( value ) {
privateVarTest = value;
}
}
Car.prototype.toString = function() {
return this.model + " is a " + this.year + " model and has " +
this.miles + " miles.";
}
var myCar = new Car( "Ford Focus", "2006", "65,000" );
document.getElementById('notepad').innerHTML += '</br> Testing </br>';
document.getElementById('notepad').innerHTML += myCar.toString() + '</br>';
document.getElementById('notepad').innerHTML += myCar.model + '</br>';
document.getElementById('notepad').innerHTML += myCar.getPrivateVarTest() + '</br>';
myCar.setPrivateVarTest( 20 );
document.getElementById('notepad').innerHTML += myCar.getPrivateVarTest() + '</br>';
Now I like using the prototype way of defining functions, as it doesn't instantiate a new version of the function for each Car Object created. However, in classic OOP languages we make our variables private and create public functions/methods to set and get these variables as needed.
JavaScript being Classless there is no private or public key word for this use, so I thought I'd experiment with a method of "faking" a private variable, and that's when found that using var instead of this essential makes it unaccessible out side of the constructor, but I was able to define getters and setters that would allow me to.
Now finaly to my question, sorry about the long wind up. For Best Practices from experinced JavaScript programmers, would you make all variables private to follow the standards of other OOP languages, and set getters and setter (which can not be prototyped forcing a creation for each Object), or avoid them as much as possible since the this keyword basicly lets you get and set all you want, and ONLY use private for hard coding some internal data needed for the class?
Thank you for taking the time to read this and providing to the discussion, I'm really just trying to get a feel for the standards that are used as Best Practices by experinced Web Developers.
General OOP
I'm in the camp that getters and setters are largely completely pointless and silly regardless of what language you're writing code in.
For the most part, exposed properties should be rare since any property of an object should typically be within the object's domain so only the object should actually change its own internals as a side-effect of other actions, not because some other object directly told it to change something. There are exceptions I'm sure (there always are) but I can't remember the last time I needed to make one.
Furthermore, when properties are exposed, the only reason to expose with a method is because you either can't just expose the property due to language constraints (Java) or because some validation or notification has to happen when you change that property. Just tacking on methods Java-bean-style that do nothing more than actually alter or return properties does nothing to preserve encapsulation. You might as well just make the property public if you can.
But the real problem with wanting to get/set everything willy-nilly from all over the place is that you've basically just written chained procedural code and called it OOP. You still have a long winding series of things that can only be reasoned about in terms of one happening after the other. With OOP, the idea is to avoid that long winding spaghetti chain so you can view your architecture more from the perspective of larger constructs that own specific domains interacting with each other at key points. Without that, you're perhaps reducing the spaghetti a touch by at least categorizing your functions under namespaces so it's easier to know where to look for stuff but you're not really leveraging the key wins that OOP can provide your architecture.
The real value of private or in JS's case local constructor/factory-closur vars is signalling intent. If it's exposed, something external really should be changing it. If it isn't, then you've made it clear that the var is only the object's business.
JS OOP
My advice is to forget class-emulation in JS. It's completely unnecessary. Prototypes are elegant and easy once you understand them. Think of a constructor's prototype property as a kind of a backup object. If you call a method on an instance that it doesn't have, the next step is to check the instance's constructor's prototype object property. If that object doesn't have it, then its constructor's prototype object gets checked and so on until you finally reach the core Object constructor's prototype.
It's because of that lookup process that you can add new methods to a constructor on the fly and have all instances "inherit" it after they've been built but it's not really inheritance so much as a fallback process.
Inheritance in JS is stupid-easy. That doesn't mean you should do a ton of it though. Long chains of cascading inheritance is regarded as an anti-pattern in any language for good reason and due to the way the callback process works, it can also really kill perf if you're hammering on the call object through like 18 levels of prototypes for every little thing in JS. I would say prefer composite objects to inheritance and when inheritances seems like a wiser option, check yourself any time you're tempted to inherit through more than 2-3 prototype links in the chain.
Oh, and one JS gotcha to look out for on local instance vars in the constructors as private properties: that's just JS's closure rules within a function scope context in action really. Methods declared in the prototype or outside of the constructor function can't access those internal vars. Constructor functions invoked with the new keyword change the rules of what 'this' accesses and they leave an instance behind but are otherwise executed JS functions in every other way.
Other flavors of crazy but also crazy-powerful worth understanding in JS OOP are the apply, call, and now bind methods. I tend to see these more as things you'd want in a factory but they are very powerful.
Once you've mastered JS OOP, start understanding JS from a functional perspective and you'll discover it has a really powerful 1-2 punch combo going on. We can do just about anything very easily and with a minimum of code in JS. The design tradeoff is performance (which modern JIT compilers are handling surprisingly well) and that it gives you plenty of rope to hang yourself with. I prefer the rope. The self-lynching is no fun but that's part of the learning/developing better instincts process which happens much faster as a result and leads to more maintainable code in the long haul. Whereas Java basically forces OOP implementation but due to being overly protectionist in regards to devs doing dumb things to themselves, results in community wide adoption of practices that run completely counter to the whole point of OOP.
The short version:
Stop getting/setting a lot if you do, regardless of language. It drastically reduces the win factor of implementing OOP in the first place.
Prototypes are really simple, elegant, and powerful. Tinker with them. Learn them. But be warned. Classes might start to feel archaic, clumsy, and overwrought in comparison (although to be fair, completely necessary in non-interpreted languages).
To make JS work well for you, self-learn the crap out of whatever aspect of it you happen to be dealing with. The rewards in terms of raw elegant linguistic power are more than worth the time spent. JS is closer to Scheme than the languages you listed being familiar with so it's weird but it's not being weird arbitrarily or without design principles in mind and JS's dominating success in web UI is no accident, regardless of what people telling everybody we're "stuck with it" would have you believe.
Full disclosure: I don't love Java.
Update:
The es6 class keyword changes virtually nothing about OOP in JS. It's 100% syntax-sugar. IMO, the use of the word "class" isn't doing newcomers any favors but there are advantages/disadvantages to all three styles of object constructor/creation and object instantiation in JS and they're all worth knowing/understanding. Those three approaches are functions as constructors, Object.create, and now the class keyword.
We need to be aware of our tendency to want every new language we learn to behave identically to the last language we learned. Or the first. And so forth. Douglas Crockford has a great (albeit a bit dated) google talk, in which he muses, "Javascript is the only language I know of that people feel they don't need to learn before using it". That talk will answer a lot of questions you never knew you had, including the one you've asked here.
There's nothing wrong with writing setters and getters. There's rarely harm in doing work to keep one's own sanity. You will happen to have a 'C accent' when speaking JS, but at least you'll be clear in your intent to anyone reading your code.
My sanity saving tip for managing 'this' across scopes, always remember that you can save your current 'this' before entering a new context:
var self = this;
I avoid using prototype except in special cases by including my object methods within the scope of the declaration.
function MyClass(_arg){
var self = this;
this.arg = _arg;
this.returnArg = function(){
return self.arg;
}
}
var foo = new MyClass("bar");
foo.returnArg(); //"bar"
in case of OOP I have to say infact javascript provide some level of oop.
by that I mean 4 main concepts of OOP design could be implemented in javascript although it is not strong and very well defined as in Java or C++. lets check those concepts and I will try to provide an example for each of them.
1- Abstraction : here as I said before we can understand why OOP is not very well defined as in Java, in Java we implement Abstraction concept using Classes, Variables, interfaced,... but in javascript Abstraction is rather implicitly defined in contrast to other OOP languages such as Java.
2- Encapsulation : I guess an example will suffice here
function Student (stdName, stdEmail, stdAvg) {
this.name = theName;
this.email = theEmail;
this.avg = stdAvg;
}
here also as you see we define a "class" like concept using functions in fact if get type Student you'll see it is a function.
3,4 - Inheritance and Polymorphism :
the way that JavaScript achieves Inheritance and Polymorphism is different than Java or C++ because of its prototypial (to be honest I have no idea any other way to say that) approach.
const Gun = function(soundEffect){
this.soundEffect = soundEffect;
};
Gun.prototype.fire = function(){
console.log(this.soundEffect);
};
const DesertEagle = function(color,clipSize){
this.color = color;
this.clipSize = clipSize;
};
DesertEagle.prototype = new Gun("pew pew peeeew");
const myWeapon = new DesertEagle("black",15);
myWeapon.fire();
now in order to cover the public/private access for variables and functions we have to use some kind of technique to implement such concept. check the code below:
const Student = function(name, stdNumber, avg){
this.name = name;
this.stdNumber = stdNumber;
this.avg = avg;
var that = this; //NOTE : we need to store a reference to "this" in order for further calls to private members
this.publicAccess = { // a set of functions and variables that we want as public
describe: function () {
console.log(that.name + " : " + that.stdNumber);
},
avg: this.avg,
};
return this.publicAccess; // return set of public access members
};
const newStd = new Student("john", "123", "3.4");
newStd.describe();
// output: john : 123
console.log(newStd.avg)
// output: 3.4
in ES6 defining a class is mush easier but it is just syntax sugar it is still the same thing at the heart of it.
I hope it will help .
I also recommend you this article (Javascript design patterns) it will provide some helpful information about avascript capabilities and design patterns.
please accept my apology for my poor English.
TL;DR:
Do we need factories/constructors in prototypical OO? Can we make a paradigm switch and drop them completely?
The BackStory:
I've been toying with doing prototypical OO in JavaScript lately and find that 99% of OO done in JavaScript is forcing classical OO patterns into it.
My take on prototypical OO is that it involves two things. A static prototype of methods (and static data) and a data binding. We don't need factories or constructors.
In JavaScript these are Object literals containing functions and Object.create.
This would mean we can model everything as a static blueprint/prototype and a data binding abstraction that's preferably hooked straight into a document-style database. I.e. objects are taken out of the database and created by cloning a prototype with the data. This would mean there is no constructor logic, no factories, no new.
The Example code:
An pseudo example would be :
var Entity = Object.create(EventEmitter, {
addComponent: {
value: function _addComponent(component) {
if (this[component.type] !== undefined) {
this.removeComponent(this[component.type]);
}
_.each(_.functions(component), (function _bind(f) {
component[f] = component[f].bind(this);
}).bind(this));
component.bindEvents();
Object.defineProperty(this, component.type, {
value: component,
configurable: true
});
this.emit("component:add", this, component);
}
},
removeComponent: {
value: function _removeComponent(component) {
component = component.type || component;
delete this[component];
this.emit("component:remove", this, component);
}
}
}
var entity = Object.create(Entity, toProperties(jsonStore.get(id)))
The minor explanation:
The particular code is verbose because ES5 is verbose. Entity above is a blueprint/prototype. Any actual object with data would be created by using Object.create(Entity, {...}).
The actual data (in this case the components) is directly loaded from a JSON store and injected directly into the Object.create call. Of course a similar pattern is applied to creating components and only properties that pass Object.hasOwnProperty are stored in the database.
When an entity is created for the first time it's created with an empty {}
The actual Questions:
Now my actual questions are
Open source examples of JS prototypical OO?
Is this a good idea?
Is it in-line with the ideas and concepts behind prototypical OOP?
Will not using any constructors/factory functions bite me in the ass somewhere? Can we really get away with not using constructors. Are there any limitations using the above methodology where we would need factories to overcome them.
I don't think the constructor/factory logic is necessary at all, as long as you change how you think about Object-Oriented Programming. In my recent exploration of the topic, I've discovered that Prototypical inheritance lends itself more to defining a set of functions that use particular data. This isn't a foreign concept to those trained in classical inheritance, but the hitch is that these "parent" objects don't define the data to be operated on.
var animal = {
walk: function()
{
var i = 0,
s = '';
for (; i < this.legs; i++)
{
s += 'step ';
}
console.log(s);
},
speak: function()
{
console.log(this.favoriteWord);
}
}
var myLion = Object.create(animal);
myLion.legs = 4;
myLion.favoriteWord = 'woof';
So, in the above example, we create the functionality that goes along with an animal, and then create an object that has that functionality, along with the data necessary to complete the actions. This feels uncomfortable and odd to anyone who's used to classical inheritance for any length of time. It has none of the warm fuzziness of the public/private/protected hierarchy of member visibility, and I'll be the first to admit that it makes me nervous.
Also, my first instinct, when I see the above initialization of the myLion object is to create a factory for animals, so I can create lions, and tigers, and bears (oh my) with a simple function call. And, I think, that's a natural way of thinking for most programmers - the verbosity of the above code is ugly, and seems to lack elegance. I haven't decided whether that's simply due to classical training, or whether that's an actual fault of the above method.
Now, on to inheritance.
I have always understood inhertance in JavaScript to be difficult. Navigating the ins and outs of the prototype chain is not exactly clear. Until you use it with Object.create, which takes all the function-based, new-keyword redirection out of the equation.
Let's say we wanted to extend the above animal object, and make a human.
var human = Object.create(animal)
human.think = function()
{
console.log('Hmmmm...');
}
var myHuman = Object.create(human);
myHuman.legs = 2;
myHuman.favoriteWord = 'Hello';
This creates an object which has human as a prototype, which, in turn, has animal as a prototype. Easy enough. No misdirection, no "new object with a prototype equal to the prototype of the function". Just simple prototypal inheritance. It's simple, and straightforward. Polymorphism is easy, too.
human.speak = function()
{
console.log(this.favoriteWord + ', dudes');
}
Due to the way the prototype chain works, myHuman.speak will be found in human before it's found in animal, and thus our human is a surfer instead of just a boring old animal.
So, in conclusion (TLDR):
The pseudo-classical constructor functionality was kind of tacked on to JavaScript to make those programmers trained in classical OOP more comfortable. It is not, by any means, necessary, but it means giving up classical concepts such as member visibility and (tautologically) constructors.
What you get in return is flexibility, and simplicity. You can create "classes" on the fly - every object is, itself, a template for other objects. Setting values on child objects will not affect the prototype of those objects (i.e. if I used var child = Object.create(myHuman), and then set child.walk = 'not yet', animal.walk would be unaffected - really, test it).
The simplicity of inheritance is honestly mind-boggling. I've read a lot on inheritance in JavaScript, and written many lines of code attempting to understand it. But it really boils down to objects inherit from other objects. It's as simple as that, and all the new keyword does is muddle that up.
This flexibility is difficult to use to its fullest extent, and I'm sure I have yet to do it, but it's there, and it's interesting to navigate. I think most of the reason that it hasn't been used for a large project is that it simply isn't understood as well as it could be, and, IMHO, we're locked into the classical inheritance patterns we all learned when we were taught C++, Java, etc.
Edit
I think I've made a pretty good case against constructors. But my argument against factories is fuzzy.
After further contemplation, during which I've flip-flopped to both sides of the fence several times, I have come to the conclusion that factories are also unnecessary. If animal (above) were given another function initialize, it would be trivial to create and initialize a new object that inherits from animal.
var myDog = Object.create(animal);
myDog.initialize(4, 'Meow');
New object, initialized and ready for use.
#Raynos - You totally nerd sniped me on this one. I should be getting ready for 5 days of doing absolutely nothing productive.
As per your comment that the question is mainly "is constructor knowledge necessary?" I feel it is.
A toy example would be storing partial data. On a given data set in memory, when persisting I may only choose to store certain elements (either for the sake of efficiency or for data consistency purposes, e.g. the values are inherently useless once persisted). Let's take a session where I store the user name and the number of times they've clicked on the help button (for lack of a better example). When I persist this in my example, I do have no use for the number of clicks, since I keep it in memory now, and next time I load the data (next time the user logs in or connects or whatever) I will initialise the value from scratch (presumably to 0). This particular use case is a good candidate for constructor logic.
Aahh, but you could always just embed that in the static prototype: Object.create({name:'Bob', clicks:0}); Sure, in this case. But what if the value wasn't always 0 at first, but rather it was something that required computation. Uummmm, say, the users age in seconds (assuming we stored the name and the DOB). Again, an item that there is little use persisting, since it will need to be recalculated on retrieval anyway. So how do you store the user's age in the static prototype?
The obvious answer is constructor/initialiser logic.
There are many more scenarios, although I don't feel the idea is much related to js oop or any language in particular. The necessity for entity creation logic is inherent in the way I see computer systems model the world. Sometimes the items we store will be a simple retrieval and injection into a blueprint like prototype shell, and sometimes the values are dynamic, and will need to be initialised.
UPDATE
OK, I'm going to try for a more real-world example, and to avoid confusion assume that I have no database and need not persist any data. Let's say I'm making a solitaire server. Each new game will be (naturally) a new instance of the Game prototype. It is clear to me that their is initialiser logic required here (and lots of it):
I will, for example, need on each game instance not just a static/hard-coded deck of cards, but a randomly shuffled deck. If it were static the user would play the same game every time, which is clearly not good.
I may also have to start a timer to finish the game if the player runs out. Again, not something that can be static, since my game has a few requirements: the number of seconds is inversely related to the number of games the connected player has won so far (again, no saved info, just how many for this connection), and proportional to the difficulty of the shuffle (there is an algorithm that according to the shuffle results can determine the degree of difficulty of the game).
How do you do that with a static Object.create()?
Example of a staticly-clonable "Type":
var MyType = {
size: Sizes.large,
color: Colors.blue,
decay: function _decay() { size = Sizes.medium },
embiggen: function _embiggen() { size = Sizes.xlarge },
normal: function _normal() { size = Sizes.normal },
load: function _load( dbObject ) {
size = dbObject.size
color = dbObject.color
}
}
Now, we could clone this type elsewhere, yes? Sure, we would need to use var myType = Object.Create(MyType), but then we're done, yes? Now we can just myType.size and that is the size of the thing. Or we could read the color, or change it, etc. We haven't created a constructor or anything, right?
If you said there's no constructor there, you're wrong. Let me show you where the constructor is:
// The following var definition is the constructor
var MyType = {
size: Sizes.large,
color: Colors.blue,
decay: function _decay() { size = Sizes.medium },
embiggen: function _embiggen() { size = Sizes.xlarge },
normal: function _normal() { size = Sizes.normal },
load: function _load( dbObject ) {
size = dbObject.size
color = dbObject.color
}
}
Because we've already gone and created all the things we wanted and we've already defined everything. That's all a constructor does. So even if we only clone/use static things (which is what I see the above snippets as doing) we've still had a constructor. Just a static constructor. By defining a type, we have defined a constructor. The alternative is this model of object construction:
var MyType = {}
MyType.size = Sizes.large
But eventually you're going to want to use Object.Create(MyType) and when you do, you will have used a static object to create the target object. And then it becomes the same as the previous example.
The short answer to your question "Do we need factories/constructors in prototypical OO?" is no. Factories/Constructors serve 1 purpose only: initialize the newly created object (an instance) to a specific state.
That being said, it is often uses because some objects need initialization code of some sort.
Let's use the component-based entity code you provided. A typical entity is simply a collection of components and few properties:
var BaseEntity = Object.create({},
{
/* Collection of all the Entity's components */
components:
{
value: {}
}
/* Unique identifier for the entity instance */
, id:
{
value: new Date().getTime()
, configurable: false
, enumerable: true
, writable: false
}
/* Use for debugging */
, createdTime:
{
value: new Date()
, configurable: false
, enumerable: true
, writable: false
}
, removeComponent:
{
value: function() { /* code left out for brevity */ }
, enumerable: true
, writable: false
}
, addComponent:
{
value: function() { /* code left out for brevity */ }
, enumerable: true
, writable: false
}
});
Now the following code will create new entities based on the 'BaseEntity'
function CreateEntity()
{
var obj = Object.create(BaseEntity);
//Output the resulting object's information for debugging
console.log("[" + obj.id + "] " + obj.createdTime + "\n");
return obj;
}
Seems straight forward enough, until you go to reference the properties:
setTimeout(CreateEntity, 1000);
setTimeout(CreateEntity, 2000);
setTimeout(CreateEntity, 3000);
outputs:
[1309449384033] Thu Jun 30 2011 11:56:24 GMT-0400 (EDT)
[1309449384033] Thu Jun 30 2011 11:56:24 GMT-0400 (EDT)
[1309449384033] Thu Jun 30 2011 11:56:24 GMT-0400 (EDT)
So why is this? The answer is simple: because of prototype based inheritance. When we created the objects, there wasn't any code to set the properties id and createdTime on the actual instance, as is normally done in constructors/factories. As a result, when the property is accessed, it pulls from the prototype chain, which ends up being a single value for all entities.
The argument to this is that the Object.create() should be passed the second parameter to set this values. My response would simply be: Isn't that basically the same as calling a constructor or using a factory? It's just another way of setting an object's state.
Now with your implementation where you treat (and rightfully so) all prototypes as a collection of static methods and properties, you do initialize the object by assigning the values of the properties to the data from a data source. It may not be using new or some type of factory, but it is initialization code.
To summarize:
In JavaScript prototype OOP
- new is not needed
- Factories are not needed
- Initialization code is usually needed, which is normally done through new, factories, or some other implementation that you don't want to admit is initializing an object
I recently found out that Javascript function can have classes, so I was wondering if OOP is also possible through javascript. Is It? If yes, Could you please point out some tutorials or site, where I can start with?
OOP is definitely possible. While Javascript doesn't have "classes" like most OO languages do, what it does have is called "prototypes". Basically, objects are defined in terms of other objects rather than classes. (Objects can also emulate classes to some degree, for those who can't wrap their minds around prototypal inheritance.)
One could argue JS's OO capabilities exceed those of most languages, considering objects play an even more essential role than in languages with classes.
OOP is central to Javascript, but it's not classical OOP. Javascript uses prototypes, not classes.
Douglas Crockford is a Javascript genius, so his Prototypal Inheritance in Javascript is a nice starting point. A Google search for "Javascript OOP" likely will turn up some neat articles to peruse, as well — I like the article by Mike Koss.
Javascript is an intrinsically OOP language. Like others have said, it is classless, but you have a choice of how you want to create objects.
You can create objects that make use of different types of inheritance.
A pseudo-classical inheritance. Here you build constructor functions and use new to create classes. This will look most like the typical class based OOP.
Prototypal inheritance. - This is what many of the other answer referred to.
Functional inheritance. - In this mode you make use of closures, anonymous functions, and strategic returns to create truly private and protected variables.
There's a fair amount of cross over among these types. Suffice it to say that Javascript is a very flexible and powerful language for OOP.
I'm just learning about OOP in JS as well. Here is an example of functional inheritance I put together:
jsFiddle
// Object constructor
var parent = function (initial) {
var that, privateNumber, hiddenVar;
that = {};
// Public variables
that.share = initial - 32;
// Public methods
that.getNumber = function () {
return privateNumber;
};
// Private properties
privateNumber = initial;
hiddenVar = "haha can't get me";
return that;
};
// Second object constructor that inherits from parent
var child = function (initial) {
var that, privateName;
// Inherit from parent
that = parent(initial);
// Public methods
that.getName = function () {
return privateName;
};
// Private poroperties
privateName = "Ludwig the " + initial + "th";
return that;
};
// Create objects
var newPar1 = parent(42);
var newPar2 = parent(10);
var newChild1 = child(0);
var newChild2 = child(100);
// Output on the jsFiddle page refed above: http://jsfiddle.net/ghMA6/
http://msdn.microsoft.com/en-us/magazine/cc163419.aspx
http://www.dustindiaz.com/namespace-your-javascript/
http://vimeo.com/9998565
frameworks for oop js
http://jsclass.jcoglan.com/
http://www.prototypejs.org/
Pluralsight - JavaScript for C# Developers - Shawn Wildermuth - 2h 5m
JavaScript Basics
JavaScript Functions
Object-Oriented JavaScript
Practical Application
and
Object-Oriented JavaScript: Create scalable, reusable high-quality JavaScript applications and libraries - 356 pages -2008 -packed publishing
Yes. It is possible. I have ever using the Script# to build javascript application, It allow you writing C# code, and translate to JavaScript.
it is an good experience, especially for large project, it will force your thinking in the OOP way to order your code.
The tool can be found at: (it is open source but write by an Microsoft employee)
http://scriptsharp.com
If you are not familiar with C# you can also find the similar tool for writing javascript in Java.
And if you don't want to using those too, you can investigate how it convert the code to understand how it implement the OOP feature.
Here is an example of accomplishing an OO structure in javascript that is utilizing a library(not required, recommended)
//Create and define Global NameSpace Object
( function(GlobalObject, $, undefined)
{
GlobalObject.PublicMethod = function()
{
///<summary></summary>
}
GlobalObject.Functionality = {}
}) (GlobalObject = GlobalObject || {}, jQuery);
//New object for specific functionality
( function(Events, $, undefined)
{
//Member Variables
var Variable; // (Used for) , (type)
// Initialize
Events.Init = function()
{
///<summary></summary>
}
// public method
Events.PublicMethod = function(oParam)
{
///<summary></summary>
///<param type=""></param>
}
// protected method (typically define in global object, but can be made available from here)
GlobalObject.Functionality.ProtectedMethod = function()
{
///<summary></summary>
}
// internal method (typically define in global object, but can be made available from here)
GlobalObject.InternalMethod = function()
{
///<summary></summary>
}
// private method
var privateMethod = function()
{
///<summary></summary>
}
Events.PublicProperty = "Howdy Universe";
}) (GlobalObject.Functionality.Events = GlobalObject.Funcitonality.Events || {}, jQuery )
// Reusable "class" object
var oMultiInstanceClass = function()
{
// Memeber Variables again
var oMember = null; //
// Public method
this.Init = function(oParam)
{
oMember = oParam;
}
}
The strength to this is that it initializes the Global object automatically, allows you to maintain the integrity of your code, and organizes each piece of functionality into a specific grouping by your definition.
This structure is solid, presenting all of the basic syntactical things you would expect from OOP without the key words.
There are even some ingenious ways to set up interfaces as well. If you choose to go that far, a simple search will give you some good tutorials and tips.
Even setting up intellisense is possible with javascript and visual studio, and then defining each piece and referencing them makes writing javascript cleaner and more manageable.
Using these three methods as needed by your situation helps keep the global namespace clean, keep your code organized and maintains separation of concerns for each object.. if used correctly. Remember, Object Oriented Design is of no use if you don't utilize the logic behind using objects!
I have been trying to learn how to add testing to existing code -- currently reading reading Working Effectively With Legacy Code. I have been trying to apply some of the principles in JavaScript, and now I'm trying to extract an interface.
In searching for creating interfaces in JavaScript, I can't find a lot -- and what I find about inheritance seems like their are several different ways. (Some people create their own base classes to provide helpful methods to make it easier to do inheritance, some use functions, some use prototypes).
What's the right way? Got a simple example for extracting an interface in JavaScript?
There's no definitive right way, because so many people are doing so many different things.. There are many useful patterns.
Crockford suggests that you "go with the grain", or write javascript in a way that corresponds to javascript's prototypal nature.
Of course, he goes on to show that the original model that Netscape suggested is actually broken. He labels it "pseudoclassical", and points out a lot of the misdirection and unnecessary complexity that is involved in following that model.
He wrote the "object" function as a remedy (now known as Object.create() ). It allows for some very powerful prototypal patterns.
It's not always easy to do develop a clean interface when you have to work with legacy javascript, especially not when you're dealing with large systems, usually including multiple libraries, and each implementing a unique style and different inheritance pattern. In general, I'd say that the "right way" to do inheritance is the one which allows you to write a clean interface which behaves well in the context of your legacy code, but also allows you to refactor and eliminate old dependencies over time.
Considering the differences between the major library patterns, I've found that the most successful route to take in my own work is to keep my interfaces independent of the library interfaces entirely. I'll use a library or module if it's helpful, but won't be bound to it. This has allowed me to refactor a lot of code, phase out some libraries, and use libraries as scaffolding which can be optimized later.
Along these lines, I've written interfaces that were inspired by Crockford's parasitic inheritance pattern. It's really a win for simplicity.
On the other side of the coin, I'm sure you could argue for picking a library, enforcing it across your team, and conforming to both its inheritance patterns and its interface conventions.
There are no class in javascript, only objects.
But if you insist on emulating the class based object-oriented model you can use this:
function ChildClass() {
ParentClass.call(this);
// Write the rest of your constructor function after this point.
};
ChildClass.prototype = jQuery.extend({}, ParentClass.prototype, ChildClass.prototype);
jQuery.extend is a 'shallow copy' function from the jQuery library. You can replace it with any other object copying/cloning function.
You are looking at two different things.
First you have interfaces. The most accepted way of implementing this is though Duck Typing ("if it looks like a duck and quacks like a duck then it is a duck"). This means that if an object implements a set of methods of the interface then it is that interface. You implement this by having an array of method names that define an interface. Then to check if an object implements that interfece you see if it implements those methods. Here is a code example I whipped up:
function Implements(obj, inter)
{
var len = inter.length, i = 0;
for (; i < len; ++i)
{
if (!obj[inter[i]])
return false;
}
return true;
}
var IUser = ["LoadUser", "SaveUser"];
var user = {
LoadUser : function()
{
alert("Load");
},
SaveUser : function()
{
alert("Save");
}
};
var notUser = {
LoadUser : function()
{
alert("Load");
}
};
alert(Implements(user, IUser));
alert(Implements(notUser, IUser));
Now you have inheritance. JS has no inheritance built in; so you have to implement it manually. This is just a matter of "copying" the properties of one object to another. Here is another code sample (not perfect but it demonstrates the point):
function InheritObject(base, obj)
{
for (name in base)
{
if (!obj[name])
obj[name] = base[name];
}
}
var Base = {
BaseFunc : function() { alert("BaseFunc from base"); },
InheritFunc : function() { alert("InheritFunc from base"); }
}
var Inherit = {
InheritFunc : function() { alert("InheritFunc from inherit"); },
AnotherFunc : function() { alert("AnotherFunc from inherit"); }
}
InheritObject(Base, Inherit);
Inherit.InheritFunc();
Inherit.BaseFunc();
Inherit.AnotherFunc();
Base.BaseFunc();
Base.InheritFunc();
You probably want to look at http://www.mootools.net. It has my favorite implementation of Classes. You also definitely want to check out "Pro Javascript Design Patterns"
http://www.amazon.com/JavaScript-Design-Patterns-Recipes-Problem-Solution/dp/159059908X
This book goes into good detail about how to emulate OOP in javascript.
Also check out Dean Edwards' Base.js. You can have a look at it here, the blog post is self-explanatory.
Prototype offers its own take on inheritance, from http://www.prototypejs.org/api/class/create:
var Animal = Class.create({
initialize: function(name, sound) {
this.name = name;
this.sound = sound;
},
speak: function() {
alert(this.name + " says: " + this.sound + "!");
}
});
// subclassing Animal
var Snake = Class.create(Animal, {
initialize: function($super, name) {
$super(name, 'hissssssssss');
}
});