Инициализировать набор в объекте?
Вызов .focus() с помощью jQuery приведет к немедленному запуску соответствующих обработчиков событий, и, поскольку вы делаете это из обработчика «focusin», вы получаете бесконечную рекурсию. Я всегда решал это, выполняя операцию .focus() за тайм-аут:
if (a.val().length == 1) {
setTimeout(function() {
a.next(b).focus();
}, 1);
}
Даже без проблемы рекурсии вы должны позволить текущей работе «фокуса» завершить работу, прежде чем перенаправить фокус на другой элемент .
10 ответов
Можно также использовать "Ленивый инициализатор" шаблон, где набор не инициализируется, до (и если) кто-то не получает доступ к методу считывания свойства для него... Это избегает издержек создания его в тех случаях, где родительский объект инстанцируют для некоторой другой цели, которая не требует набора...
public class Division
{
private int divId;
public int DivisionId { get; set; }
private Collection<Employee> emps;
public Collection<Employee> Employees
{ get {return emps?? (emps = new Collection<Employee>(DivisionId));}}
}
Править: Этот шаблон реализации, в целом, не ориентирован на многопотоковое исполнение... emps, мог быть считан двумя различными потоками как пустой указатель, прежде чем первый поток закончит изменять его. В этом случае это, вероятно, не имеет значения, поскольку DivisionId неизменен и хотя оба потока получили бы различные наборы, они оба будут допустимы. Whne второй поток fihishes, поэтому, emps был бы допустимым набором. 'Вероятно', то, потому что для первого потока могло бы быть возможно начать использовать emps, прежде чем второй поток сбросит его. Это не было бы ориентировано на многопотоковое исполнение. Другая немного более сложная реализация от Jon SKeet ориентирована на многопотоковое исполнение (см. Эту статью об Одиночных элементах для его примера/обсуждения о том, как зафиксировать это.
Это зависит от контракта, который Вы имеете между своим API и пользователем.
Лично, мне нравится контракт, который заставляет Объект управлять своими наборами, т.е. инстанцированием их на создании, и гарантируя, что они не могут быть установлены в NULL через метод set - возможно путем обеспечения методов для управления набором вместо того, чтобы установить сам набор.
т.е. addFoo (Нечто toAdd) вместо setFooSet (Набор набора), и так далее.
Но Вам решать.
Я обычно буду создавать набор, затем обеспечивают, методы для добавления / удаляют объекты из внутреннего набора вместо того, чтобы делать потребителя беспокойства класса о проверке пустой указатель. Это также дает Вам способность управлять лучше, что происходит с набором. В конечном счете это зависит от того, для чего это, но скорее всего если Ваш класс имеет набор, это не именно так, что у потребителя класса может быть набор тех объектов. Иначе, почему они использовали бы Ваш класс?
Я создаю пустой набор. Несомненно, этому стоили небольшой памяти, но не достаточно большой, которая будет касаться этого.
В то время как то, что я говорю здесь, не универсально каким-либо образом, я думаю, что наборы главным образом подходят как частные собственности, к которым должны получить доступ открытые методы для самого объекта. Поэтому объект ответственен, чтобы создать и уничтожить их по мере необходимости. Таким образом, не будет возможно установить его в NULL из внешнего кода.
Я предпочитаю создавать набор после инстанцирования, обеспечивать, добавляют/удаляют методы в содержании объекта, и в случае необходимости, предоставляют addAll/removeAll методы для добавления и удаления всех внешних наборов. Я никогда не позволяю объекту коллекции быть полученным доступ для, получают или устанавливают вызывающей стороной - я могу, однако, обеспечить метод считывания, который возвращает копию (возможный неизменный) набора.
У меня также были реализации копии на записи, которые обеспечивают неизменно перенесенное представление, так как любая мутация создаст новый базовый набор.
IMO, это - то, где IEnumerable входит приятно.
Лично, мне нравится, когда мои свойства 'набора' инициализируются к пустым спискам.
Я попробовал оба пути, и я обычно счастлив, когда я нахожу, что у меня уже есть instanciated он. Кроме того, Вы могли скрыть реализацию от потребителя позади ряда методов, которые могут обработать проверку на Вас.
Если набор является внутренней частью объекта, то объект должен обычно создавать его (и не позволять пользователю устанавливать его на другой экземпляр набора).
Как правило я думаю, что объект должен создать набор и предоставить методы для управления им; добавить/получить/удалить. При следовании этому правилу Вы не должны предоставлять методы для установки набора непосредственно. Если Вы хотите метод как setSomeCollection (Набор someCollection) для удобства, реализация этого метода не должна устанавливать ссылку в объекте, но копировать значения от набора параметра метода до набора в объекте;
public void setSomeCollection(Collection someCollection) {
this.someCollection.clear();
this.someCollection.addAll(someCollection);
}
Необходимо сделать это, таким образом, клиенты API не могут получить доступ к набору, который поддерживает класс. Если они делают, они могут управлять им, не используя объекты Вашего класса и нарушить ограничения, которые гарантирует Ваш класс.
То же верно при обеспечении метода считывания; необходимо или возвратить копию внутреннего colleciton или версию только для чтения ее. Наборы свободного городского населения Apache и наборы Google предоставляют методы для создания неизменных оберток вокруг набора, а также тех, которые идут с Java в java.util пакете; java.util. Collections.unmodifiable*.