Где-то полтора года назад я начал заниматься web разработкой. Начинал с функционального программирования. Примерно пол года назад я перешел на ООП и стал использовать MVC архитектуру проектирования. Недавно появилась задача оптимизировать работу с базой данных, т. к. вся связь и работа с базой осуществлялась через один класс. Это было неудобно потому, что все время приходилось вручную писать SQL — запросы. Читать полностью »
Метка «ооп» - 7
Генератор SQL запросов на PHP
2012-10-09 в 17:27, admin, рубрики: model, mvc, php, sql, ооп, метки: model, mvc, PHP, sql, оопФункциональное программирование в ООП
2012-10-08 в 14:08, admin, рубрики: clean code, ооп, Проектирование и рефакторинг, Совершенный код, функциональное программирование, метки: clean code, ооп, функциональное программированиеДумаю, никто не станет спорить, что хороший код — код, который не только исполняет, но и максимально описывает свою задачу (это, конечно, относится в первую очередь к бизнес-логике). Причем описывает ее не деталями алгоритма, а своей сигнатурой (названием, параметрами и возвращаемым типом), сигнатурой вызываемых методов, переменными, которые он использует. В таком случае тело метода можно прочитать сверху вниз, не удерживая в памяти какой-то дополнительный контекст.Читать полностью »
Как два программиста хлеб пекли
2012-10-03 в 5:46, admin, рубрики: KISS, ооп, Программирование, метки: kiss, ооп 
Я работаю программистом уже много лет, на протяжении которых, как это ни странно, я всё время что-то программирую. И вот какую интересную вещь я заметил: в коде, написанном мной месяц назад, всегда хочется что-то чуть-чуть поправить. В код полугодичной давности хочется поменять очень многое, а код, написанный два-три года назад, превращает меня в эмо: хочется заплакать и умереть. В этой статье я опишу два подхода. Благодаря первому архитектура программы получается запутанной, а сопровождение — неоправданно дорогим, а второй — это принцип KISS.
Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.
Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.
Именно так, «делался», без уточнения способа производства.
Как же поступят наши программисты?Читать полностью »
Переопределение предка (dirty hack)
2012-09-27 в 11:31, admin, рубрики: dirty hack, hook, php, ооп, метки: dirty hack, hook, PHP, ооп Иногда очень хочется переопределить поведение класса родителя, не меняя его код.
К примеру поменять место хранения шаблонов из файлов в базу… или добавить кэширование…
или заменить в ORM удаление записей на пометку их как удаленные…
Да мало ли что мы можем пожелать изменить…
Если каждый программист будет лезть в ядро фреймворка или просто в чужой код, то это будет каша.
У этой задачи есть множество решений. Я хочу предложить то, которое мне нравится больше всего.
Решение основано на __autoload() а точнее на spl_autoload_register.
Читать полностью »
Генераторы vs классы
2012-09-03 в 18:23, admin, рубрики: python, генераторы, классы, ооп, оптимизация, метки: python, генераторы, классы, ооп, оптимизация Очень маленький пост о том, что выбрать: генератор или класс, когда реализация возможна обеими способами.
Читать полностью »
Zend Framework, субъективные впечатления
2012-09-03 в 12:22, admin, рубрики: mvc, php, Zend Framework, велосипедостроение, ооп, метки: mvc, PHP, zend framework, велосипедостроение, оопНедавно мне было поручено разработать некое веб-приложение. Не буду вдаваться в подробности, а лишь скажу, что приложение связанно с планированием перевозок. Есть общедоступная часть, воспользоваться которой может любой посетитель сайта. Есть внутренние интерфейсы для операторов системы. Есть информеры для размещения на сторонних сайтах. С технической точки зрения это несколько десятков экранов, множество различных форм, табличек. Часть экранов используют ajax, кастомные компоненты, написанные на javascript, и всякие красивости типа drag-and-drop. Данные, как обычно, хранятся в реляционной БД в виде полутора десятков таблиц. В общем не совсем примитивное приложение, но и очень сложным назвать его тоже не могу.
По работе мне, мне достаточно часто приходится проектировать или лично кодить подобные приложения. Однако в данном проекте было одно важное требование. Приложение должно быть разработано на базе серьезной и проверенной платформе, а именно на Zend Framework. Использование самописных “велосипедов” — недопустимо. Скажу честно, опыта реальной работы с Zend Framework у меня до сих пор не было. Но платформа известная и за ней стоит известный разработчик. Многими разработчиками Zend Framework вообще рассматривается как стандарт веб разработки. Так что, тем более, есть повод освоить что то новое и солидное. Поэтому я с энтузиазмом взялся за этот проект.
Читать полностью »
Протофабрика на php, или как не зависеть от фреймворка
2012-08-27 в 9:03, admin, рубрики: autoload, php, Веб-разработка, ооп, фабрика, фреймворки php, метки: autoload, PHP, ооп, фабрика, фреймворки php Из-за того, что приходится использовать различные фреймворки, но писать, по сути, одно и то же рано или поздно начинает преследовать дежавю. Для php это особенно актуально, часто приходится как выбирать платформу под заказчика, так и допиливать уже имеющийся проект. Вроде бы, нет ничего проще — написал один раз код и таскай его за собой. Но различные API и организация файлов не дают это сделать естественным образом. Очевидное решение — организация своего «багажа» в виде классов. Тогда конкретное приложение (модуль, компонент) как раз будут связывать API фреймворка (или CMS) с вашим классом. Проблема организации файлов имеет также вроде бы очевидное решение — инклудишь нужный класс и всё. Но не зря же все активно пользуются различными фреймворками, а не пишут все с нуля — лучше сосредоточиться на новых задачах, а не думать как «подцепить» уже готовое. Посему я и написал небольшой класс, фабрику-загрузчик.
Читать полностью »
AMatch, часть 2. Коды ошибок, собственные ошибки, новый формат callback
2012-08-22 в 14:32, admin, рубрики: amatch, pattern matching, php, validation, ооп, Программирование, метки: amatch, pattern matching, PHP, validation, оопВ этой статье я расскажу о некоторых новшествах, появившихся в проекте AMatch с момента написания первой статьи.
Напомню, что AMatch — класс, с помощью которого валидация входных параметров из большого набора if-ов превращается в удобную, лаконичную запись. К примеру:
Example: simple
$match = AMatch::runMatch($params)
->doc_id(0, '<') // Левое значение меньше
->subject_id(0, '!=') // Не равен нулю
;
$result = $match->stopMatch();
if (!$result) {
die(var_export($match->matchComments(), true)); // для наглядности умрём
}
Почему все работают с ООП? Кратко о главном или «пища» для размышления
2012-08-22 в 13:40, admin, рубрики: php, ооп, Программирование, метки: PHP, оопНе знаю пока, зачем и почему первым постом я выбрал именно этот. Да я прекрасно понимаю, что из этого поста я получу много отрицательных комментариев и возможно карма будет неизбежно испорчена, но будем надеяться оно того стоит.
На что хотелось бы обратить Ваше внимание, что я не хочу никого переубеждать или менять точку зрения. Этот пост, как и звучит в заголовке, просто заставит Вас задуматся.
В этот же момент я пропишу немного материала, которая позволит исключить часть негатива, который вызывает данный пост в истинных ООП-ков.
Читать полностью »
Я, наверное, знаю ООП. Опыт объектно-ориентированного программирования и дизайна. Ответ «не знающим ООП.»
2012-08-06 в 8:24, admin, рубрики: java, абстрагирование, инкапсуляция, интерфейсы, наследование, ооп, Программирование, проектирование, проектирование взаимодействия, проектирование интерфейсов, метки: абстрагирование, инкапсуляция, интерфейсы, наследование, ооп, проектирование, проектирование взаимодействия, проектирование интерфейсовПосле появления статей типа "Я не знаю ООП" — возникает желание внести ясность, «сорвать покровы» и «докопаться до истины».
Принципы объектно-ориентированности
Обычно выделяют (читай: на собеседовании требуют назвать) четыре «принципа объектно-ориентированного программирования»: абстракцию, инкапсуляцию, наследование и полиморфизм.
На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта — некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного «функциональности» (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется «вариантом», а степень числа — «потенцией»), назвали «методом». Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской «записи», привело к появлению концепции «наследования».Читать полностью »