Во-первых, я не вижу точки в попытке защитить себя от вызывающей стороны, сознательно пытающейся вызвать катастрофический отказ. Они могли легко сделать это путем попытки получить доступ через недопустимый указатель сами. Существует много других путей - они могли просто перезаписать Вашу память или стек. Если необходимо защитить от этого вида вещи затем, необходимо работать в отдельном процессе с помощью сокетов или некоторого другого IPC для коммуникации.
Мы пишем довольно много программного обеспечения, которое позволяет партнерам/клиентам/пользователям расширять функциональность. Неизбежно о любой ошибке сообщают нам сначала, таким образом, полезно смочь легко показать, что проблема находится в сменном коде. Дополнительно существуют проблемы безопасности, и некоторым пользователям больше доверяют, чем другие.
Мы используем много различных методов в зависимости от требований производительности/пропускной способности и защищенности. От самого предпочтительного:
отдельные процессы с помощью сокетов (часто передающие данные как текст).
отдельные процессы с помощью общей памяти (если большие объемы данных для передачи).
тот же процесс разделяют потоки через очередь сообщений (если частые короткие сообщения).
тот же процесс разделяют потоки все переданные данные, выделенные от пула памяти.
тот же процесс через прямой вызов процедуры - все переданные данные выделяются от пула памяти.
Мы пытаемся никогда не обратиться к тому, что Вы пытаетесь сделать при контакте с внешним программным обеспечением - особенно, когда нам дают плагины/библиотеку как двоичный а не исходный код.
Использование пула памяти довольно легко при большинстве обстоятельств и не должно быть неэффективным. При выделении данных во-первых затем, это тривиально для проверки указателей по значениям, которые Вы выделили. Вы могли также сохранить выделенную длину и добавить "волшебные" значения прежде и после данных для проверки на допустимый тип данных и потери данных.
Ваши первые два примера полностью эквивалентны:
MyClass.prototype = new Object(); // empty object
MyClass.prototype = {}; // empty object
Ваш третий пример недействителен, поскольку вы назначаете MyClass.prototype
ссылку на Конструктор объекта , и это функция, а не новый объект.
Я лично предпочитаю второй, синтаксис литерала или инициализатора :
MyClass.prototype = {prop1: 'value', prop2: 'value2'};
//...
MyClass.prototype.foo = 'bar';
MyClass.prototype.method1: function () {/**/};
Изменить: В ответ на ваш комментарий пустой литерал объекта {}
по существу эквивалентен new Object ()
из-за этого:
Рабочий ObjectLiteral: {} оценивается следующим образом:
- Создайте новый объект, как если бы с помощью выражения new Object ().
- Возврат результата (1).
Для получения дополнительных сведений см. раздел 11.1.5 (Инициализатор объекта) Спецификация языка ECMAScript (pdf).
Изменить: Третий пример не выдаст никаких ошибок, но он совсем не годится, например, вы можете легко затереть функцию конструктора объекта, если расширите ее позже MyClass.prototype:
MyClass.prototype = Object;
MyClass.prototype.foo = 'bar';
Object.foo === MyClass.prototype.foo; // true
Зависит от объекта
. Если это функция, вы хотите использовать метод new Object ()
. Если это «виртуальный класс» (определенный с помощью Object = {someProperty: someValue}
), тогда вы используете второй метод.
Еще несколько указателей на этой странице наследования прототипов в JavaScript
MyClass.prototype.method1: function () {/ ** /};
Исправление к приведенному выше: оно должно быть
MyClass.prototype.method1 = function () {/**/};
(обратите внимание на знак равенства после 'method1').
Двоеточие используется только тогда, когда само определение метода находится внутри определения объекта, например:
var myObject = {myVar1: 10, myMethod1: function() { /* */};