Как улучшить структуру моего JavaScript, чтобы лучше использовать ООП

Question

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

На этот раз я работаю над проектом, который более или менее создает решение для управления файлами в браузере.

Мой первый кусочек кода - позволить пользователям выбирать один и несколько файлов с помощью клавиатурных команд (стрелки и Shift) и мыши (щелчок и Shift)

Я использовал шаблон проектирования, который я изучил, наблюдая за кодом коллег в другом проекте, но меня не устраивает объем кода, необходимый для вызова функций и глобальных (для объекта) переменных, например:

SW.selection.addItemsToSelection($(this))

или

SW.selection.vars.$selectedItems

Полный код вы можете увидеть на JSFiddle здесь

Мои вопросы:

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

и

(b) У меня есть только смутное понимание ООП, поскольку я изо всех сил пытаюсь применить его к реальным проблемам - как лучше всего структурировать этот код, следуя методологии ООП, учитывая его фрагмент того, что будет большим JS-приложением.

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

Answer 1

Не думаю, что с вашими примерами вызовов что-то не так, но я упомяну еще одно преимущество шаблона синглтона: определение локальных имен.Я приведу пример из реальной жизни: если я работаю с картами Google и устаю ссылаться на google.maps.LatLng везде, я могу сократить его в рамках моего модуля.

MyApp.MyModule = (function(MM, g) {

  MM.doSomething = function() {
    // here's a function that makes extensive use of google.maps
    // but I can use "g"
    var ll = new g.LatLng(-1, -1);
    var map = new g.Map();
  }

  return MM;
})(MyApp.MyModule || {}, google.maps);

Обратите внимание, что я использую тот же трюк, чтобы сократить имя моего собственного модуля.Другие модули будут вызывать MyApp.MyModule.doSomething () , если они обращаются к моему методу через глобальную область видимости, но я могу ссылаться на свои собственные переменные и методы как MM.doSomething () .

Answer 2

Вы можете заменить SW.selection на this в большинстве мест, если вы находитесь в области видимости объекта.

Шаблон проектирования выглядит как «синглтон» (или его эквивалент в JavaScript: Object), поэтому нет необходимости в таких причудливых вещах ООП, как наследование и т. Д. Одна вещь, которую вы могли бы рассмотреть, это возможность иметь частные переменные в вашем синглтоне. :

SW.selection = (function() {
    var private = 'I’m private';
    return {
        public: function() {
            return private;
        }
    }
}());

SW.selection.public(); // returns 'I’m private', 
                       // but the private variable is not accessible from here

Таким образом, вы можете хранить переменные в закрытой области видимости, поэтому вам не нужно каждый раз получать к ним доступ через весь синглтон, используя SW.selection.vars.myvar и т. Д.