|
Пишем на PHP: out.class (начало)Руслан Курепин
Прошу прощения, что долго не выходил в
эфир.
Думаю, что оформить новый класс для вас не составит никакого труда. Теперь опять надо отложить в сторону кодирование и подумать над тем, что потребуется -- какие функции нам нужны для работы видимой части web-проекта. Прежде всего, нам потребуется вывод на сайт списка рубрик. Причем, каждое название рубрики должно быть ссылкой на страницу, которая показывает список всех текстов, имеющихся в данном разделе (рубрике). Далее. Из первого вытекает, что нам нужна функция, способная скомпоновать названия всех текстов раздела в нужном порядке и выложить их на сайт в виде ссылок на сами документы, не так ли? Это будет вторая функция, которую мы напишем для класса class_out. Пользуясь той же логикой, становится очевидно, что нам нужна функция, показывающая сам текст. Эту функцию напишем в последнюю очередь. Забегая немного вперед, хочу сказать, что после этих трех функций мы бросим программировать в чистом PHP и начнем "собирать" наш сайт уже с использованием html, styles и дры. Того, что будет написано -- уже достаточно для создания жизнеспособного сайта. Кстати, буду очень благодарен, если кто-то нарисует простенький дизайн для демонстрационного сайта по нашему материалу. Уже после того, как заработает наш сайт, мы займемся его техническим украшательством: подписка и рассылка материалов, голосовалки, гостевая, всевозможная статистика, напишем свой счетчик посещений -- поработаем с графикой, и так дальше. Почему я все это сообщаю сейчас? Потому, что хочу поднять одну не очень важную, но достаточно интересную тему. Я хотел ее коснуться чуть позже, но посетитель форума по имени Const затронул ее в своем сообщении, и я обещал раскрыть подробнее свою позицию по этому вопросу. В чем же, собственно, проблема. А в том, что классы можно рождать друг от друга хоть каждый раз, когда надо написать новую функцию. Удобно ли это? Или наоборот: разместить все перечисленные возможности сайта в один файл и тупо обращаться к нему с каждой html-страницы? Любая крайность -- плохо. Тут надо искать золотую середину. И будем мы ее искать вместе. Что предлагаю я. У меня уже выработалась своя техника составления древа файлов и классов. Она сильно похожа на ту, что я вам преподношу. Мы разделили функции общего назначения на три класса: vars, mysql, utils. Для удобства. Конечно, можно было их собрать в один файл и даже в один класс. Но это вы сможете сделать сами, если пожелаете. Тут никаких весомых доводов "за" или "против" привести, как мне кажется, не получится. "У каждого свой вкус: один любит арбуз, а другой -- свиной хрящик..."(с). Далее мы написали класс добавления данных. Он у нас получился небольшой, но если бы мы на самом деле писали огромный проект, то функций добавления данных и функций управления данными было бы заметно больше. Стоило ли бы, в этом случае, разнести их на подклассы? Не думаю. Я бы не стал. Почему? Объясню. Когда мы пишем систему добавления и управления данными (back office это обычно называется), то никогда до конца не можем знать, в каком виде будут поступать данные и в каких комбинациях. И если мы начнем дробить систему добавления данных на разные классы, то рано или поздно начнем наталкиваться на ситуации, когда функции из одной ветки классов будут требоваться в классах других веток. К чему это все приведет? Правильно, приведет все это к большому бардаку! Но при всем при этом, не следует забывать, что чем больше код программы, тем дольше она интерпретируется и выполняется. Универсальность, в любых ее видах, приводит к громоздкости. Как быть с этим? А очень просто. Достаточно оценить: как часто класс добавления или управления данными будет вызываться. Если это частота не превышает запроса в несколько секунд, то можно ничего не дробить на подклассы. Даже слабенький сервер спокойно обработает ваши запросы. Если же идет речь о более интенсивном использовании данного класса, но можно подумать об оптимизации. А вот класс out мы как раз будем оптимизировать, путем разнесения некоторых функций в разные классы-файлы. Как это будет выглядеть. Берем за точку отсчета class_out, в который добавим функции, требуемые для любой страницы сайта. Затем, породим от него class_out_title, в который занесем функции, вызываемые только на титульной странице сайта. От того же class_out породим еще ветвь, например, -- class_out_news, которая будет нести в себе функции, связанные с новостной страницей. И так далее. Для каждого типа страницы мы создадим свой подкласс, рожденный от общего class_out, который и будем вызывать на этих самый страницах. Я не сильно запутал вас? Надеюсь, понятно, чего таким образом добьемся? Очевидно, что при запросе пользователем одной страницы, PHP придется интерпретировать только данные, имеющие непосредственное отношение к этой самой странице. Другие классы при этом -- отдыхают. Это очевидный плюс. А есть еще и не такая очевидная польза, но реальная, как показывает жизнь. Представьте, что вы изменили функцию вывода новостей на странице. И при внесении изменений, совершили ряд синтаксических или логических ошибок. Разумеется, PHP будет ругаться на ваши ошибки, и вместо страницы сайта посетитель будет видеть ругань какого-нибудь MySQL. Но, в нашем случае, это будет видеть посетитель только новостной страницы. Все остальные страницы будут продолжать показываться корректно, пока вы чините новости. Согласитесь, это тоже важно, когда вы правите сайт "по живому", как это обычно делаю я. Кстати, ничего в этом хорошего нет -- в переделке сайта по живому, но это здорово экономит время, когда речь идет о каких-то мелочах. Ладно, хватит на сегодня. Завтра начнем писать код out_class, а вы пока осмысливайте пройденное и готовьте свои дизайны... До завтра!
|
Copyright © <LMTH>. Все материалы являются собственностью их авторов.
При перепечатывании ссылка на http://www.magaz.org/ как на источник информации обязательна. Правила использования материалов журнала |