[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Вопрос по классам
I++
<?php

class
Connector
{
private static $connect_base;
private $handle_con;

public function connect($config)
{
// Код для подключения.
// Хэндл подключения привязывается внутри объекта $this->handle_con;
// В коде используется self::$connect_base;

}

private function sock_read()
{
// Читает данные, находит определенную команду например call_userfunc которая должна находиться в классе Facade
// Вызывает функцию call_userfunc

}

public function get_command($var)
{
// Что-то делает с Var
}
}


class ConnectorHandler
{
public function get_command($var)
{
// Что-то делает с Var после чего вызывает функцию call_userfunc2 которая должна находиться в классе Facade
}
}


class Facade
{
private $Servers_array = array();
private $ConnectorHandler;

public static function doIt()
{
$obj = new Connector;
$obj2 = new Connector;
$obj3 = new Connector;
$obj4 = new ConnectorHandler;

self::$Servers_array[] = $obj;
self::$Servers_array[] = $obj2;
self::$Servers_array[] = $obj3;
self::$ConnectorHandler = $obj4;

$obj->connect('example.com');
$obj2->connect('example.net');
$obj3->connect('example.ru');
}

private call_userfunc($var)
{
self::$ConnectorHandler->get_command($var);
}

private call_userfunc2($id, $var)
{
self::$Servers_array[$id]->get_command($var);
}
}


Facade::doIt();

?>


Все же как правильнее будет реализация подобной схемы, может колбэки хранить в отдельном классе?

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

Долго медитировал на разные паттерны, но все равно получается говнокод какой та... Хочется упростить разработку, за счет того, что каждый класс работает по отдельности, ConnectorHandler не сможет работать без Connector, но класс Connector в Facade сможет работать без ConnectorHandler.

Может в этом плане уже есть наработанные методы? А я тут велосипеды изобретаю.



Спустя 18 минут, 6 секунд (10.04.2012 - 08:14) glock18 написал(а):
насколько я понял, нужны френды. и дружественные функции/классы в пыхе не поддерживаются. наработанных методов для этого нет, насколько я знаю (кроме самого простого, что ниже), может быть что-то более-менее интересное можно в 5.4 версии при помощи трейтов замутить.

как вариант, делать все методы в Facade статичными и открытыми

Спустя 29 минут, 45 секунд (10.04.2012 - 08:43) I++ написал(а):
Да согласен трейты бы подошли ништяк, но по воле костыльстроения нужен пых 5.3, просто жуткий геморой собирать пых 5.4 из исходников, да и не все pecl'ы проверены, могут не работать.

В общем я решил как сделать, я буду дергать колбэки для статичного класса Facade из других классов, но предварительно в внутри класса Connector и ConnectorHandler, проверять какие методы реализованы в Facade и в зависимости от набора функционала дергать те или иные колбэки если они поддерживаются классом Facade.

Вот думаю правильно ли так делать или нет.

Цитата
как вариант, делать все методы в Facade статичными и открытыми


Иного выхода я тоже не вижу, все равно мне объект не требуется, у меня класс статичный.

Спустя 3 минуты, 41 секунда (10.04.2012 - 08:47) glock18 написал(а):
Цитата (I++ @ 10.04.2012 - 05:43)
В общем я решил как сделать, я буду дергать колбэки для статичного класса Facade из других классов, но предварительно в внутри класса Connector и ConnectorHandler, проверять какие методы реализованы в Facade и в зависимости от набора функционала дергать те или иные колбэки если они поддерживаются классом Facade.


можешь примерный use case привести?

Спустя 2 минуты, 57 секунд (10.04.2012 - 08:50) I++ написал(а):
Щас попробую, у меня просто событийная модель в каждом из классов, поэтому двумя словами не описать.

Спустя 19 минут, 5 секунд (10.04.2012 - 09:09) I++ написал(а):
Поэтапно работает так:

Facade::doIt();

Создаем объекты

$obj = new Connector;
$obj2 = new Connector;
$obj3 = new Connector;
$obj4 = new ConnectorHandler;

подключаемся

$obj->connect('example.com');
$obj2->connect('example.net');
$obj3->connect('example.ru');

внутри функции connect назначается переменная объекта handle_con, эта переменная может использоваться только в созданом объекте.
в self::$connect_base так же попадает handle_con это массив всех handle_con для всех объектов.

Входим в Connector::main_loop();
Тут проверяем состояние каждого подключения, если оно изменилось вызываем функцию sock_read для объекта в котором произошло событие.

sock_read находит комманду полученную с сокета и делает вызов Facade::call_userfunc('моя команда');

Внутри call_userfunc вызываем

self::$ConnectorHandler->get_command($var);

Попадаем в объект ConnectorHandler функцию get_command которая получила $var с значением 'моя команда', внутри идет обработка и проверка, есть ли такая команда, если есть дергаем Facade::call_userfunc2($id, 'моя команда');

попадаев в Facade::call_userfunc2($id, $var)

$id тут хранится номер в массиве где находится объект который породил событие в ConnectorHandler, например $id = 2;

дергаем self::$Servers_array[$id]->get_command('Да ништяк команда есть'); // Для того объекта который порадил событие, и передаем параметр о том, что Да такая команда существует.

Попадаем в объект $obj3->get_command('Да ништяк команда есть');

после чего, например пишем в сокет о том, что команда существует.

Выходим из функции и опять попадаем в main_loop в ожидании новой команды.

<?php
class
Connector
{
private static $connect_base;
private $handle_con;

public function connect($config)
{
// Код для подключения.
// Хэндл подключения привязывается внутри объекта $this->handle_con;
// В коде используется self::$connect_base;

}

private function sock_read()
{
// Читает данные, находит определенную команду например call_userfunc которая должна находиться в классе Facade
// Вызывает функцию call_userfunc

}

public function get_command($var)
{
// Что-то делает с Var
}

public function main_loop()
{
// Следит за всеми handle_con
}
}


class ConnectorHandler
{
public function get_command($var)
{
// Что-то делает с Var после чего вызывает функцию call_userfunc2 которая должна находиться в классе Facade
}
}


class Facade
{
private $Servers_array = array();
private $ConnectorHandler;

public static function doIt()
{
$obj = new Connector;
$obj2 = new Connector;
$obj3 = new Connector;
$obj4 = new ConnectorHandler;

self::$Servers_array[] = $obj;
self::$Servers_array[] = $obj2;
self::$Servers_array[] = $obj3;
self::$ConnectorHandler = $obj4;

$obj->connect('example.com');
$obj2->connect('example.net');
$obj3->connect('example.ru');

Connector::main_loop(); // Входим в бесконечный цикл (Основной эвент, он проверяет состояние всех объектов Connector, а так же всех объектов ConnectorHandler)
}

public function call_userfunc($var)
{
self::$ConnectorHandler->get_command($var);
}

public function call_userfunc2($id, $var)
{
self::$Servers_array[$id]->get_command($var);
}
}


Facade::doIt();

?>

Спустя 12 минут, 43 секунды (10.04.2012 - 09:22) I++ написал(а):
По сути вот такая схема колбэков:

class Connector
{
public function call($class)
{
call_user_func(array($class, 'callback'));
}
}


class Facade
{
public function main()
{
$obj = new Connector;
$obj->call(__CLASS__);
}

public static function callback()
{
echo 'my_callback';
}
}


Facade::main();

Спустя 27 минут, 16 секунд (10.04.2012 - 09:49) caballero написал(а):
жертва моды на паттерны - сочуствую.

Самое разумное здесь, выкинуть весь этот индусский код вместе с книжкой по паттернам.
А затем реализовать так чтобы решалась твоя задача по реализации необходимой бизнес логики. А ты пытаешся не задачу решить а паттернов насовать. Тем более это PHP а не ява - ООП без долгоживущих объектов уже неполноцнное и никакие паттерны тут не помогут.

Спустя 38 минут, 45 секунд (10.04.2012 - 10:28) glock18 написал(а):
Цитата (caballero @ 10.04.2012 - 06:49)
Самое разумное здесь, выкинуть весь этот индусский код вместе с книжкой по паттернам.
А затем реализовать так чтобы решалась твоя задача по реализации необходимой бизнес логики. А ты пытаешся не задачу решить а паттернов насовать. Тем более это PHP а не ява - ООП без долгоживущих объектов уже неполноцнное и никакие паттерны тут не помогут.


в целом верно. одно но - объекты в топике как раз долгоживущие скорее всего будут.

I++
для чего вообще тебе Facade? он здесь совершенно неуместен. Как по мне должно быть достаточно одного Коннектора (handler похоже из-за фасада только и нужен - какая-то дикая цепочка передачи команд)

Коннектор сам получает команду, и сам разбирает ее. Если команд много и всякие-разные, тогда можно для их разбора класс отдельный забацать. перхапс, handler - обработчик команд, тогда сущность тоже достаточно резонная мб. в этой ситуации статик метод с разбором команды (вопрос еще нужен ли он, вполне вероятно, что вовсе не нужен) разумно скинуть в класс, к которому он и относится

Фасад имхо тут даже неприменим просто.

Спустя 6 минут, 28 секунд (10.04.2012 - 10:34) I++ написал(а):
Цитата
жертва моды на паттерны - сочуствую.

Я не жертва паттернов.

Паттерны созданы для того, чтобы упрощать жизнь разработчику при проектировании приложений. Т.е грубо говоря: зачем изобретать велосипед, если есть готовые и проверенные схемы построения, упрощающие разработку и которые будут работать, без неожиданных глюков или тормозов от собственных велосипедов.

Цитата
Самое разумное здесь, выкинуть весь этот индусский код вместе с книжкой по паттернам.


Отлично, выкинул, как реализовать подобный функционал?

Цитата
А затем реализовать так чтобы решалась твоя задача по реализации необходимой бизнес логики.

Водолей?

Цитата
А ты пытаешся не задачу решить а паттернов насовать.


Очевидным выходом тут создание фасада либо трейтов, которые я не могу использовать.

Цитата
Тем более это PHP а не ява - ООП без долгоживущих объектов уже неполноцнное и никакие паттерны тут не помогут.


У меня долгоживущее приложение, демон слышал? И объекты могут умирать, создаваться в процессе, а так же могут меняться их свойства.

Можно было бы написать один большой класс в котором будут все функции, и чтобы осуществлять коннект как в моем случае, делать не 3 объекта, а 1 объект в котором будет массив подключений. И в конце концов я бы застрелился такой код понимать.

Спустя 6 минут, 28 секунд (10.04.2012 - 10:41) I++ написал(а):
Цитата (glock18 @ 10.04.2012 - 11:28)
Цитата (caballero @ 10.04.2012 - 06:49)
Самое разумное здесь, выкинуть весь этот индусский код вместе с книжкой по паттернам.
А затем реализовать так чтобы решалась твоя задача по реализации необходимой бизнес логики. А ты пытаешся не задачу решить а паттернов насовать. Тем более это PHP а не ява - ООП без долгоживущих объектов уже неполноцнное и никакие паттерны тут не помогут.


в целом верно. одно но - объекты в топике как раз долгоживущие скорее всего будут.

I++
для чего вообще тебе Facade? он здесь совершенно неуместен. Как по мне должно быть достаточно одного Коннектора (handler похоже из-за фасада только и нужен - какая-то дикая цепочка передачи команд)

Коннектор сам получает команду, и сам разбирает ее. Если команд много и всякие-разные, тогда можно для их разбора класс отдельный забацать. перхапс, handler - обработчик команд, тогда сущность тоже достаточно резонная мб. в этой ситуации статик метод с разбором команды (вопрос еще нужен ли он, вполне вероятно, что вовсе не нужен) разумно скинуть в класс, к которому он и относится

Фасад имхо тут даже неприменим просто.

Ну фасад мне нужен потому что у меня будет много классов. И в зависимости от коннекта, мне не потребуется подключать все классы.

Т.е класс Connector основной, его обязательно нужно подключить, остальные классы как расширения для класса Connector, либо они могут жить своей жизнью, но юзать свойства Connector'а. Например будет класс, который будет форкаться и делать чилдов, по концу обработки чилдов, класс будет вызывать колбэк внутри фасада, в этом колбэке я опишу, что делать дальше, например отправить в Connector сообщение, или ConnectorHandler отправить данные, который он обработает, а затем сам отправит в Connector.

Фасад будет служить в роли маршрутизатора между некоторыми данными получаемых из разных объектов и классов.

Спустя 18 минут, 33 секунды (10.04.2012 - 10:59) glock18 написал(а):
раз классов много будет разных, то мб фасад и к месту будет.

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

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

Спустя 13 минут, 17 секунд (10.04.2012 - 11:13) I++ написал(а):
Цитата (glock18 @ 10.04.2012 - 11:59)
раз классов много будет разных, то мб фасад и к месту будет.

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

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

Цитата
Классы, я так понимаю, наследники коннектора и хэндлера?


Нет, Connector это базовый функционал, который лишь принимает команды, для его расширения можно сделать множество классов, например ConnectorHandler, потом мне вдруг может понадобится, сделать пересылку команд броадкастом, в этом случае я подключаю класс Broadcast который принимает команду и рассылает её всем серверам с которыми связан, а так же получает от этих серверов команды и дергает колбэк внутри фасада, колбэк в фасаде получает данные которые отдал броадкаст и направляет их конектору или обработчику конектора.

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

Спустя 2 минуты, 35 секунд (10.04.2012 - 11:15) I++ написал(а):
В общем я щас кое какой код допиливаю, как доведу до минимального ума, могу скинуть показать.

Вроде по такой схеме работает, но я пока не уверен, что случится потом, когда всё распухнет, может оказаться так, что всё это говнокод и дальнейшее его расширение приведет к выносу мозга... Паттерн под подобное я не нашел, но фасад не плохо вписывается в задачу.

Спустя 1 час, 35 минут, 49 секунд (10.04.2012 - 12:51) caballero написал(а):
Цитата
Я не жертва паттернов.

То есть этот код не твой?

Цитата
Паттерны созданы для того, чтобы упрощать жизнь разработчику при проектировании приложений.


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

Цитата
Отлично, выкинул, как реализовать подобный функционал?

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


Цитата
У меня долгоживущее приложение, демон слышал?

не слышал ввиду опять же отсутсвия изначального описания задачи. Зачем делать демон на PHP тоже не понимаю.


Цитата
Например будет класс, который будет форкаться и делать чилдов, по концу обработки чилдов, класс будет вызывать колбэк внутри фасада, в этом колбэке я опишу, что делать дальше, например отправить в Connector сообщение, или ConnectorHandler отправить данные, который он обработает, а затем сам отправит в Connector.


Жесть!

Цитата
потом мне вдруг может понадобится,

Цитата
но некоторым классам могут понадобиться

Бритва Оккама - не надо плодить сущности сверх необходимого. Код который пишут на случай вдруг понадобится потом выкидывается или валяется мертвым грузом. Или получается фреймворк размерсм больше дистрибутива PHP.

Цитата
может оказаться так, что всё это говнокод и дальнейшее его расширение приведет к выносу мозга...

Осознание проблеммы - первый шаг к выздоровлению. biggrin.gif

Спустя 1 час, 23 секунды (10.04.2012 - 13:51) I++ написал(а):
Ща допилю код, скину и поймешь, что мне нужно было smile.gif

Цитата
надо описать этот функционал, а не кинуть кусок кода который непонятно что делает расчитывая что раз там паттерн то и так всем все ясно.


Ну дак словами описать точно, что и как работает сложновато слишком много чего происходит в коде.

Цитата
Думаю только некоторые ботаны могут запомнить, например, чем отличаются фасад , мост, адаптер, и прокси.


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

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

Спустя 1 час, 9 минут, 39 секунд (10.04.2012 - 15:01) caballero написал(а):
Цитата
Ну дак словами описать точно, что и как работает сложновато слишком много чего происходит в коде.

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

Цитата
Просто тут событийная модель со множеством коннектов, которые вызываются по событию, т.е рандомно.

все сервера так и работают - слушает сокет, получает конект и пошел обрабатывать. и никаких проблем с рандомностью. И никакая событийная модель тут не нужна тем более паттерны.


Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.