[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Переделывания класса
web-monster
Привет! Вообщем есть класс для разбивания данных на страницы(пагинатор) там идёт такое подключение:

$_DB = new mysqli($config->DB_HOST,$config->DB_USER,$config->DB_PASS,$config->DB_NAME);
$_PAGING = new Paging($_DB);
$r = $_PAGING->get_page( "SELECT * FROM таблица" );

while($row = $r->fetch_assoc())
{

и сам класс:
<?php
class
Paging {

private $page_size = 10;
private $link_padding = 10;
private $page_link_separator = ' ';
private $next_page_text = 'следующая >';
private $prev_page_text = '< предыдущая';
private $result_text_pattern = 'Показано с %s по %s из %s';
private $page_var = 'p';

private $db;
private $q;
private $total_rows;
private $total_pages;
private $cur_page;

public function __construct($db, $q='', $page_var='p')
{
$this->db = $db;
if ($q) $this->set_query($q);
$this->db->query('SET NAMES UTF8');
$this->page_var = $page_var;
$this->cur_page = isset($_GET[$this->page_var]) && (int)$_GET[$this->page_var] > 0 ? (int)$_GET[$this->page_var] : 1;
}

public function set_query($q)
{
$this->q = $q;
}

public function set_page_size($page_size)
{
$this->page_size = abs((int)$page_size);
}

public function set_link_padding($padding)
{
$this->link_padding = abs((int)$padding);
}

public function get_page($q='')
{
if ($q) $this->set_query($q);

$r = $this->db->query( $this->query_paging($this->q) );
$this->total_rows = array_pop($this->db->query('SELECT FOUND_ROWS()')->fetch_row());

if ($this->page_size !== 0) $this->total_pages = ceil($this->total_rows/$this->page_size);

return $r;
}

public function get_result_text()
{
$start = (($this->cur_page-1) * $this->page_size)+1;
$end = (($start-1+$this->page_size) >= $this->total_rows)? $this->total_rowssad.gif$start-1+$this->page_size);

return sprintf($this->result_text_pattern, $start, $end, $this->total_rows);
}

public function get_page_links()
{
if ( !isset($this->total_pages) ) return '';

$page_link_list = array();

$start = $this->cur_page - $this->link_padding;
if ( $start < 1 ) $start = 1;
$end = $this->cur_page + $this->link_padding-1;
if ( $end > $this->total_pages ) $end = $this->total_pages;

if ( $start > 1 ) $page_link_list[] = $this->get_page_link( $start-1, $start - 2 > 0 ? '...' : '' );
for ($i=$start; $i <= $end; $i++) $page_link_list[] = $this->get_page_link( $i );
if ( $end + 1 < $this->total_pages ) $page_link_list[] = $this->get_page_link( $end +1, $end + 2 == $this->total_pages ? '' : '...' );
if ( $end + 1 <= $this->total_pages ) $page_link_list[] = $this->get_page_link( $this->total_pages );

return implode($this->page_link_separator, $page_link_list);
}


public function get_next_page_link()
{
return isset($this->total_pages) && $this->cur_page < $this->total_pages ? $this->get_page_link( $this->cur_page + 1, $this->next_page_text ) : '';
}


public function get_prev_page_link()
{
return isset($this->total_pages) && $this->cur_page > 1 ? $this->get_page_link( $this->cur_page - 1, $this->prev_page_text ) : '';
}


private function get_page_link($page, $text='')
{
if (!$text) $text = $page;

if ($page != $this->cur_page)
{
$reg = '/((&|^)'.$this->page_var.'=)[^&#]*/';
$url = '?'.( preg_match( $reg, $_SERVER['QUERY_STRING'] ) ? preg_replace($reg, '${1}'.$page, $_SERVER['QUERY_STRING']) : ( $_SERVER['QUERY_STRING'] ? $_SERVER['QUERY_STRING'].'&' : '' ).$this->page_var.'='.$page);
return '<a href="'.$url.'">'.$text.'</a>';
}

return '<span>'.$text.'</span>';
}


private function query_paging()
{
$q = $this->q;

if ($this->page_size != 0)
{
$start = ($this->cur_page-1) * $this->page_size;
$q = preg_replace('/^SELECT\s+/i', 'SELECT SQL_CALC_FOUND_ROWS ', $this->q)." LIMIT {$start},{$this->page_size}";
}

return $q;
}


public function all()
{
return sprintf($this->total_pages);
}


public function now()
{
return sprintf($this->cur_page);
}

}

?>

я подключаюсь к базе так:
<?php
require_once "dbconfig.php";
class Db extends Config {

private $connection ;

function __construct() {
$this->open_connection() ;
//echo "Соединение установлено" ;
}

private function open_connection()
{
$this->connection = mysql_connect($this->DB_HOST,$this->DB_USER,$this->DB_PASS) ;
if(!$this->connection)
{
die("Нет соединения с базой: ". mysql_error()) ;
}
else
{
$db_select = mysql_select_db($this->DB_NAME) ;
if(!$db_select)
{
die("Нет соединения с таблицей: ". mysql_error()) ;
}
}

mysql_query("set names utf8") or die("set names utf8 failed") ;
}

public function sql($query)
{
$result = mysql_query($query, $this->connection);
if(!$result)
{
die("Ошибка запроса: ".mysql_error());
}
return $result;
}
}


$db = new db() ;
?>

Помогите переделать класс чтобы он брал общее подключение а не открывал каждый раз новое!



Спустя 1 час, 27 минут, 31 секунда (29.06.2010 - 02:28) SlavaFr написал(а):
private static $connection =false;
.........

function __construct() {
self::open_connection() ;
......


private static function open_connection()
{
self::$connection = self::$connection?self::$connection:mysql_connect($this->DB_HOST,
$this->DB_USER,
$this->DB_PASS) ;
if(!self::$connection)
{
die("Нет соединения с базой: ". mysql_error()) ;
}
else
{
$db_select = mysql_select_db($this->DB_NAME,self::$connection) ;
if(!$db_select)
{
die("Нет соединения с таблицей: ". mysql_error()) ;
}
}

mysql_query("set names utf8",self::$connection) or die("set names utf8 failed") ;
}
......

a die() это не хорошо, ползуйся Еxception.
и set names желательно на mysql_set_charset поменять (если версия пхп >5.2.3)

Спустя 6 часов, 19 минут, 58 секунд (29.06.2010 - 08:48) linker написал(а):
mysql_pconnect()

Веселая конструкция "self::$connection = self::$connection", аля true=true

Спустя 26 минут, 48 секунд (29.06.2010 - 09:15) SlavaFr написал(а):
Цитата (linker @ 29.06.2010 - 05:48)

Веселая конструкция "self::$connection = self::$connection", аля true=true

еще раз внимательно посмотри

Спустя 9 минут, 32 секунды (29.06.2010 - 09:24) linker написал(а):
Цитата (SlavaFr @ 29.06.2010 - 06:15)
Цитата (linker @ 29.06.2010 - 05:48)

Веселая конструкция "self::$connection = self::$connection", аля true=true

еще раз внимательно посмотри

Советую заменить на банальное, просто и более читабельное
if (!is_resource(self::$connection)) { /* подключаемся */ }

Обычно такое делают с синглтонами, но там конструктор в приват, а подключение в паблик, у вас наоборот.

Спустя 8 минут, 17 секунд (29.06.2010 - 09:32) SlavaFr написал(а):
согласен, что
if (!is_resource(self::$connection)) { /* подключаемся */ }
более читабельно.
mysq_pconnect работает только если пхп как модуль к апаче работает и приводит часто к проблемам при трансакциях. Если Б.Д innoDB, то лучше от этой функции откаратся.

Спустя 24 минуты, 10 секунд (29.06.2010 - 09:57) twin написал(а):
Цитата
a die() это не хорошо, ползуйся Еxception.

Чем именно и почему?

Спустя 22 минуты, 25 секунд (29.06.2010 - 10:19) SlavaFr написал(а):
Цитата (twin @ 29.06.2010 - 06:57)
Цитата
a die() это не хорошо, ползуйся Еxception.

Чем именно и почему?

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

Спустя 22 минуты, 27 секунд (29.06.2010 - 10:42) twin написал(а):
Чесно говоря я вообще не вижу необходимости использовать класс для организации коннекта. Вполне достаточно функции, которую кстати так же точно можно многократно использовать.
Ну да дело вкуса конечно.

А вот насчет
Цитата
Программисту который классом пользуется предоставленно самому решать что и как он должен делать в случае если нет коннекции или еще чегото не хватает и свои идеи в случае той или иной ошибки он излагает в catch блоке.
могу сказать точно - это вредная практика в данном случае. И делается только для того, что так положено. Невзирая на здравый смысл.

1. - Если вызван сей класс, значит коннект все же потребовался. И без него продолжение работы скрипта не имеет никакого смысла. Можно еще согласиться, что это нужно на стадии отладки, но вопрос то был: чем эксепшен в данном случае предпочтительнее? Почему то, что программист решит делать в случае отсутствия коннекта, нужно помещать в catch, а не сделать тут же, не отходя от кассы? Ведь не секрет, что исключения изрядно тормозят программу. Более того, отладка отладкой, но класс останется с ним и в боевом применении. А значит на всегда останется и этот тормоз.

2. - Никоем образом эксепшен не способствует многократному и универсальному использованию по крайней мере этого класса. Он вообще к универсальности имеет очень посредственное отношение.

3. - Тут вообще не понял ничего. Чем легче?

Вывод напрашивается сам собой. Желание сделать "по взрослому" часто приводит к не очень то положительным результатам.

Спустя 36 минут, 22 секунды (29.06.2010 - 11:18) linker написал(а):
twin
Ситуации бывают разные, с одним коннектом на мускул-сервер, конечно не имеет смысла изгаляться слишком сильно. Но всегда есть варианты, когда их несколько и пользователю не очень хочется смотреть на какие-то ошибки, на одном из них, т.к. второй работает, а пользователь тоже в этом случае должен работать. Или когда те же два сервака, но один бэкапный и в случае когда первый падает, то необходимо переключиться на второй. Как-то так.

Спустя 16 минут, 45 секунд (29.06.2010 - 11:35) twin написал(а):
Вот вот. Всегда в погоне за универсальными решениями оптимальность и другие показатели (та же прозрачность кода) отодвигается на второй план.

Искушение написать супер-пупер программу, которая умеет все и даже штопать носки, очень велико. Однако как часто требуются эти специфичные условия?

Это сродни таким очень модным проявлениям, как класс для работы с БД. Основным аргументом выдвигается возможность использования разных баз данных. Но если сайт запущен и в базу попало несколько записей - всё. Этот класс начинает молотить вхолстую, так как никто и никогда в трезвом рассудке не станет менять коней на переправе.

Да и вообще, причем тут ексепшен? Какая разница где я буду обрабатывать ошибки? И буду ли вообще останавливать скрипт. Я так же точно могу их слогировать тут же, не рыская в поисках catch.

Собственно нельзя вообще сравнивать die и Еxception, тут вопрос о целесообразности применения последнего в данном скрипте.


Спустя 21 минута, 21 секунда (29.06.2010 - 11:56) linker написал(а):
twin
Нет, конечно же, такие ситуации очень редки. У меня например 6 MySql серверов, на одном из них 6 баз данных. Мне приходится всем этим делом рулить в практически полной абстракции и причем процесс работы приложения не должен прерываться на тупые сообщения об ошибках и эксепшенах, пока работает хотя бы один шести.

Спустя 37 минут, 33 секунды (29.06.2010 - 12:34) SlavaFr написал(а):
Цитата

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

Я на светофоре если детей вижу не когда не буду на крассный свет переходить, чтоб детям плохой пример не подовать. Да, так положенно по тому, что так оговоренно.
в данном случае создается класс который везде и на каждом шагу употреблятся будет (не зря хочет @web-monster, чтоб коннекция статической была).

з другой стороны никто не вправе зделать заявление, что без Б.Д программу нужно какимто заявлением типа "нет конекции" закончить .
Цитата

Если вызван сей класс, значит коннект все же потребовался. И без него продолжение работы скрипта не имеет никакого смысла. Можно еще согласиться, что это нужно на стадии отладки, но вопрос то был: чем эксепшен в данном случае предпочтительнее?  Почему то, что программист решит делать в случае отсутствия коннекта, нужно помещать в catch, а не сделать тут же, не отходя от кассы? Ведь не секрет, что исключения изрядно тормозят программу. Более того, отладка отладкой, но класс останется с ним и в боевом применении. А значит на всегда останется и этот тормоз.

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

Да конечно так как он зделан с die() , то его универсальным на назавеш. если бы он исопльзовал Еxception то может быть его можно было бы и многократно пременить.
Цитата

3. - Тут вообще не понял ничего. Чем легче?


у меня сейчас 2300 скриптов в порэкте, в среднем около 600 строчек. Очень удобно с помощью поиска прыгать к слову "catch".
Цитата

Вывод напрашивается сам собой. Желание сделать "по взрослому" часто приводит к не очень то положительным результатам.

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

Спустя 1 час, 13 минут, 5 секунд (29.06.2010 - 13:47) twin написал(а):

Все исходит из вот этой (на мой взгляд) ошибочной трактовки ООП парадигмы:
Цитата
ООП было зделанно так же для того чтоб код многократно использовать и при возможности легко изменять.

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

С чем и столкнулся автор топика. Не суй он это все в класс, не возникло бы проблем. Ну а сунул, в погоне за крутизной кода, его право. Только зачем же еще усугублять то? Зачем раздувать из двух строк кода такого бегемота, еще и облепленного ексепшенами? Не мудрено, что у тебя
Цитата
2300 скриптов в порэкте, в среднем около 600 строчек

Там конечно без бутылки не разобраться.

Тут вопрос собственно не в die, не в том как обработать ошибку. Вопрос где её обработать. А останавливать скрипт или нет - вопрос второй.

Цитата
Очень удобно с помощью поиска прыгать к слову "catch".

Ну да, куда как удобнее, чем увидеть это тут же, вообще никуда не прыгая.

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

Цитата
Я на светофоре если детей вижу не когда не буду на крассный свет переходить, чтоб детям плохой пример не подовать. Да, так положенно по тому, что так оговоренно.
Похвально. Но один момент. Светофор ставит ГАИ, а тут ты ориентируешься на самодельную табличку - "не въезжать!", которую написала тётя Сара из соседнего подъезда, потому что "разъездились тут". Ты поедешь в объезд?

Стандарта такого нет, есть кем то продекларированное самописное правило, которое исполняется по принципу "если все, то я тоже".

Но использовать все, что имеется в арсенале только потому, что имеется, не взирая на последствия... Или ты думаешь, что все, что есть и используется - хорошо и правильно? Ни о чем не говорит слово deprecated?

Ведь и магические кавычки когда то трактовались как абсолютное добро, а что вышло?


Спустя 35 минут, 16 секунд (29.06.2010 - 14:22) linker написал(а):
Цитата
ООП придумали для того, чтобы локализовать сложный функционал своей областью видимости и разнообразными способами использования.

А чем работа с базой данных с использованием классов противоречит данному принципу? Есть MySQL, есть MSSQL, есть PostgreSQL, я не хочу заморачивать, какая база данных используется в том или ином проекте, а может быть их несколько в одном, я хочу просто написать $Server->connect();
Или я могу написать $Object->query($Sql);, где в качестве $Object может выступать и сам SQL-сервер, или база данных или конкретная таблица (для того чтобы выполнять запросы достаточно одного коннекта, базу данных даже не надо выбирать в принципе), плюс $Object может быть и банальным XML-файлом, у которого тоже есть запросы XPath.
Область видимости, способы использования - это только часть принципов общего ООП.
ООП очень облегчает жизнь, но только в случае когда знаешь, что делаешь.

Спустя 11 минут, 48 секунд (29.06.2010 - 14:34) SlavaFr написал(а):
Цитата

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

Я лично боюсь делать такие заявления.

Спустя 5 минут, 9 секунд (29.06.2010 - 14:39) twin написал(а):
Цитата
ООП очень облегчает жизнь, но только в случае когда знаешь, что делаешь.
Кому? Вот в чем вопрос то.
В данном случае только разработчику. Потому что да, проще написать одну строчку, воспользовавшись готовым классом. Я писал об этом чуть выше.

Только ты напишешь эту строчку один раз, потому что
Цитата
я не хочу заморачивать, какая база данных используется в том или ином проекте

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

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

Если рассуждать с точки зрения - быстрее сляпать, получить бабосы и забыть как страшный сон - то да. Обчем речь.

Только почему это возводится в степень грамотной реализации? Почему это
Цитата
Да, так положенно по тому, что так оговоренно.
?

Цитата
Область видимости, способы использования - это только часть принципов общего ООП.
Не спорю. Но это хоть как то оправдано. А вот остальное нет. В веб-разработке однозначно. Кстати, подобная полемика уже была.

Спустя 19 минут, 19 секунд (29.06.2010 - 14:58) SlavaFr написал(а):
@twin в серьезном софте нет чистой веб-разработки. веб это только разновидность комуникации с зерном программы.

Я предлогаю забанить @web-monster, ты посмотри какой он здесь базар развел biggrin.gif

Спустя 6 минут, 53 секунды (29.06.2010 - 15:05) twin написал(а):
Да хоть горшком назови, суть не изменится))

Спустя 9 минут, 23 секунды (29.06.2010 - 15:14) linker написал(а):
Цитата
а заказчик будет гонять мертвый код несколько лет. Потому что не будет он использовать разные БД в рамках одного проекта.

Вы что-нибудь знаете про autoload классов?
Цитата
И ковыряться в этих безобразиях придется может не одному программисту. И оплачиваться будет не только время работы скрипта, но и время программиста, который будет вынужден в этом всем разбираться. Каждого программиста.

А зачем программисту разбираться в том, как работает класс, ровно для того чтобы тупо извлечь из базы некоторые данные одним методом? Не важно "как работает", важно "что на выходе". Это равносильно, что пытаться копаться в сишном коде, который отвечает за функцию fopen(), чтобы понять как она там внутрях работает.

Спустя 9 минут, 31 секунда (29.06.2010 - 15:24) twin написал(а):
Цитата
Вы что-нибудь знаете про autoload классов?

Причем тут это? Конечно знаю. Но я совсем не о том.

Вот к примеру опенсоурсная знаменитая MediaWiki
Там класс для работы с БД занимает (если мне не изменяет память) что то около 1600 строк. Предусмотрено все и на все случаи жизни. Но если я инсталлирую эту штуку себе на хостинг, там будет определенная база данных. Не важно какая, но одна. И значит весь этот универсальный класс - пшик и гиря на ногах. А все в угоду универсальности.

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

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

Цитата
А зачем программисту разбираться в том, как работает класс, ровно для того чтобы тупо извлечь из базы некоторые данные одним методом? Не важно "как работает", важно "что на выходе".
Очень важно. Никогда я не доверюсь черному ящику. Мало ли кто и как там чего набуробил. Инкапсуляция пусть радует юниоров, им чем меньше проблем, тем лучше. А я себя крайне неуютно чувствую, если не могу что то контролировать и не знаю как это устроено.



Спустя 30 минут, 21 секунда (29.06.2010 - 15:54) SlavaFr написал(а):
Цитата (twin @ 29.06.2010 - 12:24)
Цитата
А зачем программисту разбираться в том, как работает класс, ровно для того чтобы тупо извлечь из базы некоторые данные одним методом? Не важно "как работает", важно "что на выходе".
Очень важно. Никогда я не доверюсь черному ящику. Мало ли кто и как там чего набуробил. Инкапсуляция пусть радует юниоров, им чем меньше проблем, тем лучше. А я себя крайне неуютно чувствую, если не могу что то контролировать и не знаю как это устроено.

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

Спустя 18 минут, 14 секунд (29.06.2010 - 16:13) linker написал(а):
Цитата
Причем тут это? Конечно знаю. Но я совсем не о том.

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

Откройте скрипт в нормальном PHP IDE и он вам разложит все по полочкам.
Цитата
Очень важно. Никогда я не доверюсь черному ящику. Мало ли кто и как там чего набуробил.

Ну тогда почему вы доверяете такому "черному ящику" как print() или mysql_connect(), мало ли чего там набуробил разраб? Вы же не лезите копаться в их внутренностях, вас вполне устраивает результат, который они отдают. Так и здесь, если класс отлично справляется с работой и его функционал достаточен, то и не фиг туда лезть, зато всегда при желании можно расширить функционал, причем не затрагивая старый код - наследование.

Спустя 1 час, 9 минут, 5 секунд (29.06.2010 - 17:22) twin написал(а):
Цитата
я писал ранее "ООП очень облегчает жизнь, но только в случае когда знаешь, что делаешь", не надо запихивать в одни класс абсолютно весь функционал.
Так а зачем тут предлагается именно это и сделать? Или я не прав:
Цитата
Есть MySQL, есть MSSQL, есть PostgreSQL, я не хочу заморачивать, какая база данных используется в том или ином проекте, а может быть их несколько в одном, я хочу просто написать $Server->connect();
Причем это как раз и начинается с безобидных на первый взгляд эксепшенов, а потом пошло-поехало. Рождается очередной кривой монстр, который выдается за супер-пупер-все-могу. Стоит только написать две строчки кода. И это считается крутым, никто не скажет:
Цитата
не twin, тогда лучше на асемблер переходить, все видно как на ладони.
Это кстати самый распространенный аргумент. Я могу кучу ссылок дать на подобные холивары, которые этим и заканчиваются - асмом и бейсиком. А что можно нормально и оптимально писать код, как то мимо ушей. Главное чтобы было круто.

Цитата
Ну тогда почему вы доверяете такому "черному ящику" как print() или mysql_connect(), мало ли чего там набуробил разраб?
Во всем должна быть мера. И не сказал бы я, что слепо доверяю. Как раз нет. И очень часто тестирую те или иные варианты даже на уровне ядра языка, чтобы найти оптимальное решение. Но PHP - это стандарт, а все остальное рукоблудие - черт знает что.

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

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

Я ни к чему не призываю, оно само когда-нибудь поймется. Просто мне повезло в свое время, и я учился у человека, который этим уже переболел. И смог объяснить сразу эту "детскую болезнь левизны в коммунизме".
Быть может и топикстартеру бы повезло пройти это малой кровью, но когда более опытные люди говорят:
Цитата
a die() это не хорошо, ползуйся Еxception.
он примет это за чистую монету и потратит кучу времени на осознание. smile.gif

А сей топик читает не только он, потому я и не молчу. И молчать не стану.

Что касается
Цитата
Можно разделить, но унаследоваться от одного базового (абстрактного) либо использовать интерфейсы. Тогда и autoload будет причем.
то по сути это еще хуже на самом деле. Стоит только внимательно разобраться что к чему. Гораздо хуже.

Спустя 1 час, 1 минута, 25 секунд (29.06.2010 - 18:23) web-monster написал(а):
да собственно try и catch плохо читается в коде, куда понятней обычном способом..
Тем более что особой выгоды нет smile.gif
Ну и по теме: какой же самый оптимальный вариант подключения к базе, с условием что он будет везде использоваться и класс пагинации(который в первом посту) использовал это подключение.

Спустя 1 час, 31 минута, 53 секунды (29.06.2010 - 19:55) twin написал(а):
На сколько я могу судить - класс пагинатора используется в комплекте с другим классом бд ( mysqli ). А это не просто подключение, а именно то, о чем тут и полемика. То есть используются его методы.

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

Спустя 44 минуты, 26 секунд (29.06.2010 - 20:39) web-monster написал(а):
Я это и собирался делать, но возникли трудности) По-этому сюда и написал. Никак не могу догнать как его перегнать

Спустя 17 минут, 23 секунды (29.06.2010 - 20:57) twin написал(а):
Переделать просто.

В конструкторе оставь только это
    public function __construct($q='', $page_var='p')
{

if (!empty($q))
$this->set_query($q);

$this->page_var = $page_var;
$this->cur_page = isset($_GET[$this->page_var]) && (int)$_GET[$this->page_var] > 0 ? (int)$_GET[$this->page_var] : 1;
}

Вот эту залихватскую конструкцию
$r = $this->db->query( $this->query_paging($this->q) );

можно спокойно написать так:
$r = mysql_query($this->query_paging($this->q));

а этот верх девелопинга
$this->total_rows = array_pop($this->db->query('SELECT FOUND_ROWS()')->fetch_row());

вот так
$this->total_rows = mysql_result(mysql_query('SELECT FOUND_ROWS()'));


Правда там останется куча мусора, но это уже сам разгребай.

Ну а коннект можешь и свой использовать. Просто автономно.

Спустя 6 минут, 10 секунд (29.06.2010 - 21:03) linker написал(а):
Цитата
Так а зачем тут предлагается именно это и сделать?

Именно это тут и не предлагается
Цитата
Причем это как раз и начинается с безобидных на первый взгляд эксепшенов, а потом пошло-поехало. Рождается очередной кривой монстр, который выдается за супер-пупер-все-могу. Стоит только написать две строчки кода. И это считается крутым, никто не скажет

Кривой монстр, это когда <?php echo "Hello world"; ?> пытаются переписать под MVC или использование говноглобальных переменных. Но когда весь трудоемкий и постоянно используемый код оборачивают в класс, не нагружая его излишествами и следуя принципам ООП - это благо.
Цитата
Но PHP - это стандарт, а все остальное рукоблудие - черт знает что.
ООП - это тоже стандарт, причем заметно облегчающий жизнь программистам, но усложняющий для тех, кто не понимает ООП.

Следуя вашей логике - в топку: питон, c++, pascal, javascript и пр. и пр. все они используют ООП, а значит программеры, которые на них пишут - халявщики и безграмотные. Возьмите любое приложение и в топку, оно написано с помощью ООП, хотя надо было чистыми функциями.

Холивар получается только тогда, когда народ не понимает, когда и при каким обстоятельствах выбирать тот или иной способ кодирования.
Цитата
то по сути это еще хуже на самом деле. Стоит только внимательно разобраться что к чему. Гораздо хуже.
Либо, если не попадались действительно серьезные проекты.

Спустя 13 минут, 1 секунда (29.06.2010 - 21:16) twin написал(а):
Я ни слова не сказал о ООП в общем его проявлении. Я сказал о нем применительно к веб-разработкам. Причем не вообще о ООП, а именно его бездумном и фанатичном применении. Я сам с удовольствием использую классы, но только там, где они действительно себя оправдывают. Пагинатор - как раз тот случай. Вот мой, если интересно.

А класс БД - чушь. И ексепшены тоже кстати. smile.gif

Вот сей топик яркое тому подтверждение. Человек заблудился в трех соснах, потому что класс пагинатора заточен на класс БД, который явно выдран из какого то приложения. И теперь он второй день греет голову, как же сделать так, что бы все работало.

А все из-за того, что кто то рассуждал так же, как и ты. Мол класс - это удобно. Это круто - можно разные базы данных юзать.

Ну ладно топикстартер выдрал откуда то, поделом. tongue.gif
Но в обслуживании таких проектов те же самые проблемы. Все запутано в клубок непонятно чего, разгребай.

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

А вот и нет . Это никакой не стандарт. И должно звучать так:
Цитата
заметно облегчающий жизнь разработчикам, но усложняющий для тех, кто будет с этим дальше работать.

Я понимаю ООП, но легче мне не становится. А у меня как раз такая профессия - чужие скрипты разгребать.

Спустя 15 минут, 57 секунд (29.06.2010 - 21:32) linker написал(а):
twin
Разгребать процедурный говнокод также трудоемко, как и оопшный, поверьте мне.
Опять же не побоюсь повторить, ООП - не стандарт, для тех кто его не понимает, а фигачит кто во что горазд. ООП - это абстракция, инкапсуляция, наследование и полиморфиз, они есть и они неизменны и незыблемы, поэтому я могу смело утверждать что ООП - это стандарт.
Цитата
потому что класс пагинатора заточен на класс БД, который явно выдран из какого то приложения.
Вы сами сказали эти заветные слова "класс пагинатора заточен на класс БД" и тут я согласен, ошибка при первоначальном проектировании архитектуры, и ООП тут вообще не причем.

Спустя 11 минут, 30 секунд (29.06.2010 - 21:43) twin написал(а):
Словеса. Я их часто слышу. Мол качественно спроектированное приложение на ООП - это легко и просто.
Только вот почему то таких качественно спроектированных приложений раз два и обчелся. А задокументированных еще меньше.

Что касается
Цитата
ООП - это абстракция, инкапсуляция, наследование и полиморфиз, они есть и они неизменны и незыблемы, поэтому я могу смело утверждать что ООП - это стандарт.
вот тут мое мнение. Я давал ссылку, тут повторяться не стану.

А что касается
Цитата
Разгребать процедурный говнокод также трудоемко, как и оопшный, поверьте мне.
не поверю. ООПэшный говнокод куда как говнистее во всех проявлениях. Начиная от технических проблем, заканчивая разбором полетов.


Спустя 8 минут, 38 секунд (29.06.2010 - 21:52) web-monster написал(а):
Что то не работает( Всё изменил! Вызов так делаю:

$_PAGING = new Paging();
$r = $_PAGING->get_page( "SELECT t1.id,t1.title,t1.category,t1.text,t1.comment,t1.view,t1.time,t2.opisanie FROM news t1,news_category t2 WHERE t1.category=t2.name ORDER by t1.id DESC" );

while($row = mysql_fetch_assoc($r))
{
данные
}

вываливает ошибку:

Warning: mysql_result() expects at least 2 parameters, 1 given in Z:\home\engine.com\www\paging.php on line 47

Спустя 1 минута, 42 секунды (29.06.2010 - 21:54) twin написал(а):
Ай, скюзми. Вот так:
$this->total_rows = mysql_result(mysql_query('SELECT FOUND_ROWS()'), 0);

Спустя 2 минуты, 43 секунды (29.06.2010 - 21:56) web-monster написал(а):
О как)) Работает! Спасибо smile.gif !

Спустя 7 минут, 11 секунд (29.06.2010 - 22:04) linker написал(а):
Цитата
Только вот почему то таких качественно спроектированных приложений раз два и обчелся
И конечно же в этом виновато ООП? А вам не приходила в голову мысль, что таки виноваты программисты криворучки, которые не умеют грамотно и квалифицированно спроектировать приложение на начальном этапе, еще до того, как взяться за клаву и написать первые строки кода?

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

Спустя 4 минуты, 3 секунды (29.06.2010 - 22:08) twin написал(а):
Цитата
А вам не приходила в голову мысль, что таки виноваты программисты криворучки, которые не умеют грамотно и квалифицированно спроектировать приложение на начальном этапе, еще до того, как взяться за клаву и написать первые строки кода?
Нет. Не приходило. Ибо вот живой пример:

Цитата
Вы сами сказали эти заветные слова "класс пагинатора заточен на класс БД" и тут я согласен, ошибка при первоначальном проектировании архитектуры, и ООП тут вообще не причем.

Это не ошибка. Это неизбежность.
Каким интересно знать образом можно было спроектировать класс пагинатора, если в концепцию приложения изначально заложена универсальность применительно к базам данных?
Тут или крестик снять или трусы надеть. smile.gif

Спустя 13 минут, 33 секунды (29.06.2010 - 22:21) linker написал(а):
Цитата
Нет. Не приходило. Ибо вот живой пример:
Лично я тут вижу неопытность программера, а не вшивость ООП.
Цитата
Это не ошибка. Это неизбежность

Неизбежность, это когда на готовый код натягивают левую архитектуру, т.е. сначала пишут, а потом думают. Имхо, надо сначала научиться думать, а потом писать и тогда не важно будет функции или классы с объектами.
Цитата
если в концепцию приложения изначально заложена универсальность применительно к базам данных
Вы опять говорите золотые слова, но не понимаете этого "в концепцию приложения изначально заложена" - неправильная архитектура, неправильная концепция. Какое было начальное проектирование, такая будет и реализация - в этом неизбежность и заключается. И опять же ООП тут ни коим боком не выступает.

Спустя 14 минут, 29 секунд (29.06.2010 - 22:36) twin написал(а):
Цитата
Вы опять говорите золотые слова, но не понимаете этого "в концепцию приложения изначально заложена" - неправильная архитектура, неправильная концепция. Какое было начальное проектирование, такая будет и реализация - в этом неизбежность и заключается. И опять же ООП тут ни коим боком не выступает.

Секундочку. Давай по полочкам. Концепция приложения проста - сделать максимально простой разработку. Это я вывел из этих слов
Цитата
Есть MySQL, есть MSSQL, есть PostgreSQL, я не хочу заморачивать, какая база данных используется в том или ином проекте, а может быть их несколько в одном, я хочу просто написать $Server->connect();
Или я могу написать $Object->query($Sql);
То бишь мы не задуряясь на то, какая будет использована база данных лепим универсальный класс.

И как в такой ситуации сделать запрос в пагинаторе? Только методом этого класса. Иначе весь смысл пропадает. А если пагинатор использует метод класса БД, то отдельно от него работать не станет, что мы и наблюдаем.

Тоесть что мы имеем. Имеем мы связанное приложение, классы которого не смогут работать вне контекста. Тоесть о повторном использовании класса пагинатора (в другом приложении) речи нет никакой.

Это что - ошибка проектирования? Это неправильная архитектура? Неправильная концепция?

Любопытно посмотреть, как тут спроектировать правильно.

Спустя 10 часов, 8 минут, 41 секунда (30.06.2010 - 08:44) linker написал(а):
Цитата
Секундочку. Давай по полочкам. Концепция приложения проста - сделать максимально простой разработку. Это я вывел из этих слов
это только часть, разработка должна не только быть простой, но еще и: удобной, масштабируемой, легко поддерживаемой, отказоустойчивой и пр. Многих этих вещей не добиться обычным процедурным программированием. Не, для хоумпаги, там форума, портальчика, можно обойтись и без всего этого - слабал и забыл.
То бишь мы не задуряясь на то, какая будет использована база данных лепим универсальный класс.
Обычно так и делают, но давайте подумаем, что есть SQL-сервер, что есть база данных, что есть таблица? Контейнеры. Что у них общего? Хранят данные. Есть ли разница между MySQL сервером и MSSQL сервером? Фактически нет. Следовательно можно реализовать один базовый абстрактный класс SQL, в котором описываются 4-5 абстрактных метода и несколько полей класса. Допустим нам нужен MySQL и MSSQL, разница исключительно в названиях функций, ну и синтаксис SQL-запросов не всегда совпадает. Вывод, нужно еще два класса, которые будут наследоваться от базового, т.е. будут обязаны реализовать все абстрактные методы.
Файл 1.php
abstract class SQL
{
protected $Handle;
public $Host;
public $Port;
public $User;
public $Pass;

abstract public function Open();
abstract public function Close();
abstract public function Query($Query);
abstract public function Fetch($Resource);
}
Файл 2.php
class MySQL extends SQL
{
public function __construct($Host, $Port, $User, $Pass) { .... }
public function __destruct() { $this->Close(); }
public function Open() { $this->Handle = mysql_connect(); }
public function Close() { mysql_close($this->Handle); }
public function Query($Query) { return mysql_query($Query, $this->Handle); }
public function Fetch($Resource) { return mysql_fetch_assoc($Resource); }
}

Файл 3.php
class MSSQL extends SQL
{
public function __construct($Host, $Port, $User, $Pass) { .... }
public function __destruct() { $this->Close(); }
public function Open() { $this->Handle = mssql_connect(); }
public function Close() { mssql_close($this->Handle); }
public function Query($Query) { return mssql_query($Query, $this->Handle); }
public function Fetch($Resource) { return mssql_fetch_assoc($Resource); }
}
Докручиваем автолоад классов и все. Нужен сервер PostgreSQL, создали новый класс в файлике 4.php, реализовали методы и работаем дальше. Какие проблемы? XML - такая же база данных, нет ничего проще
Файл 5.php
class XML extends SQL
{
public $XmlFile;
protected $XPath;

public function __construct($XmlFile) { .... }
public function Open()
{
$this->Handle = new DomDocument('1.0', 'utf-8');
$this->Handle->load($this->XmlFile);
$this->XPath = new DOMXPath($this->Handle);
}
public function Close() {}
public function Query($Query) { return $this->XPath->query($Query); }
public function Fetch($Resource) {}
}
Также добавляем автолоад и подключаемся автоматом по необходимости. Какие проблемы? И не надо заморачиваться:
$Object = new $ClassName(host, port, user, pass); // $ClassName = MYSQL | MSSQL
$Object1 = new XML('my.xml');

$Object->Open();
$Object->Query("select * from database.table where field = 1");
$Object1->Open();
$Object1->Query('/*[@param = "myparam"]');

unset($Object);
unset($Object1);

Спустя 1 час, 19 минут, 54 секунды (30.06.2010 - 10:04) twin написал(а):
Цитата
это только часть, разработка должна не только быть простой, но еще и: удобной, масштабируемой, легко поддерживаемой, отказоустойчивой и пр. Многих этих вещей не добиться обычным процедурным программированием.
Это почему же, позвольте полюбопытствовать? Никогда я с этим не соглашусь. С точностью до наоборот. То же отсутствие множественного наследования ставит всю эту крутизну на глинянные ноги.

Все остальное как раз и иллюстрирует всю несостоятельность подхода.
Цитата
Также добавляем автолоад и подключаемся автоматом по необходимости. Какие проблемы?

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

2. Все запросы в остальном приложении должны быть оформлены в виде методов класса. Что мы уже проходили. То есть о повторном использовании любого класса этого приложения в другом месте можно забыть.

3. Вся эта конструкция не имеет ни малейшего смысла, так как синтаксис запросов разный и никак метод Query() не будет работать с SQL и XML одновременно. Все равно в приложении нужно менять текст запроса. А если этого не делать, придется парсить запрос и приводить в чувство. Что влечет за собой совершенно не нужное увеличение кода, а так же всевозможные глюки. Так как универсальность обратно пропорциональна надежности.

И все это работать будет на 10-20%, так как нет таких проектов, которые одновременно используют MySQL и PostgreSQL.

Увеличенный объем кода увеличит стоимость дальнейшего обслуживания.

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

    $db = mysql_connect( $_DBSERVER, $_DBUSER, $_DBPASSWORD ) or die('No connect');
mysql_select_db($_DATABASE, $db )or die('The database is not select');

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

Ровно тоже самое, если нам нужно использовать XML. Пишем функцию в файл и подключаем там, где нужна работа с БД

И всё! Как страшно написать простой код, это же не круто...

Теперь о плюсах.
1. Минимум функционала, а значит
а) Скорость
б) Ресурсобережливость
в) прозрачность
г) надежность

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

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

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

Спустя 44 минуты, 52 секунды (30.06.2010 - 10:49) SlavaFr написал(а):
twin ты на этом форуме человек с большой репутацией и должен особо осторжно делать свои заявления, так как начинающие программисты твои заявления как аксиомы принимать начинают. Я щитаю, что они не заслужили того, чтоб мы ихнее представление нашими амбициями поколечили.
Цитата

А класс БД - чушь. И ексепшены тоже кстати.

может это и стандарт, но там где ты чужие скрипты разгребаш.
Там где я скрипты разгребаю и БД и Ексепшены есть.

Спустя 13 минут, 38 секунд (30.06.2010 - 11:03) twin написал(а):
Там где я разгребаю их тоже полно. В том и беда.
Беда в том, что это делается без анализа ситуации, просто потому что так положено. Кем то и где то. Вопреки здравому смыслу.

Довод о том, что такие продукты делаются большими группами квалифицированных разработчиков (и куда мол лезешь) - несостоятельны. Ибо

1. Единожды принятая концепция приложения обычно не меняется от версии к версии. И разработчики вынуждены играть по установленным правилам.

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

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

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

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

Понять суть сразу - значит сэкономить время на переосмысление.

Спустя 10 минут, 36 секунд (30.06.2010 - 11:13) tomash написал(а):
twin
Добавлю свои пять копеек. ООП класно и круто))) Но не в PHP. Может в дальнейших версиях будет лучше, но 5-й PHP и ООП не совсем совместимые вещи. Вобщето любая универсальность имеет следствием избыточность, а в PHP это просто превращаеться в непролазные дебри кода. Класы удобная вещь, но классы это не ООП.

Спустя 1 час, 24 минуты, 42 секунды (30.06.2010 - 12:38) linker написал(а):
Цитата
Это почему же, позвольте полюбопытствовать? Никогда я с этим не соглашусь.

Удобство - тебя не волнует как реализован класс, от чего он там наследуется и прочее. Достаточно знать, что скормить и что на выходе.
Масштабируемость - любой класс можно расширить, наследуя или переписывая родительские методы.
Отказоустойчивость - допустим есть проект, там есть новости, которые описываются неким классом. Предположим, что понадобилось расширить функционал новостей, добавить пару новых полей и методов. Создаем новый класс, наследуемся от старого и работаем с новыми новостями, но старые новости так и остались в старом классе, а так как мы не трогали его, то и старые новости также будут продолжать работать без всяких проблем, причем одновременно с новыми.
Цитата
Вот какие.
1. Для того, чтобы скрипт работал корректно, нам придется
а) подключить базовый класс
б) автолоадом подключить еще один файл
в) инициализировать объект наследника
Сколько уже лишних операций? Дальше.

a) Вы видимо действительно не знаете для чего нужен автолоад и как он работает.
б) См.п. "а"
в) Это как понимать? Если строчки $Object = new MySQL(...); $Object->Open(); , то никто не мешает Open() запихнуть в конструктор и обойтись одной строкой создания объекта.
Цитата
2. Все запросы в остальном приложении должны быть оформлены в виде методов класса. Что мы уже проходили. То есть о повторном использовании любого класса этого приложения в другом месте можно забыть.

Зачем???!!! Сложно написать $Object->Query("select * from table");?
Цитата
3. Вся эта конструкция не имеет ни малейшего смысла, так как синтаксис запросов разный и никак метод Query() не будет работать с SQL и XML одновременно. Все равно в приложении нужно менять текст запроса. А если этого не делать, придется парсить запрос и приводить в чувство. Что влечет за собой совершенно не нужное увеличение кода, а так же всевозможные глюки. Так как универсальность обратно пропорциональна надежности.
Ну поймите, не важно как работает Query, важно какой метод, какого класса выполняется. Разный синтаксис относится к сложным запросам в большинстве случаев синтаксис одинаков. Если запросы и запихиваются в методы, то исключительно как самогенерируемые с учетом специфики класса. Пример:
$Storage = new $ClassName(...);
$Object = $Storage->GetObject(array('Name' => 'MyObject'));
где метод GetObject в каждом классе сам строит запрос, с учетом своей специфики и переданных значений.
$ClassName может быть любой класс, описывающий: MySQL, MSSQL, XML, CSV, FTP, банальная директория на диске и пр. все что может хранить внутри себя что-то и это что-то может быть представлено в виде объекта.
Для сложных запросов достаточно обойтись $Object->Query("...");
Цитата
И все это работать будет на 10-20%, так как нет таких проектов, которые одновременно используют MySQL и PostgreSQL.
Не чешите всех под одну гребенку, лично у меня на работе и MySQL и MSSQL, на моем хостинге MySQL и PostgreSQL.
Цитата
Увеличенный объем кода увеличит стоимость дальнейшего обслуживания.
Финальный и самодостаточный код не требует обслуживания и не имеет значение ООП это, или обычные функции.
Цитата
На самом же деле можно все это решить просто и незатейливо. Перед началом разработки уже известно, какая база данных будет использоваться. И меняться в процессе эксплуатации она уже не будет.
Вы заблуждаетесь. У меня есть проект, который расширился с 1 одного сервера до шести и с 1 базы данных до 13, 6 ftp серверов, около 500 пользователей. При этом работает это дело одновременно, пользователь думает, что все это барахло находится в одном месте, а я не написал ни одной строчки кода, когда система расширялась.
Цитата
в тот же подключаемый (без всяких автолоадов) файл, и мы сразу же избегаем всех этих проблем.
Наличие автолоада позволяет избегать рассованных по всему коду include(), require() и ты никогда не знаешь, а что же еще понадобится заинклудить завтра. Автолоад автоматически инклудит файл с классом, при первой же попытке создать объект класса, который еще не подключен (вся вредность мертвого кода, в данном случае, заключается лишь в том, что он занимает место на диске).
Цитата
Ровно тоже самое, если нам нужно использовать XML. Пишем функцию в файл и подключаем там, где нужна работа с БД
И при этом всегда знать, а с чем работаешь с XML или SQL да еще и помнить все имена функций: mysql_query, mssql_query, xml_query и прочее, плюс не забыть вовремя заинклудить тот или иной файл, вместо простого и одинакового для любого хранилища данных $Storage->Query(); в этом прелесть абстракции.
Цитата
2. Универсальность. При таком раскладе любой класс и любая функция приложения может быть использована отдельно, так как использует штатные, а не самопальные процедуры.
А что разве классы не используют штатные функции?
Цитата
3. Расширяемость. Ни чем не хуже, а гораздо лучше, чем в ООП. Потому что проще и прозрачнее. Написать функцию (или процедуру) для коннекта к любой другой базе данных проще, потому что нет рамок абстрактного класса. Да и потому, что ООП - это надстройка. А чем больше букаф, тем сложнее.
Банальный тест на вшивость расширяемости процедурного программирования, необходимо расширить функционал функции, но таким образом, чтобы старая осталась в неизменном виде, а новая сохранила старое название, причем и той и новой функцией придется пользоваться одновременно.
P.S. Поймите правильно, я против ООП в приложениях аля "Hello world", но когда занимаешься проектированием и разработкой действительно серьезного софта, с распределенной структурой хранения данных, распределенной нагрузкой, сложных бэкапах, репликациями и прочими премудростями, без ООП не обойтись.

Спустя 22 минуты, 15 секунд (30.06.2010 - 13:00) DedMorozzz написал(а):
Мб стоит перенести в тему "ООПухоль головного мозга"? Она имеет отношение именно к ней. А тут оставить сслыку на ту тему. А тема и вправду холиварная. Когда сильнейшие программисты спорят, что лучше (к примеру twin за процедурку, glock18 за ООП) и вот уже более 10и листов этой святой войны. И у всех куча аргументов smile.gif

Спустя 39 минут, 19 секунд (30.06.2010 - 13:40) twin написал(а):
Блин. Я про Фому, мне про Ярему.
Да какое же это удобство - писать такой монструозный класс, когда тоже самое можно сделать несколькими строчками?

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

Отказоустойчивость. Легко решается все это процедуркой на самом деле.
Другой вопрос - а надо ли оно?
На кой мне наследовать какую то хрень, попадая в зависимость от этого класса? Есть классы, которые удобно использовать в разных местах. Тот же пагинатор. Или аплоадер. Или почта. Или еще куча всего. Это оправдано.
Но весь функционал пихать в класс, а потом вить веревку наследований, каждый раз оглядываясь на базовый функционал... Шаг вправо - расстрел. Влево - повешание. Кругом рамки. Ради чего? Ну как не понятно то, что это всего навсего красивая упаковка, чаще всего на поверку оказывается обычным фетишем.

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

Но это все лирика. Теперь о главном. Что что там про автолоад? Чего я не знаю?

Проверить существование класса и если нет подключить одноименный файл? Такая сложность?
Знать как это работает мало. Нужно уметь это применить в нужном месте. В случае с базами данных это место не нужное. Потому что автолоад имеет смысл при выборе классов в динамике. Контроллеры те же. А подключать один единственно возможный файл автолоадом... Впрочем после этих слов
Цитата
Удобство - тебя не волнует как реализован класс, от чего он там наследуется и прочее. Достаточно знать, что скормить и что на выходе.

я ничему больше не удивляюсь.

Не удивляюсь тому, что не видно очевидного - вместо двух строк кода декларируется пара сотен в разных файлах, не удивляюсь тому, что не видно того, что это
Цитата
У меня есть проект, который расширился с 1 одного сервера до шести и с 1 базы данных до 13, 6 ftp серверов, около 500 пользователей. При этом работает это дело одновременно, пользователь думает, что все это барахло находится в одном месте, а я не написал ни одной строчки кода, когда система расширялась.

декларируется как заслуга ООП, а на самом деле решается в несколько раз проще процедурно, не удивляюсь тому, что мои слова
Цитата
нет таких проектов, которые одновременно используют MySQL и PostgreSQL.

трансформируются в
Цитата
лично у меня на работе и MySQL и MSSQL, на моем хостинге MySQL и PostgreSQL.

Ты так и не видишь сути проблемы.

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

Это беспредметный разговор хотя бы потому, что спорить со мной бесполезно. Я знаю проблему с обоих сторон, так как переболел (вернее перенес на ногах) ООПухоль головного мозга, а у тебя пока самый криз.

Вспомни эту беседу года через три-четыре.
На сим по совету DedMorozzz позволю себе откланяться/ smile.gif

Спустя 1 час, 3 минуты, 42 секунды (30.06.2010 - 14:43) linker написал(а):
Быстрый ответ:

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