Перевод ироничного поста из блога Боба Мартина в котором он рассуждает о том, насколько неудачным является использование слова interface в современных языках программирования, и какую путаницу и проблемы оно несёт разработчикам.
— Что ты думаешь об интерфейсах?
— Имеешь в виду интерфейсы в Java или C#?
— Да. Классная фича этих языков?
— Просто великолепная!
— Правда? А что такое интерфейс? Это то же самое что и класс?
— Ну… Не совсем!
Здравствуйте коллеги!
В предыдущей статье речь шла о проблеме ООЯП в общем, в данной статье я бы хотел развить эту тему и показать более конкретно проблемы ООЯП.
Основные идеи: ООЯП имеют две ключевые проблемы: неполноценная объектная парадигма и преждевременная типизация. Неполноценная объектная парадигма не даёт определения понятию нетипизированной объектной композиции (композиция является важнейшим элементом любой парадигмы). Преждевременная типизация ограничивает семантику абстрактных понятий (семантических абстракций).
Не так давно React позиционировал себя как "V in MVC". После этого коммита маркетинговый текст изменился, но суть осталась той же: React отвечает за отображение, разработчик — за все остальное, то есть, говоря в терминах MVC, за Model и Controller.
Одним из решений для управления Model (состоянием) вашего приложения стал Redux. Его появление мотивировано возросшей сложностью frontend-приложений, с которой не способен справиться MVC.
Главный Технический Императив Разработки ПО — управление сложностью
— Совершенный код
Redux предлагает управлять сложностью с помощью предсказуемых изменений состояния. Предсказуемость достигается за счет трех фундаментальных принципов:
Смог ли Redux побороть возросшую сложность и было ли с чем бороться?
var myService = new MyService(A.Fake<ISevice1>(), new Sevice2(),
A.Fake<ISevice3>(), A.Fake<ISevice4>(),
A.Fake<ISevice5>(), A.Fake<ISevice6>()) var myService = GetInstance<MyService>().With(new Sevice2()).Subject;
Привет! Я пишу статьи, посвященные архитектуре в игровой разработке. В этой статье я хочу разобрать паттерн Команда (Command). Он многогранен, и может быть применен по-разному. Но я покажу, как сделать мой любимый трюк — машина времени для отладки изменений гейм стейта.
Эта штука сэкономила мне кучу времени в поиске и воспроизведении сложных багов. Она позволяет делать "снапшоты" игрового состояния, историю его изменения, и пошагово их применять.
Начинающие разработчики познакомятся с паттерном, а продвинутые, возможно, найдут трюк полезным.
Хотите узнать как это сделать? Прошу под кат.
Мы — внедрители. Мы должны внедрять, а не фантазировать!
(Рина Зеленая, к/ф «Девушка без адреса»)
Stage, Console и SkillTree.
Надеюсь материалы опубликованные в данной статье не покажутся слишком очевидными или покушением на оскорбление чувств «верующих», и уж тем более никто не воспримет название статьи слишком буквально как «ориентированное программирование». В любом случае данная статья это попытка поделиться личным опытом, а не пропаганда своей точки зрения.
SOLID критикует тот, кто думает, что действительно понимает ООП
© Куряшкин Виктор
Я знаком с принципами SOLID уже 6 лет, но только в последний год осознал, что они означают. В этой статье я дам простое объяснение этим принципам. Расскажу о минимальных требованиях к языку программирования для их реализации. Дам ссылки на материалы, которые помогли мне разобраться.
Вы когда-нибудь задумывались как устроен ID видео на YouTube?
Возможно, вы уже знаете/нашли ответ, но, как показали обсуждения на Stack Overflow, многие понимают эту технологию неправильно. Если вам интересно изучить что-то новое, добро пожаловать под кат.
