Доступ к закрытым переменным, определенным с помощью WeakMap внутри производного класса

Question

Я использую общий шаблон WeakMaps для эмуляции частных переменных внутри классов es6, но я не могу найти способ иметь «защищенные» переменные, то есть переменные, которые являются частными и к которым можно получить доступ через производные классы, например:

var Window = (function() {
    const _private = new WeakMap();
    const internal = (key) => {
        // Initialize if not created
        if (!_private.has(key)) {
            _private.set(key, {});
        }
        // Return private properties object
        return _private.get(key);
    };


    class Window {

        constructor() { 
            // creates a private property
            internal(this).someProperty = "value";
        }
    }

    return Window;
})();

Если я создаю подкласс, используя тот же шаблон, как я могу получить доступ к someProperty в подклассе, не определяя метод получения в базовом классе (таким образом, полностью разрушая всю цель наличия слабых карт для частногосвойства)?

Если не существует элегантного решения с использованием этого шаблона, какой вариант действий будет наилучшим?Я создаю веб-приложение, которое может иметь различные «многослойные окна», отображающие различные продукты, загруженные из другого скрипта, который делает несколько запросов к конечным точкам .php для сбора этой информации.

Сама библиотека не предназначена для того, чтобы быть публичной библиотекой, к которой каждый мог бы получить доступ, в большинстве других товарищей по команде, возможно, придется редактировать ее части, но они все равно будут соблюдать определенные шаблоны / соглашения

с точки зрения безопасности большинство запросов к другим API будет выполняться из отдельного сценария, обрабатывающего проверку полезной нагрузки, так что я действительно пытаюсь сделать это сделать многократно используемые Window классы, которые могут использовать своего рода "защищенный"переменные в производных классах, поскольку это определенно поможет мне в процессе создания этого конкретного типа GUI

Answer 1

Сама библиотека не предназначена для того, чтобы быть публичной библиотекой, к которой каждый может получить доступ, в большинстве других товарищей по команде, возможно, придется редактировать ее части, но они все равно будут соблюдать определенные шаблоны / соглашения

Из описания того, что вы действительно пытаетесь сделать и добавили в свой вопрос, похоже, что это не проблема "безопасности" как таковая, а скорее вы ищете лучшее программированиереализация / соглашение для вашей локальной команды, которая будет использовать этот интерфейс, чтобы другим разработчикам было понятно, какое состояние «защищено» и используется только внутри реализации, а не от внешних потребителей объектов.

В этом случае я бы просто использовал соглашение о подчеркивании, когда имя свойства объекта, начинающееся с подчеркивания, как в this._someProperty, предназначено только для внутреннего использования в методах самого объекта (аналогично «защищенному»)."члены в C ++), а не для внешнего использования потребителями или пользователями объектаct.

Затем сообщите об этом в документе для реализации и устно с командой, с которой вы работаете, чтобы убедиться, что все не только понимают это соглашение в коде, который вы пишете, но и чтобы они также могли последовательно использовать одно и то жесоглашение в их коде.

Так как это не кажется, у вас есть реальная потребность в безопасности здесь, причины пойти с этим типом подчеркивания "соглашение" вместо более вовлеченных решений, которые обеспечивают некоторую реальную защитуданные от других разработчиков (например, что вы пытались сделать):

1. Реализация проще
2. Нет снижения производительности
3. Не мешает модульности и размещенияпроизводные классы в отдельных файлах
4. Бесконечно расширяемые на столько свойств, сколько классов
5. Легче обучить команду, с которой вы работаете,

Однажды один из старших разработчиков поделился со мной словами: «Мой код должен быть таким простымнасколько это возможно для достижения целей (правильность, стабильность, тестируемость, ремонтопригодность, расширяемость и повторное использование) ».Это помогло мне стремиться к простоте в реализации и избежать чрезмерного проектирования за пределы того, что действительно необходимо.