См. «Обновления» в конце:
Текущая база кода имеет 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(); , Это все еще оставляет проблему одновременных вызовов разных пользователей класса? Предложения / комментарии, пожалуйста.
Может быть, попробуй что-нибудь подобное. Это быстрая попытка, но вы всегда должны стараться минимизировать дублирование кода.
В отличие от других программ написанных на других языках типа Perl и.т.д.
РНР называют языком серверных скриптов в отличие от JavaScript Vbscript. Которые являются языком клиентских скриптов. Это означает, что РНР-скрипт выполняется на сервере, а клиенту передается результат его работы, тогда как JavaScript полностью передается на клиентскую машину и там выполняется браузером.
1- РНР это часто используемый язык скриптов, которая была разработана в первую очередь для веб-программистов, и предназначена для создания динамических страниц.
2 — Когда РНР анализирует файл, тогда едет чтения содержания до тех пор пока не встретится один из специальных операторов (тег открытия ) После чего продолжается чтение кода. Таким образом РНР можно ввести в любой момент в любой код HTML.
3 — Обязательным правилом создания кода РНР является,
строка должна обязательно закрываться «,»
название функции не чувствительны к регистру (неважно СИЖ использованием больших или маленьких букв)
имена переменных чувствительны к регистру (разница между использованием больших и маленьких букв)
скобки используются двойные «» или одинарные » (использование таких вариантов «» или «» будет ошибкой)
код РНР ограничен одним из следующих Нобору тегу открытия и закрытия
Сообщение "Hello world!" выводится в заголовке web-страницы. Интересно то, что команда print внутри конструкции, которая обычно называется экранирующими последовательностями PHP (), представляет собой законченную программу. Ни длинного кода инициализации, ни включения библиотек -- программа состоит лишь из того кода, который непосредственно решает поставленную задачу!
Конечно, для выполнения сценариев PHP необходимо предварительно установить и настроить программное обеспечение PHP на сервере. Этот процесс описан в разделе «Загрузка и установка PHP/Apache» настоящей главы. Разделу предшествуют фрагменты из отзывов нескольких пользователей, выступающих в пользу PHP, с кратким обзором языка и его истории. Но прежде чем браться за процесс установки, мы познакомимся с некоторыми характеристиками PHP. Этой теме посвящен следующий раздел.
Характеристики PHP
Как вы, вероятно, уже поняли, главным фактором при проектировании языка PHP является практичность. PHP должен предоставить программисту средства для быстрого и эффективного решения поставленных задач. Практический характер PHP обусловлен пятью важными характеристиками:
- традиционностью;
- простотой;
- эффективностью;
- безопасностью;
- гибкостью.
Существует еще одна «характеристика», которая делает PHP особенно привлекательным: он распространяется бесплатно!
ТрадиционностьЯзык PHP кажется знакомым программистам, работающим в разных областях. Многие конструкции языка позаимствованы из Си Perl, а нередко код PHP практически неотличим от того, что встречается в типичных программах С или Pascal. Это заметно снижает начальные усилия при изучении PHP.
ПростотаСценарий PHP может состоять из 10 000 строк или из одной строки -- все зависит от специфики вашей задачи. Вам не придется подгружать библиотеки, указывать специальные параметры компиляции или что-нибудь в этом роде. Механизм PHP просто начинает выполнять код после первой экранирующей последовательности (). Если код имеет правильный синтаксис, он исполняется в точности так, как указал программист.
ЭффективностьЭффективность является исключительно важным фактором при программировании для многопользовательских сред, к числу которых относится и WWW. В PHP 4.0 был реализован механизм выделения ресурсов и обеспечена улучшенная поддержка объектно-ориентированного программирования, а также средства управления сеансом. В последней версии появился и механизм подсчета ссылок (reference counting), предотвращающий выделение лишней памяти.
БезопасностьPHP предоставляет в распоряжение разработчиков и администраторов гибкие и эффективные средства безопасности, которые условно делятся на две категории: средства системного уровня и средства уровня приложения.
Средства безопасности системного уровня
В PHP реализованы механизмы безопасности, находящиеся под управлением администраторов; при правильной настройке PHP это обеспечивает максимальную свободу действий и безопасность. PHP может работать в так называемом безопасном режиме (safe mode), который ограничивает возможности применения PHP пользователями по ряду важных показателей. Например, можно ограничить максимальное время выполнения и использование памяти (неконтролируемый расход памяти отрицательно влияет на быстродействие сервера). По аналогии с cgi-bin администратор также может устанавливать ограничения на каталоги, в которых пользователь может просматривать и исполнять сценарии PHP, а также использовать сценарии PHP для просмотра конфиденциальной информации на сервере (например, файла passwd).
Средства безопасности уровня приложения
В стандартный набор функций PHP входит ряд надежных механизмов шифрования. PHP также совместим с многими приложениями независимых фирм, что позволяет легко интегрировать его с защищенными технологиями электронной коммерции (e-commerce). Другое преимущество заключается в том, что исходный текст сценариев PHP нельзя просмотреть в браузере, поскольку сценарий компилируется до его отправки по запросу пользователя. Реализация PHP на стороне сервера предотвращает похищение нетривиальных сценариев пользователями, знаний которых хватает хотя бы для выполнения команды View Source.
Тема безопасности настолько важна, что ей посвящена целая глава. За подробной информацией о средствах безопасности PHP обращайтесь к главе 16.
ГибкостьПоскольку PHP является встраиваемым (embedded) языком, он отличается исключительной гибкостью по отношению к потребностям разработчика. Хотя PHP обычно рекомендуется использовать в сочетании с HTML, он с таким же успехом интегрируется и в JavaScript, WML, XML и другие языки. Кроме того, хорошо структурированные приложения PHP легко расширяются по мере необходимости (впрочем, это относится ко всем основным языкам программирования).
Нет проблем и с зависимостью от браузеров, поскольку перед отправкой клиенту сценарии PHP полностью компилируются на стороне сервера. В сущности, сценарии PHP могут передаваться любым устройствам с браузерами, включая сотовые телефоны, электронные записные книжки, пейджеры и портативные компьютеры, не говоря уже о традиционных PC. Программисты, занимающиеся вспомога-тельными утилитами, могут запускать PHP в режиме командной строки.
Поскольку PHP не содержит кода, ориентированного на конкретный web-сервер, пользователи не ограничиваются определенными серверами (возможно, незнакомыми для них). Apache, Microsoft IIS, Netscape Enterprise Server, Stronghold и Zeus -- PHP работает на всех перечисленных серверах. Поскольку эти серверы работают на разных платформах, PHP в целом является платформенно-незави-симым языком и существует на таких платформах, как UNIX, Solaris, FreeBSD и Windows 95/98/NT.
Наконец, средства PHP позволяют программисту работать с внешними компонентами, такими как Enterprise Java Beans или СОМ-объекты Win32. Благодаря
этим новым возможностям PHP занимает достойное место среди современных технологий и обеспечивает масштабирование проектов до необходимых пределов.
Бесплатное распространениеСтратегия Open Source наделала немало шуму в программной отрасли. Распространение исходных текстов программ в массах оказало несомненно благотворное влияние на многие проекты, в первую очередь -- Linux, хотя и успех проекта Apache сильно подкрепил позиции сторонников Open Source. Сказанное относится и к истории создания PHP, поскольку поддержка пользователей со всего мира оказалась очень важным фактором в развитии проекта PHP.
Принятие стратегии Open Source и бесплатное распространение исходных текстов PHP оказало неоценимую услугу пользователям. Вдобавок, отзывчивое сообщество пользователей PHP является своего рода «коллективной службой поддержки», и в популярных электронных конференциях можно найти ответы даже на самые сложные вопросы.
«Мы в течение долгого времени поддерживали личные контакты с некоторыми разработчиками PHP и вели с ними обширную переписку. Когда у разработчиков PHP возникали какие-то проблемы, относящиеся к MySQL, мы всегда были готовы помочь им в поиске решения. Кроме того, мы включили в MySQL несколько новых возможностей лишь для того, чтобы улучшить его интеграцию с PHP. Результатом наших усилий стало то, что MySQL превосходно работает с PHP, -- и мы позаботимся о том, чтобы это положение сохранилось и в будущем!»
Майкл «Монти» Видениус (Michael «Monty» Widenius),
«Выбор PHP для реализации mp3.lycos.com был обусловлен несколькими причинами. Главной причиной стали сжатые сроки работы над проектом -- ведь PHP ускоряет процесс разработки. Другой причиной была высокая эффективность -- мы перешли от 0 к 1,4 миллиона посещений в сутки, и PHP с этим прекрасно справился. Третья причина заключалась в том, что я твердо знал: если на стадии тестирования с повышенной нагрузкой в PHP обнаружатся какие-либо ошибки, я смогу их самостоятельно исправить, поскольку PHP распространяется вместе с исходными текстами».
Стиг Баккен (Stig Bakken),
«Я использовал PHP с первых дней, еще с версии PHP/FI 1.x. Мне понравилось, что я могу обрабатывать формы и настраивать страницы «на ходу» при помощи такого простого языка. Вместе с потребностями моей компании развивался и PHP.
В наши дни PHP обладает исключительно богатыми возможностями. Мы используем его практически во всех создаваемых web-сайтах, включая 32bit.com и DevShed.com. Мы даже воспользовались им в Info West для реализации службы поддержки, управления учетными записями и отслеживания портов.
Эволюция PHP и признание его мировым сообществом -- классический пример успешного ведения проекта с открытыми исходными текстами. Широта взглядов создателей, поддержка сообщества и хорошее сопровождение кодовой базы привели PHP к успеху, о котором многие коммерческие проекты могут лишь мечтать. Я с оптимизмом смотрю в будущее PHP и рекомендую каждому web-разработчику попробовать его в деле. Возможно, вы, как и я, уже не расстанетесь с ним».
Рэнди Косби (Randy Cosby),
Вводный примерПример, приведенный в листинге 1.1, наглядно показывает, как легко PHP интегрируется с HTML-кодом.
Листинг 1.1. Создание динамической страницы PHP
// Присвоить значения нескольким переменным
$site_title = "PHP Recipes";
$bg_color = "white";
$user_name = "Chef Luigi";