Nope. The two strategies are somewhat incompatible. Which is why private properties are usually public, but prefixed with an underscore, when using prototypes.
Namespace.Apple = function(p_color){ this._color = p_color; }; Namespace.Apple.prototype.eat = function(){ console.log("I'm eating a " + this._color + " apple !") };
This tells JS developers using this code that they should not mess with the _color property, as it's for internal use.
That said, you have other big problems here...
Namespace.Apple = function(p_color){ var AppleInstance = this; //clarity.. AppleInstance.color = p_color; return { /************** / Public method /**************/ //Here, we only return an access to the Method Eat Eat : NameSpace.Apple.prototype.Eat } }
This doesn't do what you think. When a constructor returns an object, the instance created with new is discarded. So you will not end up with an instance of Apple. Instead you get a plain object that looks like this:
{ Eat: Namespace.Apple.prototype.Eat }
So the object you assigned a color to? It's gone.
This method is not private.
//Will NOT be private Namespace.Apple.prototype.PrivateMethod = function(){ var AppleInstance = this; //clarity.. console.log("This is a private method"); }
Everything on the prototype is public. Everything.
And a note about conventions.
var AppleInstance = this; //clarity..
I don't think is clear at all. this is used in instance methods to mean this instance. Any obfuscation of that hurts readability.
And please, save capital letter variable names for constructors (Eat bad!, Apple good!, AppleInstance bad!), also for readability. As calling a constructor without the new keyword can have some bizarre consequences.
To avoid this, and still have private variables and methods, you don't use the prototype at all. You set up all variables and methods as functions from within the constructor, building the instance piece by piece.
var Namespace = {}; Namespace.Apple = function(color){ // color form the arguments is a local variable, bound to the methods created below var somePrivateVar = 'privateData!'; // private instance variable // public method, with access to private instance vars this.eat = function(){ console.log("I'm eating a " + color + " apple!"); }; // public method, which calls private method this.doSomethingPrivate = function() { console.log('calling private method for you'); privateMethod() } // private method var privateMethod = function(){ console.log("This is a private method for a " + color + " apple!"); }; // instance is auto-returned, no return needed. } var apple = new Namespace.Apple('red'); apple.eat(); // I'm eating a red apple! apple.doSomethingPrivate(); // calling private method for you // This is a private method for a red apple! apple.privateMethod() // <exception> apple.privateMethod is undefined
Only thing to note about this approach is that it can be much slower, and use more memory, than when you use prototypes. Functions on the prototype are shared between all instances, so you only need to create and store a single function for a method, and every instance will execute that function object.
With the above approach every single instance creates and stores a new copy of each method function. And each function has privileged access to the scope of that instances constructor, allowing you private variables and methods. If you only plan on having a few instances, this difference may not make a lot of difference. But if you plan on have a very large number of instances, the performance difference may become very important.
new function(){}- WTH?NameSpace.Apple.prototype.PrivateMethod