He estado trabajando con la biblioteca prototipo durante algún tiempo y ocasionalmente me encuentro deseando tener múltiples niveles de acceso (público, privado y protegido). Lo más cerca que he llegado hasta ahora es lo siguiente:

SampleBase = Class.create({
    /* virtual public constructor */
    initialize: function(arg1, arg2)
    {
        // private variables
        var privateVar1, privateVar2;

        // private methods
        var privateMethod1 = function() { }
        function privateMethod2() { }

        // public (non virtual) methods
        this.publicNonVirtual1 = function() { return privateVar1; }
        this.publicNonVirtual2 = function() { return privateVar2; }
    },
    // public methods (that cannot access privates)
    publicVirtual1: function() { /* Cannot access privates here. */ },
    publicVirtual2: function() { /* Cannot access privates here. */ }
});

Esto es menos ideal por varias razones:

No hay nivel protegidoPuedo tener miembros públicos que pueden acceder a miembros privados o miembros públicos que pueden ser anulados pero no miembros públicos que pueden acceder a miembros privados y ser anulados.Mis métodos públicos que pueden ser anulados no son prototipos.

He hecho algunas búsquedas pero no he encontrado nada que sugiera que puedo hacerlo mejor sin alterar cómo funciona el prototipo. Aquí hay algunos de los enlaces más interesantes:

Uso de Class.create de Prototype para definir propiedades y métodos privados / protegidosMétodos privados de JavaScriptMiembros privados en JavaScriptDe nuevo con el patrón del módulo - revelar algo al mundo

He visto que sugirió que puedes proporcionar accesores para mis métodos virtuales públicos para usar haciendo algo como esto:

Message = Class.create({
    initialize: function(message)
    {
        var _message = message;
        this.getMessage = function() { return _message; }
        this.setMessage = function(value) { _message = value; }
    },
    printMessage: function() { console.log(this.getMessage()); },
    appendToMessage: function(value) { this.setMessage(this.getMessage() + value); }
});

Esto claramente no funcionará según lo previsto. El objetivo es permitir solo imprimir y adjuntar al mensaje desde fuera del objeto. El configurador provisto para hacer que la función pública virtual funcione también permite el control total del mensaje. Se podría cambiar para hacer que el método virtual sea un poco más que un shell de la siguiente manera:

Message = Class.create({
    initialize: function(message)
    {
        var _message = message;
        this._printMessage = function() { console.log(_message); }
        this._appendToMessage = function(value) { _message += value; }
    },
    printMessage: function() {this._printMessage(); },
    appendToMessage: function(value) { this._appendToMessage(value); }
});

Esta nueva versión limita el acceso público para esta clase pero es algo redundante. Por no mencionar si appendToMessage se reemplaza en una subclase, un tercero todavía puede llamar a _appendToMessage para acceder al método original que no es bueno.

Tengo unmuy sucio idea que me acercará pero es una lata de gusanos que preferiría no abrir. Puedo publicarlo más tarde, pero mientras tanto, ¿alguien tiene sugerencias para fusionar los dos tipos de métodos públicos en un tipo útil o sobre cómo implementar miembros protegidos?

EDIT: Sospecho la falta de retroalimentación (aparte deBobince(No me moleste en comentar) significa que estoy en lo cierto en que no se puede seguir, pero creo que aclararé un poco por si acaso. No creo que sea posible acercarse a la protección de otros idiomas. Estoy más interesado en saber dónde están los límites y qué tan precisa es mi comprensión de los principios involucrados. Sin embargo, creo que sería interesante, si no útil, si pudiéramos conseguir que funcionen los distintos niveles de protección hasta el punto de que los miembros no públicos no aparezcan en un bucle for ... in (o en Prototypes Object.keys, que se usa para ... en) incluso si las personas que saben lo que están haciendo pueden romper las reglas haciendo cosas como manipular mis prototipos. Después de todo, es comoBobince dice "no tienen a nadie a quien culpar sino a ellos mismos"

Ahora para comentar sobre un tema planteado porBobince:

Incluso si hiciera variables realmente privadas / protegidas, aún no obtendría la encapsulación completa que requeriría un límite de seguridad efectivo. La capacidad de JavaScript para jugar con los prototipos de los tipos incorporados que usarán sus métodos le da a un atacante la capacidad de sabotear los métodos.

Esta es una limitación que entiendo y que probablemente debería haber mencionado anteriormente. Sin embargo, no estoy viendo esto desde el punto de vista de proteger mi código de alguien que intenta "hackearlo". Sin embargo, tengo algunas cosas que vale la pena mencionar (o que necesito corregir si me equivoco):

Solo mis miembros públicos son vulnerables de esta manera.Si mis métodos virtuales públicos están "comprometidos" de esta manera, entonces los métodos "comprometidos" todavía no tendrán acceso a los miembros privados.Si mis miembros públicos (no virtuales) están "comprometidos" de esta manera, entonces, a diferencia de la versión original del método, la versión "comprometida" no tendrá acceso a los miembros privados.Por lo que sé, la única forma de obtener acceso a los miembros privados mediante métodos definidos fuera del método de inicialización es aprovechar un error en la forma en que algunos navegadores manejan las llamadas de evaluación.