Выводим HTML с помощью PHP

Как я уже упоминал ранее, PHP и HTML отлично работают вместе. То, что мы находимся внутри блока PHP-кода, еще не говорит о том, что мы не можем вывести на экран текст в параграфе или в жирном начертании.

Это текст, выделенный жирным."; ?>

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

Создаем первую функцию

Прежде всего, несколько слов о том, что такое функция.

Функция - это своеобразная мини-программа, которая выполняет некую полезную работу и выдает нам результат.

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

Синтаксис при создании функции следующий:

Скажем, если мы хотим написать функцию, подсчитывающую сумму чисел 10 и 5, мы можем сделать так:

Мы создаем функцию с именем sum и в ее теле указываем, что она должна вывести на экран сумму чисел 10 и 5. После этого мы вызываем функцию sum . Вызов функции по сути означает ее выполнение.

В данном примере мы не используем никаких аргументов (см. синтаксис функции выше). Что такое аргументы и для чего они нужны, мы рассмотрим непосредственно на примере. Модифицируем тот код, что у нас есть, сделав его более гибким и функциональным:

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

Теперь нам нужно просто вызвать функцию, при этом передав ей в скобках два аргумента, которые она "ожидает". Мы указываем цифры 10 и 5, в результате чего получаем 15. Передав функции sum другие числа мы, разумеется, получим другой ответ.

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

Дмитрий Науменко.

P.S. Хотите двигаться дальше в освоении PHP? Обратите внимание на премиум-уроки по различным аспектам сайтостроения, включая программирование на PHP, а также на бесплатный курс по созданию своей CMS-системы на PHP с нуля. Все это поможет вам быстрее и проще освоить этот мощный язык веб-разработки:

Понравился материал и хотите отблагодарить?
Просто поделитесь с друзьями и коллегами!

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

Используется он для создания веб-проектов. Может использоваться прямо в HTML коде. И хотя результат работы скрипта часто выводится непосредственно в браузере клиента, для работы PHP не достаточно только одного браузера. То-есть вам не получится запустить index.php файл прямо в браузере, как вы уже наверняка делали с файлом index.html. Для работы PHP сценариев и веб-страниц созданных с применением PHP потребуется веб-сервер.

Если у вас еще нет хостинг площадки для вашего сайта, тогда рекомендую поэкспериментировать с PHP сценариями на локальном сервере, предназначенном для тестирования проектов. Для организации локального сервера в операционной системе Windows (WAMP, Windows-Apache-MySQL-PHP) могут быть полезны пакеты: Денвер, XAMPP, AppServ, OpenServer и т.д. После установки этих пакетов, вы получите уже настроенный и готовый к использованию сервер, а управляться он будет через удобное меню самой программы. Также, существуют и отдельные реализации APACHE, MySQL и PHP для операционной системы Windows, но настраивать их придется уже самостоятельно через конфигурационные файлы и не будет никакого меню с галочками. Для запуска, перезапуска и остановки такого сервера можно будет использовать пакетные файлы *.bat или *.cmd (батник) с командами запуска, перезапуска или остановки служб APACHE и MySQL. Третий и самый непростой для новичка вариант — это виртуальная машина с установленной и настроенной операционной системой Linux (LAMP, Linux-Apache-MySQL-PHP). Готовые образы таких «виртуалок» часто встречаются в Интернете, так что вам могут понадобиться только знания настройки программ типа VirtualBox или VMware.

Подготовка к программированию на языке PHP для чайников

1. PHP код следует помещать в файле index.php, сам файл должен быть размещен в корневом каталоге сайта, расположенного на веб-сервере.

1. Весь код на языке PHP должен быть заключен между дескрипторами или сокращенный вариант , но веб-сервер может быть не сконфигурирован для использования сокращенного варианта такой записи, поэтому предпочтителен первый вариант.
2. Вставлен PHP код может быть в любое место HTML кода.
3. Комментирование в PHP коде осуществляется следующим образом:

1. Для того, чтобы посмотреть ваш код, откройте веб-браузер и в адресной строке введите: http://localhost/www/MyEX/index.php

Вывод данных на экран с помощью языка PHP для чайников

1. Вывод данных в окно (клиентскую область веб-браузера) с помощью PHP можно выполнить посредством оператора echo. Этот оператор позволяет вывести данные различных типов: числа, символьные строки и т.д.
2. Синтаксис оператора вывода:

1. Строковые данные заключаются в двойные или одинарные кавычки. В двойных кавычках код интерпретируется PHP. Все, что заключено в одинарные кавычки выводится без какой бы ни было интерпретации. Пример:

Пример $x кода

Пример $x кода

1. Для вывода более подробной информации о переменной, которая может понадобиться при отладке программы, служит функция var_dump(). Ее синтаксис:

1. В списке переменных указывается одно или несколько имен переменных. Эта функция ничего не возвращает. Пример:

1. Менее информативной, чем var_dump(), функцией вывода сведений о переменных является:

1. Для переменных типа «массив» эта функция выводит список вида индекс => элемент.

Переменные языка РНР для чайников

1. Переменные – контейнеры для хранения данных. Данные, сохраняемые в переменной, называют значением этой переменной.
2. Переменная имеет имя – последовательность букв, цифр и символа подчеркивания без пробелов и знаков препинания, начинающаяся обязательно с символа доллара ($), за которым должна следовать буква или символ подчеркивания.
3. Правильные имена переменных: $_tel, $tmp, $my_, $address_234_45.
4. Неправильные имена переменных: $234tel, my address, $tel:234.
5. РНР является регистро-ависимым языком относительно имен переменных и констант. Однако ключевые слова могут использоваться в любом регистре.

Типы данных языка РНР и преобразование данных для чайников

1. Для того, чтобы узнать какой тип переменной, нужно воспользоваться функцией:

1. Для явного задания типа можно воспользоваться одним из двух способов:

Константы языка PHP для чайников

1. Константой называется именованная величина, которая не изменяется в процессе выполнения программы (скрипта).
2. В отличие от переменных, вы не можете изменять значения констант, которые были им присвоены при их объявлении. Константы удобно использовать для хранения значений, которые не должны изменяться во время работы программы. Константы могут содержать только скалярные данные (логического, целого, плавающего и строкового типов).
3. В РНР константы определяются функцией define(). Вот ее синтаксис:

$name — имя константы.
$value — значение константы.
$case_sen — необязательный параметр логического типа, указывающий, следует ли учитывать регистр букв (true) или нет (false).

Define("pi",3.14,true); echo pi; //Выводит 3.14

1. Для проверки существования константы можно использовать функцию defined(). Данная функция возвращает true, если константа объявлена. Пример:

Различия между константами и переменными в языке PHP для чайников

1. У констант нет приставки в виде знака доллара ($).
2. Константы можно определить только с помощью функции define(), а не присваиванием значения.
3. Константы могут быть определены и доступны в любом месте без учета области видимости.
4. Константы не могут быть определены или аннулированы после первоначального объявления.
5. Константы могут иметь только скалярные значения.

Программирование на языке PHP для чайников. Часть 1 was last modified: Март 3rd, 2016 by Admin

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

Очень часто создание и вывод сообщений разнесены по разным HTTP-запросам. Как правило, удобно бывает использовать редирект после обработки форм (чтобы избежать проблем с кнопками Back и Refresh), но в то же время естественный момент для создания сообщения - это именно момент обработки форм и совершения действий, ему сопутствующих. Почему? Представьте, что текст сообщения должен выглядеть примерно так: "Количество заказываемых единиц товара ‘Коврик для мыши’ успешно изменено с 7 до 12". После редиректа, возможно, на совершенно другую с точки зрения функциональности страницу, это будет лишняя головная - определить, что же было совершено до этого.

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

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

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

Итак, имеем проблему - сообщение должно "жить" в разных запросах. Нам нужен механизм передачи текста сообщения на страницу, которая должна его выводить. Вы уже, наверное, вспомнили про сессии.

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

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

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

class Message { /** * Содержание сообщения. */ var $content; /** * Конструктор для инициализации текста сообщения. * * @param content содержание сообщения */ function Message($content) { $this->content = $content; } /** * Запись сообщения в сессию. */ function send() { $_SESSION["session_messages"] = $this->content; } /** * Вывод сообщения на страницу. */ function toPage() { echo " - " . $this->content . "
"; } }

Для доступа к сессии используется переменная $_SESSION.

Замечу, что $_SESSION - это массив, мы используем всего лишь один элемент этого массива с индексом ‘session_message’.

В данном случае имеем дело с "массивом массивов" - то, что мы храним в элементе ‘session_message’, представляет собой массив, это и есть список передаваемых сообщений (их, конечно, может быть несколько).

Если вы не смогли нащупать нить, самое время освежить в памяти разделы мануала, посвященные сессиям и массивам.

У вас может возникнуть вопрос. А зачем здесь нужны классы? Вполне можно было бы обойтись двумя функциями. Но давайте заглянем дальше. Нам может понадобиться создавать сообщения с различными типами (info, error, warning), определять адресатов сообщений.

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

Представим, что мы бы это делали с помощью функций. Наверное, у нас была бы функция message_send($txt), еще была бы функция message_to_page($txt). Теперь надо добавить возможность различного поведения для различных видов сообщений. Вызовы функций меняются: message_send($txt, $kind), message_to_page($txt, $kind). Придется прочесать весь код приложения в поисках таких функций, делая исправления.

Этого можно избежать, заранее предвидя ситуацию, представив сообщение в виде ассоциативного массива: $msg[‘txt’], $msg[‘kind’], тогда в вызовах функций будет только один параметр. Чувствуете, как это стремится превратиться в класс?

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

Следующий класс - Inbox - как раз для этого и предназначен.

class Inbox { /** * Массив поступивших сообщений. */ var $messages = array(); /** * В конструкторе получаем все поступившие сообщения * и удаляем их из сессии. */ function Inbox() { if (is_array($_SESSION["session_messages"])) { $messages = $_SESSION["session_messages"]; $co = sizeof($messages); for ($i = 0; $i < $co; $i++) { $this->messages = new Message($messages[$i]); } } /* очищаем массив сообщений */ $_SESSION["session_messages"] = array(); } /** * Выводим на страницу содержимое Inbox. */ function toPage() { $co = sizeof($this->messages); if ($co > 0) { echo "Сообщение от системы:
"; } for ($i = 0; $i < $co; $i++) { $this->messages[$i]->ToPage(); } } }

Давайте испытаем нашу систему сообщений.

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

send(); /* перенаправление на себя же */ header("location:"); } else { $inbox = new Inbox(); $inbox->toPage(); } ?>

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

Создайте каталог на веб-сервере, затем создайте в нем эти три файла и попробуйте скрипт в работе. Заметьте, проблем с кнопками Back и Refresh не возникает.

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

Здесь мы встречаем два затруднения:

* Хотелось бы, чтобы список сообщений появлялся в определенной части страницы, и вы уже подобрали хорошее местечко для этого.
Проблема в том, что надо запустить команду $inbox->toPage() именно в тот момент, который бы соответствовал положению списка сообщений на странице. Если мы захотим поменять положение этого списка, придется лезть в код, но нехорошо постоянно для этого изменять каркас портала. Наилучшим решением было бы сделать вывод сообщений в виде отдельного модуля, о котором известно лишь только, что его надо подключить к каркасу.
То есть освободиться от строгой последовательности запуска модулей. Действительно, раз результат работы вывода Inbox не зависит от работы системы (на данном шаге - все данные у нас уже есть в сессии), то зачем лишние сложности?
* Чтобы поддерживать внешний вид (дизайн) списка сообщений надо заботиться об HTML-коде, который у нас зашит в методах toPage() классов Message и Inbox. Как правило, придется изменять PHP-код для того, чтобы изменить дизайн.

Чтобы попытаться решить первую проблему, можно создать буфер, в котором бы хранился результат работы вывода Inbox.

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

Уже эта попытка решения дает нам идею использовать XML как средство хранения промежуточных данных. А использование стилей XSLT поможет справиться и со втором проблемой.

Я не буду останавливаться на том, что такое XML, и что такое XSLT. Если вы не знакомы с этими вещами, zvon.org станет хорошей отправной точкой для изучения.

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

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

minute 57 second: 45

Что это такое - догадаться довольно просто - два сообщения и форма. Заметьте, PHP-скрипт должен подготовить только такой стринг - он очень простой. Причем порядок следования основных тегов неважен - можно поставить вначале, например, как будет удобно программисту. Как это реализовать. Можно, почти ничего не меняя, использовать output buffering, вместо HTML-кода выводить XML, а в конце просто захватить вывод в стринг. Но тогда мы потеряем в гибкости - например, хочется иногда выводить отладочную информацию прямо на страницу (с помощью echo). В то же время, разработчики PHP работают над DOM-модулем, который предлагает более продвинутый способ создания и передачи древовидных документов. Если мы захотим внедрить DOM, то придется перекраивать все приложение, изменяя вывод стрингов на создание DOM-элементов. Поэтому я предпочитаю хранить XML-представление объектов внутри самих объектов, последовательно собирая общий XML-документ. Это не так сложно, нужна всего лишь небольшая модификация. Вы увидите, что такой прием не привязан жестко к конкретному способу хранения XML-данных, и это позволит совершить переход к использованию DOM "малой кровью". Прежде всего заметим, что у каждого нашего объекта есть метод toPage(). Эта похожесть должна нас заставить задуматься о том, чтобы ввести новый общий родительский класс. Пусть каждый класс, который способен создавать кусочки XML-документа для страницы, будет наследоваться от класса, который будет заботиться об XML-представлении объекта. Назовем его Outputable.

class Outputable { /** * XML контейнер (стринг). */ var $output = ""; /** * Отдать содержимое контейнера и очистить контейнер. * * @return стринг с XML-данными */ function getOutput() { $out = $this->output; $this->output = ""; return $out; } /** * Добавить порцию к содержимому контейнера. * * @param string добавляемый стринг */ function appendOutput($string) { $this->output .= $string . "n"; } /** * "Абстрактный" метод. */ function toPage() { } }

Метод toPage() сделан пустым - в данном случае он нужен как индикатор того, как должны внешние "матрешки"-классы общаться с внутренним классом. Впрочем, здесь можно было бы предложить реализацию по умолчанию, если бы мы заметили, что есть много объектов, которые одинаково выводят себя на страницу.

Классы Message и Inbox несколько изменятся - теперь оба они должны наследоваться от Outputable, а также изменятся и методы toPage()
Message.php

class Message extends Outputable { /** * Содержание сообщения. */ var $content; /** * Конструктор для инициализации текста сообщения. * * @param content содержание сообщения */ function Message($content) { $this->content = $content; } /** * Запись сообщения в сессию. */ function send() { $_SESSION["session_messages"] = $this->content; } /** * Вывод сообщения на страницу. */ function toPage() { $this->appendOutput("".$this->content.""); } }

class Inbox extends Outputable { /** * Массив поступивших сообщений. */ var $messages = array(); /** * В конструкторе получаем все поступившие сообщения * и удаляем их из сессии. */ function Inbox() { if (is_array($_SESSION["session_messages"])) { $messages = $_SESSION["session_messages"]; $co = sizeof($messages); for ($i = 0; $i < $co; $i++) { $this->messages = new Message($messages[$i]); } } /* очищаем массив сообщений */ $_SESSION["session_messages"] = array(); } /** * Выводим на страницу содержимое Inbox. */ function toPage() { $co = sizeof($this->messages); $this->appendOutput(""); for ($i = 0; $i < $co; $i++) { $this->messages[$i]->toPage(); $this->appendOutput($this->messages[$i]->getOutput()); } $this->appendOutput(""); } }

Изменился способ вывода - теперь вместо непосредственного вывода на страницу внешнее представление до поры до времени хранится в Outputable, который "сидит" в каждом из объектов. Метод appendOutput() служит некоторой заменой конструкции echo(). Чтобы забрать вывод объекта, используется метод getOutput().

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

send(); /* текущая секунда */ $msg_sec = new Message("second: " . date("s")); $msg_sec->send(); /* перенаправление на себя же */ header("location:"); exit; } else { /* подготавливаем список сообщений в виде XML */ $inbox = new Inbox(); $inbox->toPage(); $global_content->appendOutput($inbox->getOutput()); } $global_content->appendOutput(""); $xml_string = $global_content->getOutput(); $xh = xslt_create(); $xarg = array(); /* заголовок XML-документа */ $xarg["xml"] = ""."n"; /* тело XML-документа */ $xarg["xml"] .= "" . $xml_string . ""; /* XSL-шаблон */ $xarg["xsl"] = implode("", file("style.xsl")); /* выводим HTML-код - результат XSL-трансформации */ echo xslt_process($xh, "arg:xml", "arg:xsl", NULL, $xarg); /* выводим XML-исходник (debug) */ echo "

" . htmlspecialchars($xml_string) . "

Главное новшество - в объекте $global_content, название которого говорит само за себя. В данном случае он принадлежит классу Outputable, в реальных задачах вы, наверное, создадите отдельный класс для контента страницы.

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

Для того, чтобы посмотреть на результат, осталось только подготовить XSL-шаблон.
style.xsl

Чего же мы добились?

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

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

Еще одно преимущество - легкость отладки. Если вы запустите скрипт, то заметите, что на каждой странице присутствует debug-вывод - XML-прообраз, который здорово упрощает отладку приложений.

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

Напоследок, галопом о перспективах:

* всплывающие окна для списка важных сообщений
* "страницы-отправители" и "страницы-адресаты" в сообщениях
* ведение лога сообщений в базе данных
* кнопка "показать историю моих действий"
* статистический анализ действий пользователей в пределах сессий
* "интеллектуальные помощники" в веб-приложениях

См. «Обновления» в конце:

Текущая база кода имеет 1.4k-строку чисто процедурного кода, который отправляет sms (имеет бизнес-логику, db-связь и все в одном гигантском, if условно вложенное бесчисленное множество, if s, никаких функций, полных литералов, подлинного кандидата DailyWTF?). И я решил укусить пулю и переписать всю чертову с нуля.
Дело в том, что это будет мой первый опыт ООП. Я читал как можно больше об OOD и о хорошей практике и решил начать с чего-то простого. Я хочу реализовать отправку / получение сообщений (в основном текст / SMS, но MMS, электронная почта должны быть включены в будущем). Поэтому я написал следующее в качестве своего первого сообщения

Я не думаю, что правильно применяю концепцию полиморфизма. Я чувствую, что if бы не было, верно? Возможно, они необходимы для setContent() но как насчет sendMessage() ? Поэтому я подумал, что отделив отправляющую часть в свой class SendMessage implements SendMessageInterface . который будет иметь свои собственные переменные для $server, $protocol и методов для отправки электронной почты и текста и т. д. Но при написании этого класса я понял, что if s снова ползут, как if($msg->getType() == "text") условные обозначения. Чтобы добавить к этому, я создаю новый класс, который отделяет часть действия моего объекта, который меня путает (например, class door должна отвечать за реализацию методов close() и open()).

Теперь либо я принимаю, что if всегда будет там (что, похоже, побеждает всю цель полиморфизма), или я должен делать что-то неправильно .
С точки зрения пользователя, я представляю себе что-то вроде:

$msg = new Message(); $msg->setType("email"); //or "text" or "mms" etc. $msg->setContent($content); //eg $content=array("subject"=>"foo","body"=>"bar") $msg->sendMessage(); //if the last line is not possible, then perhaps //$sender = new SendMessage($msg); //$sender->send();

что мне здесь не хватает? невозможно достичь $msg->sendMessage(); ? Должны ли / нужны ли мне разные классы сообщений (MessageEmail , MessageText и т. Д.)? Должен ли я отделить SendMessage (и, возможно, иметь $msg->sendMessage(); называть его?)

// и это когда я даже не думал о получении сообщения ! Боже, помоги мне!! 🙁

Обновление 15 августа 2011 года. Подумав обо всех аспектах текущей базы кода, я определил следующие части, которые мне нужно будет реализовать. a. Message Class(es) (type, content, sender, receiver, DateTime of send/receive etc.) Responsibilities: creating and modifying messages ascribing consistent and appropriate characteristics of a message b. Send Class(es) (protocol, header info, server/operator to use) Responsibilities: Sending messages Changing the state of Message (for setting send DateTime of Message) e. Database Class(es) (id, content, to, from, time etc.) Responsibilities: Represent Message for storage. CRUD (Create, Read, Update, Delete) actions on this representation for DBMS. e. Interfaces (MAX_MESSAGE_LENGTH, TIMEOUT etc.) Responsibilities: Provide interface for communication between various modules.

Я считаю, что моя основная причина путаницы заключалась в смешивании интерфейсов с полиморфизмом (см. Комментарий). Как вы оцениваете это?

Обновление 16 августа 2011 г.
В основном я использовал интерфейсы, чтобы навязывать функциональность. Вот краткая версия файла interface. interface MessageInterface { //omitting getters for clarity public function setType($type); public function setSender(IdentityInterface $sender); public function setReceiver(IdentityInterface $receiver); public function setSendGateway(GatewayInterface $sendGateway); } interface IdentityInterface { public function setName($name); public function setAddress($address); } interface GatewayInterface { public function setProtocol($protocol); public function send(IdentityInterface $sender, IdentityInterface $receiver, ContentInterface $content); }

(нет причудливых вещей, поскольку я еще не интегрировал class GatewaySMPP implements GatewayInterface в мой основной класс Message который выглядит так:

Class Message implements MessageInterface { private $_type; private $_content; private $_sender; private $_receiver; private $_sendGateway; //private $_receiveGateway; private $_dataStorage; public function __construct($type = NULL, $content = NULL, IdentityInterface $sender = NULL, IdentityInterface $receiver = NULL, GatewayInterface $sendGateway = NULL) { $this->setType($type); $this->setContent($content); ($sender === NULL) ? $this->setSender(new Identity()) : $this->setSender($sender); ($receiver === NULL) ? $this->setReceiver(new Identity()) : $this->setReceiver($receiver); //similarly for $setSendGateway etc. } //setters and getters, omitting for clarity public function send(...) { //testing pending $this->_sendGateway->send($this->getSender(), $this->getReceiver(), $this->getContent ...) }

Интересной частью было внедрение GatewaySMPP, которое включало множество операций сокета и проверку ответов. Мне просто нужно написать public function send() обёртки public function send() вокруг private function _send{PDU,SM} .

Хотя я думал об интеграции GatewaySMPP, я понял, что буду открывать / закрывать сокеты для соединения SMPP для каждой операции отправки сообщений. Это нормально для упражнений / тестирования, но на практике мне кажется, что мне может понадобиться изменить мою логику, чтобы использовать существующее соединение. Вопрос в том, как? Вот текущая логика:

Class GatewaySMPP { private $_socket,$_port,$_host //etc. public function __construct($host,$port,$user,$passwd) { $this->_socket = FALSE; $this->_host = $host; //initialize other private variables } public function init() { if($this->_socket !== FALSE) return FALSE; //socket already in use $this->_socket = fsockopen($this->_host, $this->_port ...) //prepare bind statement for initiating SMPP connection and fwrite to socket $this->_sendPDU(BIND, $data) } public function send($receiver, $sender, $message, ...) { //use private functions which do actual socket operations $this->_sendSM($receiver, $sender, $message, ...) } public function end() { if($this->_socket === FALSE) return; //socket already closed this->_sendPDU(UNBIND, ""); //omitting response check $result = fclose($this->_socket); //omitting response check }

Q. Проблема, с которой я столкнулся, состоит в том, что каждый объект GatewaySMPP будет иметь свой собственный $ _socket, поэтому я подумал о том, чтобы сделать singleton (содрогание ) GatewaySMPP или использовать какую-либо переменную global / state для отслеживания сокетов для повторного использования. Лучшая идея, которая приходит мне на ум, заключается в том, что потребитель этих классов использует следующую логику. 1. Создайте и используйте одиночный $objGatewaySMPP для всех $objectMessage 2. objGatewaySMPP->init(); 3. foreach($objMessage as $msg) $msg->send(); 4. objGatewaySMPP->end(); , Это все еще оставляет проблему одновременных вызовов разных пользователей класса? Предложения / комментарии, пожалуйста.

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

sendService = $sendService; } public function send($recipient) { $this->sendService->send($recipient, $this); } } class EmailMessage extends Message { private $subject; private $header; //setters and getters / maybe a constructor } class SMSMessage extends Message { private $from; //setters and getters / maybe a constructor } //Services for sending messages interface SendService { function send(Recipient $recipient, $message); } class EmailSendService implements SendService { function send($recipient, EmailMessage $message){ // you can use only the attributes from the recipient that you need (email address) // you can be sure that the message has a header and a subject because you are enforcing // the type allowed to be passed to this function // do email sending stuff } } class SMSSendService implements SendService { function send($recipient, SMSMessage $message){ // you can use only the attributes from the recipient that you need (tel number) // do sms sending stuff } } // Defines a "user" that can be used for both messge types class Recipient { private $email; private $tel; private $name; //setters and getters } // how you would use the above // 1 - set up recipient - in the real world you would probably have something that would provide this // to you, like a database lookup $recipient = new Recipient(); $recipient->setEmail("[email protected]"); $recipient->setName("Herp Derp"); $recipient->setTel("07770000000000"); // 2 - get a service for sending your message $sendService = new SMSSendService(); // 3 - create your message by passing it a service which it can use to send itself $message = new SMSMessage($sendService); // 4 - set attributes of your message and then send (passing a recipient to send to) $message->setContent("lorem ipsum herp derp doop"); $message->send($recipient);

С интерфейсами вы можете сделать это без расширения другого класса. И это здорово.

Я попробую сказать в коде (потому что мой английский хуже, чем мой PHP)

to = $to; $this->subject = $subject; $this->content = $content; } public function Send() { mail($this->to, $this->subject, $this->content); } } class SMS implements IMessage { private $num; private $from; private $message; public function __construct($num, $message, $from = "") { $this->num = $num; $message = substr(trim($message), 0, 140); $from = empty($from) ? $num: $from; } public function Send() { //... } }

Учитывая, что метод setContent будет использоваться только для текстовых типов (ну, я полагаю, это потому, что вы выполняете условную проверку), кажется логичным разбить класс каким-то образом, возможно, на базовое слово Message и SMSMessage ala SMSMessage и MMSMessage . В SMSMessage вы можете определить SetContent() а затем, возможно, AttachImage() например, для MMSMessage . Другим подходом является определение SetContent() как абстрактного в сообщении базового класса, а затем принуждение наследователей определять этот метод – то есть, если вы планируете сделать некоторую логику в этом методе.

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

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