Ответ 1
Это будет вопрос, основанный на мнении. Но я заберу $.02.
tl/dr: не слишком беспокоитесь об этом. JavaScript довольно гибкий и может поддерживать множество способов делать что-то. Хорошо организованная организация хорошо организована. Вы, наверное, хорошо.
Более подробный ответ:
1) Используйте классы, где они имеют смысл: где проблемная область подходит для моделирования иерархии классов/классов. Проблемная область, в которой у вас есть множество объектов формы, которые имеют общие методы, унаследованные от базового класса и других полиморфных методов... ну, это (буквально) пример учебника случая, когда иерархия классов очевидна и, вероятно, полезна, и код, ориентированный на класс, будет иметь смысл там, и в этом нет ничего плохого.
2) Вам даже не нужно использовать шаблоны закрытия/модуля/что угодно. Когда вы пишете классы, большую часть времени нет ничего плохого в использовании встроенной функциональности класса, доступной в JavaScript, - просто определите конструктор, а затем определите объект-прототип для конструктора и поместите на него свои методы. Когда вы хотите наследовать от этого класса, присвойте объекту прототипа подкласса экземпляру класса, из которого вы получаете.
(Например:
Drawing.Node = (function() {
var Node = function (context,position) {
this.context = context;
this.position = position;
}
Node.prototype = {
draw: function() { throw Exception.MethodNotOverridden; },
getContext: function() { return this.context; },
getPosition: function() { return this.position; },
setPosition: function(newPosition) { this.position = newPosition; }
};
return Node;
})();
Shape.Circle = (function () {
var Circle = // Circle constructor function
Circle.prototype = new Draw.Node;
Circle.prototype.overriddenmethod1 = function () {
}
Circle.prototype.overriddenmethod2 = function () {
}
return Circle;
})()
)
Как насчет частных участников/методов? Это мнение, но большую часть времени я считаю, что конфиденциальность как механизм, исполняемый во время исполнения, чрезмерно используется и даже злоупотребляется. Разработчики могут многое сделать; они, вероятно, предпочли бы не обращать внимания на внутренности любой данной абстракции, если только она не пропустит что-то вредное. Если ваши классы не вызывают проблем, бросают/возвращают полезные ошибки, предоставляют действительно полезные методы и достаточно хорошо документированы, вам не понадобится какой-либо механизм обеспечения соблюдения конфиденциальности, потому что каждый будет так доволен работой, которую ваши классы сохраняют их они никогда не заглянут внутрь. Если ваши классы не соответствуют этому стандарту, ну, отсутствие механизма обеспечения соблюдения конфиденциальности не является вашей реальной проблемой.
Есть исключение из этого, и когда у вас есть JavaScript-код из разных (и часто ненадежных) источников, смешивающих внутри страницы/приложения. В этот момент, по соображениям безопасности, вам иногда приходится тщательно думать об изоляции некоторых важных функций/методов в рамках данной области, к которой имеет доступ только ваш код и ваш код.
Edit/Добавление
В ответ на вопрос о том, почему у меня есть эти сразу оцененные функции, рассмотрите этот альтернативный способ записи определения Drawing.Node:
Drawing.Node = function (context,position) {
this.context = context;
this.position = position;
}
Drawing.Node.prototype = {
draw: function() { throw Exception.MethodNotOverridden; },
getContext: function() { return this.context; },
getPosition: function() { return this.position; },
setPosition: function(newPosition) { this.position = newPosition; }
};
Это делает то же самое, что и код выше. Это также, ИМХО, вполне приемлемо и, возможно, немного яснее и менее сложно.
С другой стороны, я нахожу, что помещение всего, что входит в область сразу исполняемой анонимной функции, дает мне как минимум два преимущества:
-
Если я решаю, что мне нужно определить какие-либо частные методы или выполнить какую-либо работу по настройке, относящуюся только к определенному определению класса, она дает мне приятную личную область для работы.
-
Если я решил, что мне нужно перемещать расположение
Nodeв иерархию объектов namespacing в другом месте, это удобно, если все, связанное с его определением, связано в одном удобном месте.
Иногда эти преимущества малы. Иногда они немного более убедительны. YMMV.