2015-04-24 1 views
1

Я разрабатываю JavaScript SDK, который предназначен для упрощения работы с конкретным, сложным REST API путем абстрагирования некоторой сложности.Использование свойств accessor в JavaScript SDK-дизайне?

Некоторые из объектов, которые предоставит SDK, должны будут раскрывать свойства, которые можно установить и извлечь.

Я использовал и изучил другие SDK JavaScript, и явные функции getter/setter, по-видимому, используются почти повсеместно в пользу свойств accessor.

Некоторые примеры, чтобы проиллюстрировать, что я имею в виду:

Явные функции геттер/сеттер

function Widget() { 
    return { 
     setName: function(name) { 
      //Sanitization, error checking, etc, could go here. 
      this.name = name; 
     }, 
     getName: function() { 
      return this.name; 
     } 
    } 
} 

var widget = new Widget(); 
widget.setName("Testing"); 
w.getName(); //"Testing" 

Accessor недвижимость

function Widget(name) { 
    //Internal property that is modified by the accessor property. 
    this._name = name; 
} 
Object.defineProperty(Widget.prototype, "name", { 
    get: function() { 
     return this._name; 
    }, 
    set: function(value) { 
     //Sanitization, error checking, etc, could go here. 
     this._name = value; 
    } 
}); 

var widget = new Widget(); 
widget.name = "Testing"; 
widget.name; //"Testing" 

Для меня самое важное различие здесь ISN фактическая реализация, но как объекты манипулируют конечный пользователь; через вызовы функций в первом случае и через прямое назначение во втором случае.

Обе реализации позволяют проверять/дезинфицировать ошибки при установке значения и мутацию внутреннего значения «на лету» при ее изъятии.

Итак, почему большинство SDK, похоже, избегают использования свойств доступа? Это плохая идея использовать их? Если нет, то когда целесообразно использовать их вместо явных функций getter/setter? Вот несколько причин, я думал:

  • Отсутствие поддержки в старых браузерах
  • Возможная путаница разработчик при проверке объектов в среде разработки/веб-браузер
  • Возможная путаница разработчик, если они не ожидают прямое назначение иметь побочные эффекты

Если язык предоставляет явный механизм для этой цели (accessors), почему он более популярен для «изобретать колесо» с явными функциями getter/setter?

+1

Я думаю, что это мнение основано. Но я предпочитаю первый случай, потому что это * просто *. Acessors делает ваш код более крупным и запутанным (как вы сказали), чтобы сделать то же самое, что и первый случай, который вы предложили. – DontVoteMeDown

+1

Существует также более простая возможность не использовать устройства доступа, когда это не требуется. Не делайте код JS похожим на Java. –

+0

@dystroy Стоит упомянуть, что также будет Java SDK, который служит аналогичной цели, поэтому в этом случае может быть какая-то польза от двух, имеющих аналогичные API. Я понимаю, что эта идея должна быть сбалансирована с тем, что подходит для обоих языков. – segfault

ответ

0

Одна из причин заключается в том, что некоторые люди по-прежнему используют IE8 и ниже, которые не имеют полезной поддержки Object.defineProperty. Для людей, пытающихся создать общедоступный SDK, который можно использовать в таких средах, это нетривиальная проблема для работы. У получателей и сеттеров нет этой проблемы.