Рубрика «композиция»

Использовать финальные классы или не использовать финальные классы? Вот в чём вопрос. А ещё в том, когда и как это делать правильно.

Финальные классы в PHP, Java и других языках - 1

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

Выбираемся из дебрей тестов: строим короткий путь от фикстуры к проверке - 1

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

Несмотря на то, что код написан на Scala, предлагаемые идеи будут актуальны для разработчиков и тестировщиков на всех языках, поддерживающих парадигму функционального программирования. Ссылку на Github с полным решением и примером вы сможете найти в конце статьи.

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

Тайлер Анлауф подготовил подробный анализ модульного окружения ROME: Church of Sant’Ivo созданного им в UE4 и 3ds Max. В статье он рассказывает о предварительном черновом плане (blockout), модульной сборке, освещении, постобработке и многом другом.

Сложное модульное архитектурное окружение в UE4 - 1

ROME: Church of Sant’Ivo

В данном анализе я поделюсь с вами своим процессом работы над ROME: Church of Sant’Ivo, хитростями, которым научился, трудностями, с которыми столкнулся во время работы, а также планами под дальнейшему усовершенствованию сцены, потому что она пока ещё не завершена.

Сложное модульное архитектурное окружение в UE4 - 2

Цели проекта

Задачи этого проекта заключались в усовершенствовании моего процесса работы над графикой, изучении Unreal Engine и улучшении моих навыков работы с освещением, цветом и композицией. Храм Сант-Иво алла Сапиенца соответствует целям проекта — в нём очевидно заметны возможности работы с модульной структурой, освещением, цветом и композицией.

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

Эволюция мобильной архитектуры Reddit - 1

Это первая из статей, где мы рассказываем об архитектуре приложения Reddit под iOS. Здесь речь идёт о функциональности, которая работает ближе к UI. В частности, о переходе к архитектуре Model-View-Presenter (MVP). Преимущества такого рефакторинга:

  • Улучшение гибкости кода, его ясности и поддерживаемости для поддержки будущего роста и ускорения итераций.
  • Повышение производительности прокрутки в 1,58 раза.
  • Стимуляция модульного тестирования. Количество тестов увеличилось с нескольких штук до более 200.

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

Нередко случается, что решив разобраться с какой-то новой темой, понятием, инструментом программирования, я читаю одну за другой статьи на различных сайтах в интернете. И, если тема сложная, то эти статьи могут не на шаг не приблизить меня к понимаю. И вдруг встречается статья, которая моментально дает озарение и все паззлы складываются воедино. Трудно определить, что отличает такую статью от других. Правильно подобранные слова, оптимальная логика изложения или же просто более релевантный пример. Я не претендую на то, что моя статься окажется новым словом в C# или же лучшей обучающей статьей. Но, возможно для кого-то она станет именно той, которая позволит разобраться, запомнить и начать правильно применять те понятия, о которых пойдет речь.
Читать полностью »

Впервые о теории близости я прочитал в 2007 году. Она была сформулирована так: «объекты, расположенные близко друг к другу, воспринимаются связанно». Тогда я подумал: «спасибо, Кэп! Я как-то и сам догадался, что букву “М” нужно вешать ближе к мужскому туалету, а не к женскому». Тогда я не осознал, что это одно из главных правил дизайна, которое помогает подбирать расстояния между элементами, размеры полей, расположение кнопок, размер логотипов и многое другое. А главное, теория позволяет быстро понять, хороший перед вами дизайн или нет, даже если вы не дизайнер.
image
Читать полностью »

В мире объектно-ориентированного программирования уже достаточно давно подвергается критике концепция наследования.

Аргументов достаточно много:

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

Альтернативой наследованию являются использование интерфейсов и композиция. (Интерфейсы давно используется в качестве альтернативы множественному наследованию, даже если в иерархии классов активно используется наследование.)

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

А как можно решить эту задачу (отсутствие дублирования кода) в случае композиции и интерфейсов?
Этой теме и посвящена настоящая статья.
Читать полностью »

Мы в rangle.io давно увлекаемся функциональным программированием, и уже опробовали Underscore и Lodash. Но недавно мы наткнулись на библиотеку Ramda, которая на первый взгляд похожа на Underscore, но отличается в небольшой, но важной области. Ramda предлагает примерно тот же набор методов, что и Underscore, но так организовывает работу с ними, что функциональная композиция становится легче.

Разница между Ramda и Underscore – в двух ключевых местах – каррирование и композиция.
Читать полностью »

Что нужно знать, чтобы хорошо рисовать? - 1

Давид Ревуа — прекрасный художник, работающий со свободным программным обеспечением, постоянный член сообществ Krita Foundation и Blender Institute, концепт-художник анимационных проектов Gooseberry Open Movie Project, Mango Open Movie Project (Tears of Steel) и Durian Open Movie Project (Sintel). В этой статье он делится с начинающими художниками списком знаний, которые необходимо приобрести, чтобы работы получались реалистичными. Он обращает внимание, что для рисования «в цифре» следует обзавестись теми же навыками, что и в традиционной технике. Итак, приобщимся к его опыту.
Читать полностью »

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js