Иногда нет-нет да и хочется что-нибудь абстрагировать и обобщить в коде на Си. К примеру, хочешь ты принтануть содержимое структуры несколько раз, пишешь везде, как дурак, printf("%s %d %f\n", foo->bar, foo->baz, foo->boom), и интуитивно кажется, что есть способ сделать foo->print(foo), и так вообще со всеми структурами, не только с foo.
Возьмем пример: есть некий чувак с именем и фамилией, и есть птица, у которой есть имя и владелец.
Здравствуйте, меня зовут Дмитрий Карловский и я… крайне плох в построение социальных связей, но чуть менее плох в построении программных. Недавно я подытожил свой восьмилетний опыт реактивного программирования, проведя обстоятельный анализ различных подходов к решению типичных детских болячек:
Main Aspects of Reactivity
Я очень рекомендую прочитать сперва ту статью, чтобы лучше понимать дальнейшее повествование, где мы с нуля разработаем совершенно новую TypeScript реализацию, вобравшую в себя все самые крутые идеи, позволяющие достигнуть беспрецедентной выразительности, компактности, скорости, надёжности, простоты, гибкости, экономности..
Статья разбита на главы, перелинкованные с соответствующими аспектами из упомянутого выше анализа. Так что если вдруг потеряетесь — сможете быстро восстановить контекст.
Повествование будет долгим, но если вы продержитесь до конца, то сможете смело идти к начальнику за повышением. Даже если вы сам себе начальник.
Машины Руба Голдберга «работают». А еще они неэффективные, хрупкие, их сложно изготовить и поддерживать. Поэтому написать код, который «просто работает» — очень низкая планка.
Многие не осознают, что написание кода во многом напоминает написание эссе или книги. Насколько же я был уверен, что умение писать эссе мне «в жизни не пригодится» - но позже я узнал, что писать эссе – значит гораздо больше, чем укладываться в число слов и соответствовать критериям оценки.
Некоторое время назад пытался устроиться на подобные вакансии (меня не взяли). Но теперь есть список вопросов, которые помогут подготовиться и углубиться в мир программирования (список вопросов взят из самого долгого интервью, остальные были в разы короче).
Некоторым из этих книг уже очень много лет. Главная книга о паттернах — Design Patterns — увидела свет в 1994-м году, значит, ей уже почти тридцать. По сравнению с ней, Clean Architecture, вышедшая десять лет назад — практически, ребёнок!
Но десять лет для индустрии — гигантский срок. Возможно, эти книги уже устарели и нам они не нужны?
В прошлой статье в частности я критиковал, что при создании игр неумело используют технологию MVC. Нет я не заядлый критик чего бы то не было, просто я не люблю когда подход или технологию применяют тогда, когда она не нужна. В этой статье, я расскажу один пример, когда эта технология просто необходима. Но внимание - для её реализации вам не нужен никакой фреймфорк, если вы еще не верите в свои силы - я научу вас создавать элегантные решения с минимумом трудозатрат, и тогда когда это нужно :)
По ссылке "Когда нужно MVC, как сделать Binding визуальных контроллов с методом (UNITY, C#, Разработка игр)" вы можете послушать меня, а кто хочет почитать прошу подкат.
⚛ О применении слоеной архитектуры в современном React-Mobx приложении
В данной статье я привожу пример использования композиции сервисов через инъекцию зависимостей в React приложении. Это позволяет сочетать проверенный временем подход и проработанные компоненты от Еnterprise и сообщества
В современном языке Java паттерн Посетитель (Visitor) уже не нужен. Он отлично компенсируется использованием запечатанных типов и переключателей, использующих сопоставление с шаблоном – в таком случае те же цели достигаются проще и меньшим объемом кода.
Всякий раз, оказываясь в ситуации, где мог бы применяться паттерн Посетитель, подумайте, не воспользоваться ли вместо него более современными возможностями языка Java. Разумеется, эти возможности могут использоваться и в других обстоятельствах, но в этой статье мы обсудим сравнительно узкую тему: чем заменить паттерн Посетитель. Для этого я начну с максимально краткого введения и приведу пример, а затем объясню, как достичь тех же целей более простым (и кратким) кодом.
Довольно часто у студентов, изучающих C++ в определённых учебных кругах, складывается мировоззрение о том, что всё должно быть объектами. Попросите их написать программу, которая считает некоторое значение - и они начнут с создания объекта ValueComputer и метода vc.computeResult().
Например: дана задача с помощью динамического программирования посчитать количество способов замостить костяшками домино прямоугольник 
. Студент пишет:
LSP (протокол языкового сервера) сегодня весьма популярен. Есть стандартное объяснение этого феномена. Возможно, ранее вам уже попадалась эта картинка, у нас также являющаяся заглавной.
Считаю, что такое стандартное объяснение популярности LSP – неверное. Ниже предложу вам альтернативную трактовку.
От автора перевода: Написанный далее текст может не совпадать с мнением автора перевода. Все высказывания идут от лица оригинального автора, просьба воздержаться от неоправданных минусов. Оригинальная статья выпущена в 2014 году, поэтому некоторые фрагменты кода могут быть устаревшими или "нежелаемыми".
Содержание статьи:
В статье приведены доводы, которые ставят под вопрос правильность присутствия ORM в рамках ООП.
В этой статье автор высказывает личное мнение, сформулированное на основе его собственного опыта и вкуса. Поэтому просьба не обижаться, если вы с ним не согласны. Конечно, оно может быть ошибочным – но это и стоит обсудить.
(на картинке изображён С++ среди других функциональных языков)
Классы - это скорее всего первое, что добавил Страуструп в далёких 1980х, ознаменовав рождение С++. Если представить, что мы археологи древних плюсов, то косвенным подтверждением этого факта для нас будет this, который по прежнему в С++ является указателем, а значит, скорее всего, он был добавлен до "изобретения" ссылок!
Но речь не про это, пора окинуть взглядом пройденный с тех пор путь, изменение и языка и парадигм, естественный отбор лучших практик, внезапные "великие открытия" и понять к чему это всё привело язык, который когда то вполне официально назывался С с классами (ныне мем).
В конце(СПОЙЛЕР) мы попытаемся превратить С++ в функциональный язык за несколько простых действий.
Для начала рассмотрим базовое применение классов:
Существует множество мнений о возможности применения ООП подходов и паттернов в Rust. Кто-то считает, что полноценного ООП в Rust нет и быть не может. Другие разработчики, наоборот, высказывают мнение, что элементы языка позволяют использовать приёмы из ООП именно так, как их видели создатели этой парадигмы.
В данной статье я постараюсь продемонстрировать, какие идеи и принципы из ООП позволяет реализовать Rust, и как это работает на простых примерах.
Я считаю, что именно агрегаты из Domain-Driven Design лежат в основе поддерживаемых информационных систем. Однако эта концепция малоизвестна за пределами DDD-сообщества и довольно сложна для понимания, поэтому я решил написать очередной пост посвящённый агрегатам. В основном для чтобы структурировать собственное понимание агрегатов и создать "методичку" для своих команд, но и широкой общественности, я надеюсь, этот пост тоже может быть полезен.
В Java можно объявлять переменные в классе, методе, блоке или конструкторе. В зависимости от варианта объявления, у переменной могут быть разные области видимости в программе, а сама переменная может относиться к статическому или нестатическому типу в зависимости от того, где она объявлена.
Основываясь на этих критериях, можно разделить все переменные в Java на следующие типы: локальные переменные, переменные экземпляра и переменные класса. Затемнение и сокрытие переменных происходит, когда оказываются одноименными две переменные в разных областях видимости (в локальной и глобальной области видимости, в родительских и дочерних классах). При таком сценарии используется значение той переменной, которая находится во внутренней области видимости, так как она затемняет/скрывает значение той переменной, что находится во внешней области видимости.
Map - это интерфейс, а HashMap - одна из его реализаций. Тем не менее, в этой статье мы постараемся разобраться, чем полезны интерфейсы, узнаем как сделать код гибче с помощью интерфейсов и почему существуют разные реализации одного и того же интерфейса.
Давайте я сразу зайду с козырей. Сколько ошибок в коде этой функции вы можете найти за 60 секунд?
func NewConnectionString(host, path, database, user, password string, debug bool) string {
return fmt.Sprintf(
"proto://%s/%s?userName=%s&password=%s&database=%s&debug=%t",
host, path, database, user, password, debug,
)
}
Все ошибки в этом довольно небольшом коде найти и обезвредить довольно сложно. Я попробую их сейчас сформулировать и скомпоновать в две основные:
Ладно, признавайтесь — наверняка каждый за 60 секунд смог заметить первую ошибку, но не все из вас смогут заметить вторую. Если ваш список ошибок оказался короче, чем мой — тогда прошу под кат.