Actionscript: использование событий против передачи себя объекту - что быстрее, лучше?

Question

Мой друг и я ведем эту дискуссию о том, что в AS3 быстрее передать это другому объекту, чтобы иметь возможность общаться / взаимодействовать между ними или, если события - путь. Хотя использование Events для выполнения этой задачи довольно стандартно, вот несколько фиктивных кодов для иллюстрации вопроса:

   public class ClassA{

   public var items:Array = new Array();
      public function classA(){
        items.push(new ClassB(this));
      }

      public function poke(){
         trace('yes, can i help you?');

         this.items.speak();
      }
   }



   public class ClassB{
      public var parentObject:Object;
      public function classB(pobj:Object){
        parentobject = pobj;
        parentobject.poke();
      }

      public function speak(pobj:Object){
          trace('nothing, forget it!');
      }
   }

Таким образом, если ClassA создается, он помещает новый объект ClassB в свой Array-Array. Конструктор ClassB вызывает poke () экземпляра Class-A, который немедленно вызывает функцию speak () - ClassB.

Я не знаю, каков правильный термин для этого метода (или, если есть, даже один). Мой друг говорит, что он чувствует, что его код работает быстрее при использовании многих объектов, но я сомневаюсь в этом, потому что думаю, что это может запутать сборщик мусора.

Что вы думаете об этой теме и какие источники вы бы порекомендовали прочитать по этой теме?

Answer 1

Разница в том, что события лучше разделяют ваши классы. Читать о Сцепление .

В коде, который вы дали, ваш класс B должен знать, что такое класс A, а ваш класс A должен знать, что такое ваш класс B.

В случае событий классы должны знать только то, где они могут найти экземпляр объекта, чтобы добавить к нему слушателя. Ему не нужно знать, какие функции вызывать или вызывать какие-либо функции, кроме addEventListener.

Отправляющий объект ничего не знает о слушателе.

Способ передачи сообщений в Events избавляет от тесной взаимозависимости классов, что может привести к проблемам с обслуживанием и поиском ошибок. Лучше знать как можно меньше о другом объекте. События хороши тем, что отправляющий объект может публиковать информацию о происходящем, не подвергая функции или внутренние детали другим объектам.

См: Слабая связь и Сплоченность .

Answer 2

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

В целом, такой тесно связанный подход ограничил бы сложность конкретного приложения настолько сильно, что не было бы никакой реальной необходимости оптимизировать скорость передачи сообщений.

Answer 3

Согласитесь с ответами kekoav и rhtx, но я бы также добавил, что вы пытаетесь оптимизировать то, что не требует оптимизации. В качестве последнего средства вы можете захотеть заменить события для простых вызовов методов, если вы действительно заметили замедление, но гадать, что может быть быстрее или медленнее, бессмысленно.