Доступ к закрытым переменным, определенным с помощью 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++), а не для внешнего использования потребителями или пользователями объекта.

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

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

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

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