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

в 2:38, , рубрики: AngularJS, localStorage, phalcon, php, routing, Веб-разработка, интернет-магазин, корзина товаров, ооп, оформление заказа, Разработка под e-commerce, стайлгайд, сумма заказа

image

Введение

Всем привет! Не так давно я написал публикацию «Одностраничный магазин с корзиной на Phalcon + AngularJS + Zurb Foundation», которая имела неоднозначный эффект мягко говоря. А точнее получила много отрицательных комментариев, какие-то были объективные и конструктивные, какие-то нет, и они меня заставили задуматься, почему так произошло, ведь я хотел сделать полезный мануал, который пригодиться мне и другим, начинающим писать на AngularJS.

Исповедь

Да, мануал был полезен для меня, для меня старого, того, кому в 2009 году отказали в работе в местной веб-студии, и он по сей день ни разу ни работал в команде, ни разу не работал на наёмной работе, а полагался только на себя, и главным критерием эффективности реализации проектов был один — главное, что работает. Но это я — старый, после написания той статьи, и множества комментариев, я впервые решил попробовать сделать всё по правилам хорошего тона, хотя бы ради интереса.
Читать полностью »

в 4:30, , рубрики: AngularJS, phalcon, php, Веб-разработка, интернет-магазин, корзина товаров, ооп, оформление заказа, Разработка под e-commerce, сумма заказа

Введение

Всем привет! Завтра у меня дедлайн по проекту, который я делаю для местной Камчатской компании по доставки еды. И поэтому у меня есть две причины написать эту статью, первая — прокрастинация перед дедлайном, а вторая — я не нашёл на Хабре какого-либо обучающего мануала по написанию корзины товаров на AngularJS.

Я нашёл статью на стороннем блоге, которая частично помогла мне решить пару задач, которые стояли передо мной. Но оформление статьи оставляло желать лучшего, да и за 5 лет я уже отвык от кода в блокноте, без подсветки синтаксиса, поэтому нужно было как-то структурировать и сделать более читабельной эту полезную информацию.

Одностраничный магазин с корзиной на Phalcon + AngularJS + Zurb Foundation - 1

Почему был выбран формат одностраничного магазина?


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

в 9:50, , рубрики: dependency injection, game development, Gamedev, unity3d, ооп

Привет!

При ознакомлении с разработкой под Unity3D, для меня, пришедшего из мира Java и PHP, довольно необычным стал подход к внедрению зависимостей на данной платформе. В основном, конечно, это связано с недоступностью конструкторов MonoBehaviour и ScriptableObject, создание объектов вне доступа разработчика, а также наличие редактора, в котором можно конфигурировать каждый объект индивидуально или целыми префабами (при этом оставляя возможность один из экземпляров префаба изменить на своё усмотрение в процессе создания сцены).
Читать полностью »

в 20:48, , рубрики: Delphi, FireMonkey, open source, tdd, ооп, Проектирование и рефакторинг

Часть 1.
Часть 2.
Часть 3. DUnit + FireMonkey.
Часть 3.1. По мотивам GUIRunner.

Ещё в начале увлечения программированием мне нравилось работать с файлами. Работа, правда, в основном заключалась в чтении входных данных и записей результатов. Дальше была работа с БД, файлами я пользовался все реже. Максимум IniFile иногда. Поэтому задача сериализации была довольно интересной для меня.

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

image

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

в 12:46, , рубрики: er-диаграмма, Анализ и проектирование систем, бизнес-анализ, моделирование, онтология, ооп, Семантика, Терминология IT, управление проектами

Пою что вижу, или вижу, что пою?

Основная задача бизнес-аналитика при разработке нового ПО – изучение предметной области и формальное описание полученных сведений в виде модели (Domain Model). Аналитик должен петь то, что он видит и то, что он хочет увидеть. Для этого у него должен быть язык, на котором он исполнит свою песню. Однако, аналитик не всегда знаком с подходящим языком, и потому часто пользуется другими языками. Отчасти это происходит по причине того, что управление проектом ведется не с точки зрения предметной области, а с точки зрения реализации. И тогда с аналитиком может произойти несчастье: он может перестать видеть то, что надо петь и начать видеть лишь то, для чего есть слова в словарном запасе используемого им языка. Все остальное перестает для него существовать. Тогда, вместо того, чтобы петь, что он видит, аналитик начинает видеть то, что поет. Должен сразу заметить, я не против языков, я против сужения области анализа, которое возникает по причине недостаточности этих языков.

Структура таблицы

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

в 21:35, , рубрики: c++, c++11, ненормальное программирование, ооп, Проектирование и рефакторинг, фабричный метод

У классической реализации фабричного метода на C++ есть один существенный недостаток — используемый при реализации этого шаблона динамический полиморфизм предполагает размещение объектов в динамической памяти. Если при этом размеры создаваемых фабричным методом объектов не велики, а создаются они часто, то это может негативно сказаться на производительности. Это связанно с тем, что во первых оператор new не очень эффективен при выделении памяти малого размера, а во вторых с тем что частая деаллокация небольших блоков памяти сама по себе требует много ресурсов.
Для решения этой проблемы было бы хорошо сохранить динамический полиморфизм (без него реализовать шаблон не получится) и при этом выделять память на стеке.
Если вам интересно, как это у меня получилось, добро пожаловать под кат.

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

в 13:38, , рубрики: иерархия, композиция, наследование, ненормальное программирование, ооп

Эта публикация — ответ на текст «Решетчатое наследование», опубликованный хабрапользователем potan, с предложением альтернативы, на субъективный взгляд автора, более близкой к ООП с классами.
Читать полностью »

в 7:23, , рубрики: clojure, иерархии, наследование, ненормальное программирование, ооп

Наследование, при кажущейся простоте, часто приводит к сложным, сопротивляющимся изменениям структурам. Иерархии классов растут как самый настоящий лес.
Целью наследование является привязка кода (набора методов) к минимальному набору свойств сущности (как правило — объекта), которые он обеспечивает и которые ему требуются. Это упрощает повторное использование, тестирование и анализ кода. Но наборы свойств со временем становятся очень большими, начинают пересекаться нетривиальным образом. И в структуре классов появляются миксины и прочее множественное наследование.
Внести изменения в глубине иерархии становится проблематично, приходится думать заранее о «внедрении зависимостей», разрабатывать и использовать сложные инструменты рефакторинга.

Возможно ли всего этого избежать? Стоит попытаться — пусть методы будут привязаны к множеству характерных свойств объекта (тегов), а иерархия наследования выстраивается автоматически по вложенности этих множеств.

Пусть мы разрабатывает иерархию для игровых персонажей. Часть кода будет общая для всех персонажей — она привязана к пустому набору свойств. Код, отвечающий за их отображение будет представлен в виде вариантов для OpenGL и DirectX разных версий. Что-то будет зависеть от расы персонажа, что-то от наличия и вида магических способностей и тп. Теги персонажа первичны. Они перечисляются явно, а не наследуются. А реализация наследуется в зависимости от набора тегов (по вложенности). Таким образом умение стрелять из ПЗРК не окажется у кенгуру, потому что его унаследовали от пехотинца.

Идея такого подхода была предложена Дмитрием Кимом. Автор не стал ее воплощать в код, я попробую исправить это упущение.
Реализация такого подхода на Clojure, как обычно, на github.
Читать полностью »

в 9:06, , рубрики: active record, mysql, php, Zend Framework, базы данных, ооп, шаблоны проектирования

Доброго времени суток! Я работаю над веб-проектом X. Проект большой, сложный и перспективный. Но, как и в любом другом проекте, есть много кода, написанного наспех с пометкой «когда-нибудь исправлю».

Пришло время исправлять.

Читая очередной мануал, я обнаружил шаблон проектирования «Active Record». Простой запрос в Google, и вот уже подруга Википедия коротко и ясно рассказала обо всём (https://ru.wikipedia.org/wiki/ActiveRecord). Смысл шаблона прост: для работы с таблицами в базе данных решено было создать специальный класс, который бы выполнял все основные действия (CRUD).
Читать полностью »

в 9:26, , рубрики: php, ооп

Некоторое время назад назад Энтони Феррара выразил мысли по поводу будущего PHP. Соглашусь с большинством его взглядов, но не со всеми. В статье я остановлюсь на одном конкретном аспекте: преобразования примитивных типов данных, таких как строки или массивы, в “псевдо-объекты”, позволяя выполнять в них вызовы методов.

Начнем с нескольких примеров:

$str = "test foo bar";
$str->length();      // == strlen($str)        == 12
$str->indexOf("foo") // == strpos($str, "foo") == 5
$str->split(" ")     // == explode(" ", $str)  == ["test", "foo", "bar"]
$str->slice(4, 3)    // == substr($str, 4, 3)  == "foo"

$array = ["test", "foo", "bar"];
$array->length()       // == count($array)             == 3
$array->join(" ")      // == implode(" ", $array)      == "test foo bar"
$array->slice(1, 2)    // == array_slice($array, 1, 2) == ["foo", "bar"]
$array->flip()         // == array_flip($array)        == ["test" => 0, "foo" => 1, "bar" => 2]

Здесь $str — это обычная строка и $array является простым массивом — они не объекты. Мы просто даем им немного объектного поведения, позволяя вызывать в них методы.

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

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

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