У классической реализации фабричного метода на C++ есть один существенный недостаток — используемый при реализации этого шаблона динамический полиморфизм предполагает размещение объектов в динамической памяти. Если при этом размеры создаваемых фабричным методом объектов не велики, а создаются они часто, то это может негативно сказаться на производительности. Это связанно с тем, что во первых оператор new не очень эффективен при выделении памяти малого размера, а во вторых с тем что частая деаллокация небольших блоков памяти сама по себе требует много ресурсов.
Для решения этой проблемы было бы хорошо сохранить динамический полиморфизм (без него реализовать шаблон не получится) и при этом выделять память на стеке.
Если вам интересно, как это у меня получилось, добро пожаловать под кат.
Рубрика «ооп» - 33
Фабричный метод без размещения в динамической памяти
2014-11-28 в 21:35, admin, рубрики: c++, c++11, ненормальное программирование, ооп, Проектирование и рефакторинг, фабричный методОтвет на Решетчатое наследование
2014-11-26 в 13:38, admin, рубрики: иерархия, композиция, наследование, ненормальное программирование, ооп Эта публикация — ответ на текст «Решетчатое наследование», опубликованный хабрапользователем potan, с предложением альтернативы, на субъективный взгляд автора, более близкой к ООП с классами.
Читать полностью »
Решетчатое наследование
2014-11-26 в 7:23, admin, рубрики: clojure, иерархии, наследование, ненормальное программирование, ооп Наследование, при кажущейся простоте, часто приводит к сложным, сопротивляющимся изменениям структурам. Иерархии классов растут как самый настоящий лес.
Целью наследование является привязка кода (набора методов) к минимальному набору свойств сущности (как правило — объекта), которые он обеспечивает и которые ему требуются. Это упрощает повторное использование, тестирование и анализ кода. Но наборы свойств со временем становятся очень большими, начинают пересекаться нетривиальным образом. И в структуре классов появляются миксины и прочее множественное наследование.
Внести изменения в глубине иерархии становится проблематично, приходится думать заранее о «внедрении зависимостей», разрабатывать и использовать сложные инструменты рефакторинга.
Возможно ли всего этого избежать? Стоит попытаться — пусть методы будут привязаны к множеству характерных свойств объекта (тегов), а иерархия наследования выстраивается автоматически по вложенности этих множеств.
Пусть мы разрабатывает иерархию для игровых персонажей. Часть кода будет общая для всех персонажей — она привязана к пустому набору свойств. Код, отвечающий за их отображение будет представлен в виде вариантов для OpenGL и DirectX разных версий. Что-то будет зависеть от расы персонажа, что-то от наличия и вида магических способностей и тп. Теги персонажа первичны. Они перечисляются явно, а не наследуются. А реализация наследуется в зависимости от набора тегов (по вложенности). Таким образом умение стрелять из ПЗРК не окажется у кенгуру, потому что его унаследовали от пехотинца.
Идея такого подхода была предложена Дмитрием Кимом. Автор не стал ее воплощать в код, я попробую исправить это упущение.
Реализация такого подхода на Clojure, как обычно, на github.
Читать полностью »
ActiveRecord своими руками на PHP
2014-11-06 в 9:06, admin, рубрики: active record, mysql, php, Zend Framework, базы данных, ооп, шаблоны проектированияДоброго времени суток! Я работаю над веб-проектом X. Проект большой, сложный и перспективный. Но, как и в любом другом проекте, есть много кода, написанного наспех с пометкой «когда-нибудь исправлю».
Пришло время исправлять.
Читая очередной мануал, я обнаружил шаблон проектирования «Active Record». Простой запрос в Google, и вот уже подруга Википедия коротко и ясно рассказала обо всём (https://ru.wikipedia.org/wiki/ActiveRecord). Смысл шаблона прост: для работы с таблицами в базе данных решено было создать специальный класс, который бы выполнял все основные действия (CRUD).
Читать полностью »
Некоторое время назад назад Энтони Феррара выразил мысли по поводу будущего 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 позволяет определить методы для примитивных типов.
Как я писал Foundation для С
2014-10-07 в 11:47, admin, рубрики: c++, define, библиотеки с, ненормальное программирование, ооп 
Долгое время программирования на Obj-C оставляет свой отпечаток на челе программиста. Кто видел этот красивый Foundation, написанный еще во времена NeXTSTEP, т.е. приблизительно в 1987-89 годы (кто знает более точную дату, поправте меня). Вся красота чистого ООП-программирования, доступная в Obj-C слилась в NS, который действительно был next step'ом по качеству и красоте кода. Это было создание, почти всех необходимых базовых средств разработки:
— строки и локализация;
— контейнеры (динамический массив, словарь (он же NSDictionary, для С++-ов привычнее слово map), даты (NSDate));
— потоки;
— графика;
— архиватор обьектов и другие плюшки.
Читать полностью »
PHP-фреймворк Badoo
2014-10-07 в 9:00, admin, рубрики: badoo, blitz, framework, javascript, php, php-framework, protobuf, баду, Блог компании Badoo, Веб-разработка, ооп 
Код нашего сайта повидал уже не одну версию PHP. Он неоднократно дополнялся, переписывался, модифицировался, рефакторился — в общем, жил и развивался своей жизнью. В это время в мире появлялись и исчезали новые best practice, подходы, фреймворки и тому подобные явления, облегчающие жизнь разработчику и готовые решить все основные проблемы, возникающие в процессе создания веб-сайтов.
В этой статье мы расскажем о нашем пути: как был организован код изначально, какие возникали проблемы и как появился текущий фреймворк.
Что было
Проект начали делать еще в 2005 году. Тогда никаких жестких правил по написанию кода и четко структурированного фреймворка не было. Код писали несколько разработчиков, они легко в нем ориентировались и его поддерживали, каждый привносил что-то свое. В то время известные сейчас фреймворки только создавались, поэтому примеров для подражания было мало. Так что можно сказать, что наш фреймворк образовался стихийно.
С архитектурной точки зрения это выглядело так: были объекты страниц, наследуемые от целой иерархии базовых классов, отвечающих за инициализацию окружения, сессии, пользователя и т.п. Каждая страница сама решала, когда, как и что ей выводить, делать редирект и т.п. В иерархии базовых классов было собрано много вспомогательных функций для инициализации и генерации стандартных блоков страниц, проверки пользователей, показа промежуточных промо-страниц и т.п. Со временем большинство из них было переопределено наследниками до неузнаваемости, что в разы усложнило и понимание того, как работает сайт, и саму поддержку кода.
Читать полностью »
Притча о программистах и кодерах
2014-09-15 в 10:33, admin, рубрики: ооп, паттерны, приёмы программирования, Программирование Давным давно, в далёкой предалёкой галактике, на одной провинциальной планетке жили разумные млекопитающие, у которых недавно начался век информационных технологий. В тот век многим приходилось писать программы на разных языках для различных программных платформ. И любой потомок обезьяны с этой планеты, написавший хотя бы пару строчек кода, который заставил тупую вычислительную машину сделать несколько разумных (с точки зрения автора) действий, уже считал себя просветлённым мудрецом, постигшим ДАО информационных технологий и назывался не иначе как джедаем программистом.
Сегодня, дорогие любители истории вселенной, мы с вами постараемся разобраться, в чём же заключается фундаментальное заблуждение этих потомков обезьян людей, и в чём же различие между программистами и не программистами, для простоты будем называть их кодерами.
Читать полностью »
ООБД без ООП
2014-09-05 в 6:36, admin, рубрики: Анализ и проектирование систем, объектно-ориентированные бд, ооп, Программирование, метки: объектно-ориентированные бд, ооп Лично мне не надо объяснять, что такое ООП. Я сам в первую очередь мыслю существительными и только во вторую — глаголами.
Но речь не о том, кто как мыслит; я хочу обсудить ситуацию, когда отказ от привычных механизмов ООП упрощает работу с объектами.
Как, пример, можно вспомнить добрым словом Lotus Notes, где имя формы хранилось внутри документа. Создавая форму LN, мы тем самым описываем новый UI класс, в котором можно добавлять свойства и переопределять методы (Queryopen, Postsave и пр.). При этом новый объект, созданный с помощью этой формы, не связан с ней механизмом наследования. Форма – это свойство объекта, и в LN есть команда «SwitchForm», с помощью которой можно открыть объект с другой формой, естественно, с вызовом других методов. Неопределенные свойства при этом вернут пустую строку.
Читать полностью »
MindStream. Как мы пишем ПО под FireMonkey
2014-08-11 в 14:51, admin, рубрики: Delphi, FireMonkey, FireMonkey mobile, ооп, Проектирование и рефакторингМесяц назад мы решили написать кросс-платформенное приложение, используя FireMonkey. В качестве направления выбрали рисование графических примитивов, с возможностью сохранения и восстановления данных.
Процесс написания приложения мы договорились подробно описывать на Хабре.
В статьях будет показано на практике использования различных техник, таких как: Dependency Injection, фабричный метод, использование контекстов, использование контроллеров и т.д. В ближайшем будущем планируется прикрутить туда тесты Dunit. DUnit’a в данный момент нет для FMX, так что придётся что-то придумывать самим.
Начнем мы с рабочего прототипа который к моменту окончания статьи приобретет такой вид:
