12. More Passives
13. Skill Tree
14. Console
15. Final
Читать полностью »
В 2017 году Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомитсья в оригинале). Переводом второй является данная статья. Перевод третьей будет доступен в скором времени.
Для меня, одним из обязательных требований, к "чистой" архитектуре, является грамотное разделение кода приложения по слоям. Сам слой не делает ничего, вся соль в том, как он используется и какие ограничения накладываются на компоненты, ему принадлежащие. Давайте немного пофилософствуем, перед тем как рассмотреть конеретные практические приемы.
Привет! Представляю вашем вниманию перевод статьи "Design Patterns in Cocos2d-x" автора Aleksei Pinchuk.
Статья будет интересна для разработчиков Cocos2d-x и тех, кто изучает паттерны. Она выполнена в форме краткого конспекта, в котором можно быстро посмотреть где применяется тот или иной паттерн в Cocos2d-x. Целью статьи не является полное описание каждого паттерна.
Читать полностью »
Перевод ироничного поста из блога Боба Мартина в котором он рассуждает о том, насколько неудачным является использование слова interface в современных языках программирования, и какую путаницу и проблемы оно несёт разработчикам.
— Что ты думаешь об интерфейсах?
— Имеешь в виду интерфейсы в Java или C#?
— Да. Классная фича этих языков?
— Просто великолепная!
— Правда? А что такое интерфейс? Это то же самое что и класс?
— Ну… Не совсем!
Здравствуйте коллеги!
В предыдущей статье речь шла о проблеме ООЯП в общем, в данной статье я бы хотел развить эту тему и показать более конкретно проблемы ООЯП.
Основные идеи: ООЯП имеют две ключевые проблемы: неполноценная объектная парадигма и преждевременная типизация. Неполноценная объектная парадигма не даёт определения понятию нетипизированной объектной композиции (композиция является важнейшим элементом любой парадигмы). Преждевременная типизация ограничивает семантику абстрактных понятий (семантических абстракций).
Одна из наиболее приятных для меня концепций Go — это возможность композиции интерфейсов. В этой статье мы разберем небольшой пример использования такой возможности языка. Для этого представим гипотетический сценарий, в котором две структуры обрабатывают пользовательские данные и выполняют http-запросы.
Читать полностью »
Всем привет! Я продолжаю серию переводов, в которой мы по косточкам разбираем, что такое Dependency Injection.
В предыдущих статьях серии речь шла о «внедрении зависимостей» как подходе к проектированию приложений и возможных способах реализации такого подхода. Были разобраны типы зависимостей, варианты их внедрения, давались советы по снижению связанности компонентов кода.
В сегодняшнем переводе речь пойдет о том, что собой представляет DI-контейнер, его функциях, преимуществах использования и отличии от фабрик.
Поговорим про unit тестирование. Для больших и возрастных проектов весьма актуальна проблема «толстых» сервисов. Я сейчас говорю про большое количество зависимостей передаваемых в конструктор. Если к этому добавить несколько десятков методов, которые необходимо тестировать, становится очевидно, что тратится много времени на мокирования ненужных частей. Решить проблему поможет автоматизация,. т.е. создание экземпляра необходимого типа и мокирование неиспользованных зависимостей в процессе выполнения.
Получается нам нужно
var myService = new MyService(A.Fake<ISevice1>(), new Sevice2(),
A.Fake<ISevice3>(), A.Fake<ISevice4>(),
A.Fake<ISevice5>(), A.Fake<ISevice6>())заменить на нечто похожее. Напоминает паттерн builde, не так ли?
var myService = GetInstance<MyService>().With(new Sevice2()).Subject;
Главное не переборщить с автоматизацией. Производительность тоже важна, особенно если в проекте несколько десятков тысяч тестов, которые будут запускаться как локально, так и в настроенном CI.
Разумеется нам не обойтись без рефлексии.
Читать полностью »
Привет! Я пишу статьи, посвященные архитектуре в игровой разработке. В этой статье я хочу разобрать паттерн Команда (Command). Он многогранен, и может быть применен по-разному. Но я покажу, как сделать мой любимый трюк — машина времени для отладки изменений гейм стейта.
Эта штука сэкономила мне кучу времени в поиске и воспроизведении сложных багов. Она позволяет делать "снапшоты" игрового состояния, историю его изменения, и пошагово их применять.
Начинающие разработчики познакомятся с паттерном, а продвинутые, возможно, найдут трюк полезным.
Хотите узнать как это сделать? Прошу под кат.