ООП *

В этой статье мы продолжим разбирать содержание работы Stephen Toub-а: «How Async/Await Really Works in C#». В этот раз, в след за автором исходного Поста мы рассмотрим код, который генерирует C# компилятор для реализации асинхронных вызовов и множество связанных с этим сущностей-понятий-приемов, таких как: контекст исполнения, боксинг, стейт машина, стек, потоки, … Эта 6-я часть, пожалуй, основная часть всей работы, которая непосредственно отвечает на вопрос: «Как на самом деле Async/Await работают (и компилируются) в C#»

Там, где мне придется цитировать содержание исходного текста в переводе (то есть более-менее дословно переводить), оно будет выделено подчеркнутым курсивом.

Возможно вам будет интересно сравнить эту мою работу с первоначальным переводом.

В 1978 году вышел третий том монографии Дональда Кнута «Искусство программирования», где автор рассматривает алгоритмы сортировки и поиска. Помимо самих алгоритмов описаны аппаратные характеристики компьютера и их влияние на производительность при работе с алгоритмами.

В 2024 году мы с вами возьмём классические алгоритмы сортировки и посмотрим, как работает современный многоядерный процессор при сортировке нескольких массивов на одном и нескольких логических ядрах. Мы напишем приложение с графическим интерфейсом (GUI) на фреймворке Qt, обойдем глобальную блокировку интерпретатора (GIL), воспользуемся несколькими потоками, на один из которых переложим выполнение асинхронного цикла событий, и распараллелим этот поток для реализации параллельных вычислений.

«ООП для меня означает лишь обмен сообщениями, локальные ограничения и защиту, сокрытие состояния процесса и крайне позднее привязывание», — Алан Кэй (человек, придумавший термин «объектно-ориентированное программирование»)¹

Возможно 11 подписчиков моего блога обратили внимание на тот факт, что все мои статьи касаются языка Wolfram, а несколько последних статей вышли довольно громоздкими. Одна из последних статей была помечена Хабром как требующая в среднем 32 минуты на прочтение. Я посчитал, что это может отпугнуть пользователей (все 11 человек и не факт, что все они до сих пор читают Хабр) и решил попробовать писать более короткие статьи. Плюс я сам перестану теряться в большом количестве текста.

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

Ниже реализация структуры данных LinkedList на Wolfram Language.

Привет!

Сегодня я хочу поговорить про GRASP. В то время как многие знакомы с SOLID, GRASP, хотя и известен, мало кто в геймдеве воспринимает его всерьёз (или хотя бы знают о нем). GRASP расшифровывается как общие шаблоны распределения ответственностей. Самые часто упоминаемые принципы GRASP известны гораздо шире, чем сам список, в который они включены. Это знаменитые слова про низкую связность и высокое зацепление.

В этой статье представлены такие паттерны, как Abstract Document, Monad, Object Mother, Object Pool, Step Builder. Примеры приведены на .NET 7 и C#. Приятного чтения.

Продолжение в статье "Сто паттернов для разработки корпоративных программ. Часть 2.2".

В этой статье рассмотрены все паттерны проектирования из "Банды четырёх" с примерами на языке программирования C#. Для самых терпеливых имеются дополнительные паттерны.

Это первая статья из серии "Сто паттернов для разработки корпоративных программ". Следующие статьи будут посвящены паттернам из книг Мартина Фаулера и Роберта Нистрема.

Привет всем. Меня зовут Артурас, я пишу на Javascript. Полтора года назад я уволился из оффшорной компании и решил написать свой движок для браузерных 2d игр. Сегодня - делюсь результатами.

И снова всем привет! Продолжение к переводу второй части книги Patterns.dev

В ней речь идет про паттерны производительности. Узнайте, как оптимизировать последовательность загрузки, чтобы повысить скорость использования вашего приложения и др.

Напомню, что авторы Patterns.dev:
Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.
Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed ​​Insights, Chrome User Experience Report и другими.

Материал книги будет полезен не только React‑разработчикам, но и всем, кто так или иначе интересуется или сталкивается с frontend‑разработкой. Это ознакомительная часть перевода учебника https://www.patterns.dev/. Перевод всей третьей части учебника можно найти здесь.

P. P. S.: Третья часть взята из книги: https://www.patterns.dev/, переведена на русский язык. Книга находится под лицензией CC BY-NC 4.0

Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

Сразу хочу отметить перед читателем, что это не просто вольные рассуждения на тему, а в том числе и презентация моей библиотеки для Python, которую можно найти на github и установить через pip, и которая трудится в моей многопользовательской игре как SQL движок проекта.

Проблемы ORM известны всем, кто хоть раз ими пользовался. Об этом существует множество статей как у нас, так и в зарубежных источниках. Эти проблемы в общем можно объединить довольно сложным термином Object‑relational impedance mismatch, что позволю себе вольно перевести как «Объектно‑реляционная разница потенциалов».

Альтернативой использованию ORM всегда было использование чистых драйверов баз данных и написание сырых SQL запросов, которые в свою очередь очень тяжело поддерживать и рефакторить в реальных проектах.

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

В PHP 8.0 добавлен класс mixed. Тип mixed принимает любое значение. Он эквивалентен объединённому типу object|resource|array|string|float|int|bool|null. Доступно, начиная с PHP 8.0.0.

mixed - это, говоря языком теории типов, высший тип. Это означает, что все остальные типы являются его подтипами.

Шаблоны проектирования в ООП делятся на 4 принципиально разных подтипа:

Принято считать, что программирование это сложно, но это миф (все проще чем кажется), и все что нужно чтобы стать программистом это немного упорства и изобретательности.

В этой статье мы получим все базовые навыки, которые нужны Delphi программисту (включая базовые знания RunTime, работу с Com-объектами и Canvas, вводом\выводом, файлами, парсингом, ооп, и тд), по окончании статьи.

Это перевод вступления из электронной книги - документа.

Авторы утверждают что:

В этой главе вы увидите, как можно удовлетворить некоторые из распространенных требований корпоративных приложений (приложений для бизнеса), таких как низкая стоимость (простота) сопровождения и тестируемость, применяя слабосвязанный дизайн для вашего приложения. Вы увидите очень простую иллюстрацию этого подхода в примерах кода, которые показывают два разных способа реализации зависимости между классами ManagementController и TenantStore. Вы также увидите, как принципы объектно-ориентированного программирования SOLID связаны с теми же проблемами (имеются ввиду проблемы стоимости сопровождения = исправления ошибок + возможности расширения функциональности и тестируемости).

На конец 2023 года язык программирования Python является самым популярным по индексу TIOBE. Что касается работы, то по количеству вакансий в мире язык Python занимает второе место (после JavaScript/TypeScript). Поэтому у соискателей на должность, где требуется Python, возникает потребность подготовки к собеседованиям.

В этой статье я расскажу о том, как используя Python, можно написать desktop-приложение для ОС Windows, которое поможет быстро, эффективно и абсолютно бесплатно подготовиться к собеседованиям по Python.

В ходе обсуждений докладов на Analyst Days возник вопрос о связи Domain-driven design (DDD) с объектно-ориентированным подходом (ООП): оказывается, для большинства она вовсе не так очевидна, как мне представлялось. Подробнее погружаясь в это обсуждение, я понял, что для современной разработки их общность действительно не очевидна, а практики DDD можно применять, не связывая с ООП. Я думаю, что подробное рассмотрение этого вопроса будет полезно для получения комплексного представления и понимания DDD, что сделает его применение эффективнее.

Как известно нет ничего более постоянного чем временное. Нам нужно было сделать по возможности простую программу для визуализации сложных структур бинарных данных, считанных из разных типов-версий устройств.

Адаптированный проект для публичного использования, рабочий на Гите, компилируется в простой exe-файл. Можно скачать как exe-файл, если доверяете своему антивирусу.  Надеюсь, кому-то пригодится. Но чтобы начать пользоваться надо научиться писать XАML определения вложенных структур, по которым работает парсер. Ссылка в конце статьи.

Не будет никаких модных слов, только то, что нужно для работы.

В комментариях к мой статье пользователь @Refridgeratorв ответ на мой вопрос написал, что в Wolfram Language (WL) не хватает следующего:

"ООП, перегрузки операторов, строгой типизации, событийно-ориентированного
программирования, дата-ориентированного программирования, параллельного программирования с примитивами синхронизации, средств отладки, скорости исполнения." (с) @Refridgerator

Я отлично понимаю, что вокруг Mathematica сложились некоторые исторические стереотипы. В них обычно WL представляется как калькулятор на стероидах или просто игрушка, или больше язык запросов, которым можно дополнительно решать уравнения и строить графики. Сегодня я попытаюсь показать, что в языке есть не только лишь графики, уравнения и интегралы. Вряд ли у меня хватит сил написать подробно касательно каждого пункта списка, но я постараюсь объяснить хотя бы часть.

Каждый разработчик рано или поздно сталкивается с моментом, когда стандартные решения перестают справляться с возросшими требованиями проекта. Именно в этот момент стоит рассмотреть паттерн "Абстрактная фабрика" — один из мощных инструментов, который помогает строить системы, готовые к расширениям и изменениям. Это не просто шаблон проектирования, это целая философия построения многогранного, но при этом структурированного кода.

Что вообще хотим увидеть:

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

Тему предваряет обзор материалов, которые я использовал при написании своей статьи, в одном из которых есть сравнение C# делегатов с техникой которая заменяет их использование на Java, которое я тоже собираюсь проанализировать в конце.