Рубрика «ооп» - 47

в 12:22, , рубрики: mvc, php, Zend Framework, велосипедостроение, ооп, метки: , , , ,

Недавно мне было поручено разработать некое веб-приложение. Не буду вдаваться в подробности, а лишь скажу, что приложение связанно с планированием перевозок. Есть общедоступная часть, воспользоваться которой может любой посетитель сайта. Есть внутренние интерфейсы для операторов системы. Есть информеры для размещения на сторонних сайтах. С технической точки зрения это несколько десятков экранов, множество различных форм, табличек. Часть экранов используют ajax, кастомные компоненты, написанные на javascript, и всякие красивости типа drag-and-drop. Данные, как обычно, хранятся в реляционной БД в виде полутора десятков таблиц. В общем не совсем примитивное приложение, но и очень сложным назвать его тоже не могу.

По работе мне, мне достаточно часто приходится проектировать или лично кодить подобные приложения. Однако в данном проекте было одно важное требование. Приложение должно быть разработано на базе серьезной и проверенной платформе, а именно на Zend Framework. Использование самописных “велосипедов” — недопустимо. Скажу честно, опыта реальной работы с Zend Framework у меня до сих пор не было. Но платформа известная и за ней стоит известный разработчик. Многими разработчиками Zend Framework вообще рассматривается как стандарт веб разработки. Так что, тем более, есть повод освоить что то новое и солидное. Поэтому я с энтузиазмом взялся за этот проект.
Читать полностью »

в 9:03, , рубрики: autoload, php, Веб-разработка, ооп, фабрика, фреймворки php, метки: , , , ,

Из-за того, что приходится использовать различные фреймворки, но писать, по сути, одно и то же рано или поздно начинает преследовать дежавю. Для php это особенно актуально, часто приходится как выбирать платформу под заказчика, так и допиливать уже имеющийся проект. Вроде бы, нет ничего проще — написал один раз код и таскай его за собой. Но различные API и организация файлов не дают это сделать естественным образом. Очевидное решение — организация своего «багажа» в виде классов. Тогда конкретное приложение (модуль, компонент) как раз будут связывать API фреймворка (или CMS) с вашим классом. Проблема организации файлов имеет также вроде бы очевидное решение — инклудишь нужный класс и всё. Но не зря же все активно пользуются различными фреймворками, а не пишут все с нуля — лучше сосредоточиться на новых задачах, а не думать как «подцепить» уже готовое. Посему я и написал небольшой класс, фабрику-загрузчик.
Читать полностью »

в 14:32, , рубрики: 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)); // для наглядности умрём
}

Читать полностью »

в 13:40, , рубрики: php, ооп, Программирование, метки: ,

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

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

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

в 9:55, , рубрики: delegator, ruby, ruby on rails, ооп, рефакторинг

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

Допустим, у вас есть класс Person. Пользователи в системе могут продавать что-то и/или публиковать статьи. Подклассы здесь использовать не получится, потому что пользователь может одновременно быть и автором, и продавцом. Проведем рефакторинг.
Читать полностью »

в 8:24, , рубрики: java, абстрагирование, инкапсуляция, интерфейсы, наследование, ооп, Программирование, проектирование, проектирование взаимодействия, проектирование интерфейсов, метки: , , , , , , ,

После появления статей типа "Я не знаю ООП" — возникает желание внести ясность, «сорвать покровы» и «докопаться до истины».

Принципы объектно-ориентированности

Обычно выделяют (читай: на собеседовании требуют назвать) четыре «принципа объектно-ориентированного программирования»: абстракцию, инкапсуляцию, наследование и полиморфизм.

На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта — некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного «функциональности» (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется «вариантом», а степень числа — «потенцией»), назвали «методом». Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской «записи», привело к появлению концепции «наследования».Читать полностью »

в 7:44, , рубрики: amatch, php, validation, ооп, Песочница, Программирование, метки: , , ,

Товарищи! Эта статья не для high-high-highload систем. Скорость работы представленных решений определённо меньше простейших проверок. На многотысячных или очень глубоких структурах применять предлагаемый подход крайне не рекомендуется. В этом топике побеждает быстрое кодирование, а не быстрый код.

Без длинных

Давайте без длинных вступлений, но всё же с предысторией. Однажды в рамках создания очередного очень важного компонента веб-сервиса нам понадобилось проверять уйму очень разных входных параметров (в данном случае, пришедших через $_REQUEST). Компонент был очень сложный, внутренняя и внешняя логика вызывала ежедневный баттхёрт между всеми участниками, а отдуваться приходилась немногим «избранным» программистам, которые писали, переписывали, выпиливали и запиливали заново. Когда на вход в систему с фронтенда падают десятки разных переменных, в том числе массивов, программисты при этом делают перекрёстные задачи (меняя логику) и мешают друг другу — код очень быстро разрастается, количество цепочек if-ов начинает занимать не одну страницу. Возвращаться к такому коду всё более и более чуждо ранимой душе. Тесты уже не очень помогают, т. к. каждое изменение логики приводит к изменению тех же тестов, в которых ещё надо вспомнить, понять и простить. Вот тогда и встал вопрос о создании удобного способа проверять весь входной поток каким-то приятным глазу способом, да чтоб всегда и везде получать фидбек про ошибки в однотипном виде. Акцент тут изначально стоял именно на удобстве для разработчиков, строго прошу в дальнейшем иметь.
Читать полностью »

в 15:59, , рубрики: closure, php, каррирование, метапрограммирование, ооп, Программирование, функциональное программирование, частичное применение, метки: , , , , , ,

Искусство каррирования
Вдохновившись статьей Еще раз о каррировании и частичном применении в PHP, в голову пришла реализация частичного применения метода, именно метода, а не функции.
Читать полностью »

в 3:08, , рубрики: c++, инкапсуляция, ооп, сборка мусора, указатели, управление памятью, метки: , , ,

Недавно появилась заметка о простой и эффективной «ручной» сборке мусора в С++. Вполне допускаю, что локальная сборка мусора внутри какого-то сложного класса (где идёт активная низкоуровневая работа с указателями) может быть оправдана. Но в масштабах большой программы, существует более надёжный и простой метод избавления от утечек памяти. Не претендуя на «метод на все случаи жизни», очень надеюсь, что он сделает проще жизнь хотя бы некоторым из читателей.

Суть метода предельно проста: если каждый объект является переменной какой-либо области видимости или простым («стековым») членом другого объекта, то даже при аварийном закрытии программы от необработанного исключения, всегда будет происходить корректная очистка. Задача заключается в том, чтобы свести всё многообразие динамических сценариев к этой схеме.
Читать полностью »

в 8:45, , рубрики: ruby, ооп, Программирование

Под катом несколько примеров того как можно отрефакторить код, сделать его более элегантным и расширяемым. Все представлено в примерах.Читать полностью »

1...1020...464748...50...50
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js