- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
<?php
class Event {
private static $_instance = NULL;
protected $_events_pool = array();
public static function getInstance() {
if (self::$_instance === NULL) {
$class = __CLASS__;
self::$_instance = new $class;
}
return self::$_instance;
}
private function __construct() { }
public function connect($event, $callback, array $params = null) {
$this->_events_pool[$event] = array(
'callback' => $callback,
'params' => $params,
);
return $this;
}
public function clear($event = NULL) {
if ($event === NULL) {
$this->_events_pool = array();
} else {
foreach ($this->_events_pool as $id => $_event) {
if ($_event['event'] === $event) {
$this->_events_pool[$id] = NULL;
}
}
}
}
public function emit($events = NULL) {
if ($events === NULL) {
$events = array_keys($this->_events_pool);
} else {
$events = (is_array($events)) ? $events : array($events);
}
foreach ($events as $event) {
foreach ($this->_events_pool as $id => $item) {
if ($id === $event) {
$this->call($this->_events_pool[$id]['callback']);
}
}
}
}
protected function call($class_name, $method_name = NULL, array $params = array(), array $class_params = array()) {
$_method = ($method_name === NULL) ? $class_name : array($class_name, $method_name);
call_user_func_array($_method, $params);
}
}
Follow us!
Если откинуть грамматические говняшки, типа "new $class;" вместо "new self();", перебор всех событий вместо того чтобы одним точным ударом вычесть нужное, то остаётся менее очевидное - protected функция call, которая должна вызваться из потомка, но его нигде тут не показано.
"Где здесь говнокод, nergal?!"
2.немного странный подход. Класс называется Event - ожидается, что обьектов будет два и более, а нет - видим шаблон синглтона. При этом организовывается очередь событий $_events_pool, и для работы с ней предоставляется интерфейс - но сама очередь событий НЕ статична!
имхо довольно обескураживающая логика, и через месяц такие вот особенности без доки забываются
Я бы рекомендовал переименовать класс в EventPool, и $_events_pool тоже на всякий случай сделать статичным - со стороны будет пониматься гораздо лучше.
Так вот:
1. Метод претерпел изменений и вместо __CLASS__ там get_called_class() - не могу сказать с уверенностью, под него ли я писал изначально, но очень на то похоже.
2. Также и с названием - сейчас этот файл есть частью фреймворка и носит имя Core_Signal.
Не вижу ничего плохого в нестатичности очереди - она существует покуда жив инстанс класса, следовательно, пока к нему можно будет обратиться.
в данном случае, может быть, кроме понимания и не будет ничего плохого, но в общем случае могут быть случаи:
а. из-за ошибки в реализации мы случайно создали другой инстанс - очереди тоже стало две
б. очередь доступна только в контексте обьекта - что значит, что зачастую извне мы не сможем получить очередь напрямую. Когда тут синглтон, то это неважно, а вот если мы бы организовали, скажем, пул - тогда бы нам пришлось явно указывать обьект
Что бы убица, если понадобится сделать вместо синглтона пул объектов?
а так мы можем создать только иллюзию статики, а внутренне организовывать различные обьекты, расширять класс потомками и так далее. Если нам нужны именно эти свойства синглтона, то вряд ли имеет смысл предоставлять разделяемые данные
Интересно, как можно расширить класс с приватным конструктором?;)))
Поэтому можно и синглтон расширить. Ну, на худой конец, обернуть...
б. А нам не нужна очередь напрямую - это ведь инкапсуляция по-сути, не так ли?)
И тут очевидно, что класс выполняет роль event dispatchera, чего умничать то =)