Jeurey`s blog

Избавляемся от геморроя ООП

Ноябрь 19, 2007

Я люблю ООП, честно... Только одно «НО» мешает — проблематично каждый раз передавать в различные конструкторы данные, которые на 95% бесполезны.

Какой же выход можно придумать?..

Для себя я решаю эту проблему так: в 99% случаев нужно передать в конструктор (да в любой метод, по сути) указатель на открытое соединение с базой данных. Если ваша система использует механизмы сессий — то имеет смысл хранить дескриптор в переменной сессии.

Как вариант, конечно же, использование «глобализации» переменной, содержащей указатель... Но зачем делать лишние телодвижения? =)

Добавить в закладки

: быстродействие 13 комментариев

13 комментариев на “Избавляемся от геморроя ООП”

[YS.PRO] высказал:
Ноябрь 28, 2007 в 18:56

«проблематично каждый раз передавать в различные конструкторы данные, которые на 95% бесполезны»

Зачем их тогда передавать? Либо используем как параметры по умолчанию. Или я что-то не понял?

Dogmat высказал:
Ноябрь 29, 2007 в 02:07

Как вариант, создавать статические методы у тематических классов.

и объектность сохраняется и глобализация не нужна.

Ex. вызов Connection::getConnection ();

Jeurey высказал:
Ноябрь 29, 2007 в 02:44

[YS.PRO], если нужно передать в класс пару массивов — что делать будете? А из всех массивов — вам только по три элемента нужно...

Или, скажем, так: чтобы не заводить экземпляры классов в различных классах — нужно их как-то собрать и передать «одним махом». Раньше я делал это массивом...

Вот и выгода.

2Dogmat: что быстрее — обращение к элементу глобального массива или вызов статического метода? =)

Dogmat высказал:
Ноябрь 30, 2007 в 01:16

2 Jeurey , оно конечно быстрее, но только вот удобство и архитектура ...

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

она может быть как важна так и вовсе роли не играть.

это к вопросу, о вечном споре delphi и c++, при разработке десктопов.

тут я придерживаюсь все же мнения «пока вы будете писать интерфейс в C++ , я вам накидаю несколько более сложных в Delphi»

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

к вопросу о массивах с элементами ...

есть такое понятие как ссылки на значение, когда не передается объект(копия объекта) а передается лишь ссылка на значение, сам ведь в курсе =)

к вопросу об экземпляров классов, есть такое понятие как синглтон, что собственно решает проблему с избыточностью новых экземпляров во многих случаях, тоже ты про это в курсе =)

вобчем ты сам про все в курсе =)

ps. остановись все таки на удобстве и следованию архитектуре,

а на функции возложи только lowlevel операции

Jeurey высказал:
Ноябрь 30, 2007 в 20:41

Ну-ну... Ты же знаешь, что я стараюсь писать не короткий код, а красивый и быстрый.

Слабость, ёпрст =)

Меня никто в сроки не гонит — есть поле для фантазии и самореализации =)

BDSoft высказал:
Февраль 17, 2008 в 18:07

на счет сессий, а вдруг куки не включены?

pimax высказал:
Февраль 19, 2008 в 02:59

Я не понимаю сути этого поста в блоге.

Может быть я просто плохой прогер, НО наследование еще никто не отменял.

Зачем что-то куда-то передавать? Массивы??? Это смешно...

Схема простая: есть базовый класс, от которого наследуется класс для работы с БД, и от базового класса наследуется еще например класс для работы с новостями. Сложно ли из класса новостей получить доступ к объекту для работы с БД? На мой взляд — НЕТ. Если Вы считаете что сложно — то советую перечитать матчасть.

Jeurey высказал:
Февраль 19, 2008 в 07:56

Не сложно...

К классу БД добавьте класс шаблонизатора, к нему — прибавьте класс валидатора, роутера-маршрутизатора, html-хелпера... Много получается? Теперь представляем себе 2 варианта:

1. Все ссылки на объекты содержатся в родительском классе.

2. Все ссылки лежать в глобальном массиве.

Что смешного во втором случае?

Первый вариант больше смахивает на написание «полувиртуальной» машины, написанной на php...

pimax высказал:
Февраль 19, 2008 в 15:04

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

А про глобальный массив — это что-то из области PHP 4. Но тогда была веская причина для глобалов, а сейчас зачем?

Jeurey высказал:
Февраль 20, 2008 в 06:17

А как прикажите получать ссылки на объекты изнутри класса?

Статическими функциями? 25 вызовов указателя на 1 класс — это и есть оптимизация кода?

pimax высказал:
Февраль 20, 2008 в 19:58

Не вижу логики, откуда 25 вызовов?

Я же писал то, что каждый класс подключается только в том случае, если он действительно нужен, все остальные программа даже не погружает в память.

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

jeurey высказал:
Февраль 22, 2008 в 15:09

Видимо, мы не понимаем друг-друга...

Возьму простой пример: класс debug.

Он складывает всю служебную информацию внутри своего атрибута $log.

Есть метод: add_info -он по определению не может быть статическим.

Метод дебаг используется в 10 классах. Каждый из них должен получить ссылку на объект debug.

Как прикажите в каждый из 10 классов отдать её? Новый объект ведь нет резона заводить.

ivan высказал:
Апрель 23, 2008 в 20:55

А зачем делать метод add_info статическим?

Ведь паттерн «одиночка» не зря же придумали...

Вот пример:

final class debug

{

private static $debug=NULL;

private $errors;

private $start_time;

private $stop_time;

private function __construct () {

$this->errors = array ();

$this->start_time=microtime (true);

}

public static function getDebug () {

if (debug::$debug==NULL) {

debug::$debug=new debug ();

}

return debug::$debug;

}

public function __toString () {

return 'debug';

}

public function addError ($error, $level=0) {

$this->errors[$level][]=$error;

}

public function out () {

$out='';

if (count ($this->errors)>0) {

$out.='';

foreach ($this->errors as $lvl => $error) {

foreach ($error as $val) {

$out.=''.$val.'';

}

$out.='';

}

$out.='Время выполнения: '.$this->execTime ();

return $out;

}

private function execTime () {

return microtime (true) -$this->start_time;

}

Далее в любом месте получаем ссылку на класс debug и используем его методы:

debug::getDebug () ->addError ('error 1');

при этом нового объекта не создается... а использование глобальных массивов типа $_SESSION вообще противоречит концепции ООП и ни чем не отличается от global $debug;

[YS.PRO] высказал:
Ноябрь 28, 2007 в 18:56
«проблематично каждый раз передавать в различные конструкторы данные, которые на 95% бесполезны»
Зачем их тогда передавать? Либо используем как параметры по умолчанию. Или я что-то не понял?
Dogmat высказал:
Ноябрь 29, 2007 в 02:07
Как вариант, создавать статические методы у тематических классов.
и объектность сохраняется и глобализация не нужна.
Ex. вызов Connection::getConnection ();
Jeurey высказал:
Ноябрь 29, 2007 в 02:44
[YS.PRO], если нужно передать в класс пару массивов — что делать будете? А из всех массивов — вам только по три элемента нужно...
Или, скажем, так: чтобы не заводить экземпляры классов в различных классах — нужно их как-то собрать и передать «одним махом». Раньше я делал это массивом...
Вот и выгода.
2Dogmat: что быстрее — обращение к элементу глобального массива или вызов статического метода? =)
Dogmat высказал:
Ноябрь 30, 2007 в 01:16
2 Jeurey , оно конечно быстрее, но только вот удобство и архитектура ...
можно все сделать и на функциях. можно и на гибриде. нужно просто понимать что и когда использовать. и важна ли тебе 0.0000001 секунды, при определенных условиях.
она может быть как важна так и вовсе роли не играть.
это к вопросу, о вечном споре delphi и c++, при разработке десктопов.
тут я придерживаюсь все же мнения «пока вы будете писать интерфейс в C++ , я вам накидаю несколько более сложных в Delphi»
в обчем, я предложил решение, когда и как использовать, нужно самому решать.
к вопросу о массивах с элементами ...
есть такое понятие как ссылки на значение, когда не передается объект(копия объекта) а передается лишь ссылка на значение, сам ведь в курсе =)
к вопросу об экземпляров классов, есть такое понятие как синглтон, что собственно решает проблему с избыточностью новых экземпляров во многих случаях, тоже ты про это в курсе =)
вобчем ты сам про все в курсе =)
ps. остановись все таки на удобстве и следованию архитектуре,
а на функции возложи только lowlevel операции
Jeurey высказал:
Ноябрь 30, 2007 в 20:41
Ну-ну... Ты же знаешь, что я стараюсь писать не короткий код, а красивый и быстрый.
Слабость, ёпрст =)
Меня никто в сроки не гонит — есть поле для фантазии и самореализации =)
BDSoft высказал:
Февраль 17, 2008 в 18:07
на счет сессий, а вдруг куки не включены?
pimax высказал:
Февраль 19, 2008 в 02:59
Я не понимаю сути этого поста в блоге.
Может быть я просто плохой прогер, НО наследование еще никто не отменял.
Зачем что-то куда-то передавать? Массивы??? Это смешно...
Схема простая: есть базовый класс, от которого наследуется класс для работы с БД, и от базового класса наследуется еще например класс для работы с новостями. Сложно ли из класса новостей получить доступ к объекту для работы с БД? На мой взляд — НЕТ. Если Вы считаете что сложно — то советую перечитать матчасть.
Jeurey высказал:
Февраль 19, 2008 в 07:56
Не сложно...
К классу БД добавьте класс шаблонизатора, к нему — прибавьте класс валидатора, роутера-маршрутизатора, html-хелпера... Много получается? Теперь представляем себе 2 варианта:
1. Все ссылки на объекты содержатся в родительском классе.
2. Все ссылки лежать в глобальном массиве.
Что смешного во втором случае?
Первый вариант больше смахивает на написание «полувиртуальной» машины, написанной на php...
pimax высказал:
Февраль 19, 2008 в 15:04
Ничего страшно не вижу в большом кол-ве классов. У меня в ядре системы порядка 25 классов. Но естественно, они не все подключаются одновременно, каждый подключается только тогда, когда он необходим...
А про глобальный массив — это что-то из области PHP 4. Но тогда была веская причина для глобалов, а сейчас зачем?
Jeurey высказал:
Февраль 20, 2008 в 06:17
А как прикажите получать ссылки на объекты изнутри класса?
Статическими функциями? 25 вызовов указателя на 1 класс — это и есть оптимизация кода?
pimax высказал:
Февраль 20, 2008 в 19:58
Не вижу логики, откуда 25 вызовов?
Я же писал то, что каждый класс подключается только в том случае, если он действительно нужен, все остальные программа даже не погружает в память.
Для тех которые нужны в базовом классе объявляется статические свойства и все дочерние классы взаимодействуют друг с другом непосредственно через обращение к этим свойствам в базовом классе.
jeurey высказал:
Февраль 22, 2008 в 15:09
Видимо, мы не понимаем друг-друга...
Возьму простой пример: класс debug.
Он складывает всю служебную информацию внутри своего атрибута $log.
Есть метод: add_info -он по определению не может быть статическим.
Метод дебаг используется в 10 классах. Каждый из них должен получить ссылку на объект debug.
Как прикажите в каждый из 10 классов отдать её? Новый объект ведь нет резона заводить.
ivan высказал:
Апрель 23, 2008 в 20:55
А зачем делать метод add_info статическим?
Ведь паттерн «одиночка» не зря же придумали...
Вот пример:
final class debug
{
private static $debug=NULL;
private $errors;
private $start_time;
private $stop_time;
private function __construct () {
$this->errors = array ();
$this->start_time=microtime (true);
}
public static function getDebug () {
if (debug::$debug==NULL) {
debug::$debug=new debug ();
}
return debug::$debug;
}
public function __toString () {
return 'debug';
}
public function addError ($error, $level=0) {
$this->errors[$level][]=$error;
}
public function out () {
$out='';
if (count ($this->errors)>0) {
$out.='';
foreach ($this->errors as $lvl => $error) {
foreach ($error as $val) {
$out.=''.$val.'';
}
}
$out.='';
}
$out.='Время выполнения: '.$this->execTime ();
return $out;
}
private function execTime () {
return microtime (true) -$this->start_time;
}
}
Далее в любом месте получаем ссылку на класс debug и используем его методы:
debug::getDebug () ->addError ('error 1');
при этом нового объекта не создается... а использование глобальных массивов типа $_SESSION вообще противоречит концепции ООП и ни чем не отличается от global $debug;

about PHP,SEO, WEB and Linux

Избавляемся от геморроя ООП

13 комментариев на “Избавляемся от геморроя ООП”

Страницы

Рубрики

Code for life :)

SEO / SMO

Архивы

Облако тегов

Интересное

Опросы

Последние заметки

Последние комментарии

О блоге