Слишком часто стала мелькать в западных блогах и твиттере аббревиатура “DCI”. Меня удивил тот факт, что на хабре по данной тематике почти нету информации, лишь в Ruby NoName Podcast S04E09 упоминалось об этом. Любопытство взяло вверх, и я решил узнать об этом загадочном слове побольше. В процессе поиска я наткнулся на хорошую статью, написанную на английском моим земляком, Виктором Савкиным. Данная статья без обильной теории, на практических примерах показывает, что из себя представляет DCI. Далее повествование будет идти от лица Виктора.Читать полностью »
Рубрика «ооп» - 44
Data Context Interaction (DCI) — эволюция объектно-ориентированной парадигмы
2012-09-10 в 10:41, admin, рубрики: dci, mvc, ruby, Анализ и проектирование систем, ооп, Программирование, проектирование поГенераторы 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, оопНе знаю пока, зачем и почему первым постом я выбрал именно этот. Да я прекрасно понимаю, что из этого поста я получу много отрицательных комментариев и возможно карма будет неизбежно испорчена, но будем надеяться оно того стоит.
На что хотелось бы обратить Ваше внимание, что я не хочу никого переубеждать или менять точку зрения. Этот пост, как и звучит в заголовке, просто заставит Вас задуматся.
В этот же момент я пропишу немного материала, которая позволит исключить часть негатива, который вызывает данный пост в истинных ООП-ков.
Читать полностью »
Я влюбился в DelegateClass
2012-08-12 в 9:55, admin, рубрики: delegator, ruby, ruby on rails, ооп, рефакторинг Если ваш класс разросся настолько, что начинает нарушать принцип единственной обязанности, вы без труда сможете разбить его на несколько более связных классов. Поможет вам в этом предоставляемая Ruby конструкция DelegateClass.
Допустим, у вас есть класс Person. Пользователи в системе могут продавать что-то и/или публиковать статьи. Подклассы здесь использовать не получится, потому что пользователь может одновременно быть и автором, и продавцом. Проведем рефакторинг.
Читать полностью »
Я, наверное, знаю ООП. Опыт объектно-ориентированного программирования и дизайна. Ответ «не знающим ООП.»
2012-08-06 в 8:24, admin, рубрики: java, абстрагирование, инкапсуляция, интерфейсы, наследование, ооп, Программирование, проектирование, проектирование взаимодействия, проектирование интерфейсов, метки: абстрагирование, инкапсуляция, интерфейсы, наследование, ооп, проектирование, проектирование взаимодействия, проектирование интерфейсовПосле появления статей типа "Я не знаю ООП" — возникает желание внести ясность, «сорвать покровы» и «докопаться до истины».
Принципы объектно-ориентированности
Обычно выделяют (читай: на собеседовании требуют назвать) четыре «принципа объектно-ориентированного программирования»: абстракцию, инкапсуляцию, наследование и полиморфизм.
На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта — некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного «функциональности» (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется «вариантом», а степень числа — «потенцией»), назвали «методом». Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской «записи», привело к появлению концепции «наследования».Читать полностью »
AMatch — проверка входных параметров в PHP
2012-08-06 в 7:44, admin, рубрики: amatch, php, validation, ооп, Песочница, Программирование, метки: amatch, PHP, validation, оопТоварищи! Эта статья не для high-high-highload систем. Скорость работы представленных решений определённо меньше простейших проверок. На многотысячных или очень глубоких структурах применять предлагаемый подход крайне не рекомендуется. В этом топике побеждает быстрое кодирование, а не быстрый код.
Без длинных
Давайте без длинных вступлений, но всё же с предысторией. Однажды в рамках создания очередного очень важного компонента веб-сервиса нам понадобилось проверять уйму очень разных входных параметров (в данном случае, пришедших через $_REQUEST). Компонент был очень сложный, внутренняя и внешняя логика вызывала ежедневный баттхёрт между всеми участниками, а отдуваться приходилась немногим «избранным» программистам, которые писали, переписывали, выпиливали и запиливали заново. Когда на вход в систему с фронтенда падают десятки разных переменных, в том числе массивов, программисты при этом делают перекрёстные задачи (меняя логику) и мешают друг другу — код очень быстро разрастается, количество цепочек if-ов начинает занимать не одну страницу. Возвращаться к такому коду всё более и более чуждо ранимой душе. Тесты уже не очень помогают, т. к. каждое изменение логики приводит к изменению тех же тестов, в которых ещё надо вспомнить, понять и простить. Вот тогда и встал вопрос о создании удобного способа проверять весь входной поток каким-то приятным глазу способом, да чтоб всегда и везде получать фидбек про ошибки в однотипном виде. Акцент тут изначально стоял именно на удобстве для разработчиков, строго прошу в дальнейшем иметь.
Читать полностью »
Объектно-ориентированное функциональное метапрограммирование или каррирование метода
2012-08-01 в 15:59, admin, рубрики: closure, php, каррирование, метапрограммирование, ооп, Программирование, функциональное программирование, частичное применение, метки: closure, PHP, каррирование, метапрограммирование, ооп, функциональное программирование, частичное применение 
Вдохновившись статьей Еще раз о каррировании и частичном применении в PHP, в голову пришла реализация частичного применения метода, именно метода, а не функции.
Читать полностью »