Попался мне на глаза Brainfuck-оподобный язык Cow. И решил я написать для него интерпретатор на новомодном Rust. А так как Rust — мультипарадигменный язык, то стиль написания программы будет функциональный. Чтобы узнать что получилось — прошу под кат.

Задача публикации: доступно изложить способ организации иерархии исключений и их обработки в приложении. Без привязки к фреймворкам и конкретной архитектуре. Описываемый способ является де-факто стандартом в сообществе: он используется во многих серьёзных библиотеках и фреймворках. В том числе Zend, Symfony. Не смотря на его логичность и универсальность, формального описания предлагаемого подхода на русском языке я не нашёл. После неоднократного устного изложения концепции коллегам, родилась мысль оформить её в виде публикации на Хабрахабр.

В языке PHP, начиная с 5-ой версии, доступен механизм исключений. В актуальной, 7-ой, версии этот механизм был улучшен и переработан с целью единнобразной обработки разных ошибок при помощи конструкции try{} catch...

В стандартной библиотеке (SPL) PHP предоставляет готовый набор базовых классов и интерфейсов для исключений. В 7-ой версии этот набор был расширен интерфейсом Throwable. Вот диаграмма всех имеющихся в версии 7 типов (изображение — ссылка):

История первая

1. Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
2. Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
3. Игры для платформы Nintendo Wii.

В питоне аттрибуты класса можно сколько угодно модифицировать во время работы, и изменения видны всем объектам этого класса и других подклассов. Под катом — одно полезное применение этого факта.

В начале...

… не было ни композиции, ни наследования, только код.

И был код неповоротливым, повторяющимся, нераздельным, несчастным, избыточным и измученным.

Основным инструментом для повторного использования кода была копипаста. Процедуры и функции были редкостью, подозрительными новомодными штучками. Вызов процедур был дорогим удовольствием. Части кода, отделенные от основной логики, вызывали недоумение!

Мрачные были времена.

Но вот лучик ООП воссиял над миром… Правда, несколько десятилетий¹ никто этого не замечал. Покуда не появился графический интерфейс², которому, как выяснилось, очень-очень не хватало ООП. Когда нажимаешь на кнопку в окне, что может быть проще, чем отправить кнопке (или ее представителю) сообщение "Нажатие"³ и получить результат?

И вот тут ООП взлетел. Было написано множество⁴ книг, расплодились бесчисленные⁵ статьи. Так что сегодня-то каждый может в объектно-ориентированное программирование, так?

Или как можно проще об основных принципах ООП в Lazarus и FreePascal

Часть I

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

Во всех книгах, посвященных паскалю, delphi и lazarus (я нашел аж целых две о последнем), очень схожая часть, посвященная ООП. По этим книгам можно много узнать о том, насколько круче ООП устаревшего структурного подхода, но так и не получить достаточных навыков применения этого на практике. Конечно, любой программист, использующий визуальные IDE, уже по умолчанию использует ООП, так как все компоненты и структурные элементы визуального приложения представляют собой объекты, однако свои собственные структуры и абстракции перенести в парадигму ООП бывает очень сложно. Чтобы понять всю прелесть и оценить открывающиеся перспективы, я решил сделать небольшое приложение, которое в конечном итоге превратилось в простенький screensaver. Заодно вспомнил о существовании тригонометрии.

Приложение будет рисовать на экране в случайных местах пятьдесят полярных роз с разными характеристиками: размер, цвет, количество лепестков. Потом их же затирать и рисовать новые, и т.д. Используя принципы структурного программирования, можно, конечно, сделать обычный многомерный массив объемом на 50 и в нем сохранять все уникальные характеристики. Однако стоит вспомнить, что паскаль подразумевает строгую типизацию данных, а, следовательно, массив не может состоять их элементов с разными типами. Можно сделать массив из записей (record), но чего уж мелочиться, от записи до класса — один шаг. Вот его мы и сделаем.

• Готовимся к собеседованию по PHP: ключевое слово «static»
• Готовимся к собеседованию по PHP: псевдотип «callable»

Вступление

Что делать?

После прочтения статьи Введение в проектирование сущностей, проблемы создания объектов на хабре, я решил написать развернутый комментарий о примерах использования Domain-driven design (DDD), но, как водится, комментарий оказался слишком большим и я посчитал правильным написать полноценную статью, тем более что вопросу DDD, на Хабре и не только, удаляется мало внимания.

Рекомендую прочитать статью о которой я буду здесь говорить.
Если вкратце, то автор предлагает использовать билдеры для контроля за консистентностью данных в сущности при использовании DDD подхода. Я же хочу предложить использование Data Transfer Object (DTO) для этих целей.

Здравствуйте коллеги!

Хотелось бы поделиться мыслями об ООЯП и ООП в целом, а также что можно (и, как мне кажется, нужно) сделать на этой основе.

Основные идеи: В современных ООЯП отсутствует чётко выделенное и обязательное ядро моделирования для создания абстракций, основанных только на "чистых" концепциях ООП. Концепция ООП "всё есть объект" не практична. Концепция обмена сообщениями жёстко связана с её реализацией.

Вступление

Дверь.Замок.Повернуть(
обычныйКлюч, 
обороты: 2, 
контекстЗдания: мойДом.мояКвартира.ПолучитьКонтекст());