ООП *

Кажется, что оборачивать BigDecimal и String в отдельные классы — это overengineering и преждевременный DDD. Но именно из-за этих «лишних» типов в прод не пролезают посылки в ПВЗ, проценты внезапно превращаются из 0.8 в 80, а деньги теряют валюту и смысл. В статье на реальном примере логистики разбираем, как один небольшой record Weight и несколько аккуратных Value Object’ов наводят порядок в бизнес-логике: инварианты перестают жить в комментариях, проверки перестают дублироваться, а код начинает читаться как текст предметной области. Без внедрения полного DDD, без религиозного фанатизма — только практические шаги.

Экспериментальная система сериализации графов объектов с самоописанием, миграциями и живой отладкой — без VM и без JSON

О чём статья:

долгоживущие(сохранение всего runtime-состояния) программы и движки

загрузка старых данных в новую(с обновлённой системой типов) версию бинарника

правка состояния на лету без перезапуска

без виртуальной машины

без замедления в 10–50 раз

Почему стандартные форматы не подходят:

они работают с деревьями, а не с графами

не умеют циклы и самоссылки

ломаются при изменении структуры типов

Что будет показано:

сериализация объектных графов с циклами

самоописание типов прямо в файле

миграция данных при удалении и перестановке полей

какие идеи оказались тупиком, а какие — нет

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

Язык программирования C#, несмотря на то, что обеспечивает автоматическое управление памятью с помощью механизма сборки мусора (GC), требует от разработчиков специальных знаний и навыков для оптимизации работы с памятью.

Всем привет, это Stalker320. Я вернулся на Хабр, осознав несколько концепций, с интересным подходом к разработке ПО с использованием Си.

Документация может спасти проект или убить его, если подойти к ней без дисциплины

В этой статье системный аналитик Влад показывает, как применять инженерные принципы — SRP, SSOT, ООП — не к коду, а к аналитике, описанию систем и документированию решений.

Наверное, каждый программист, работавший с объектно-ориентированными языками, хотя бы раз слышал о законе Деметры. Многие знают его смысл, но мало кто читал оригинальный текст 1989 года, где закон был не только сформулирован, но и подробно обоснован. В этой статье авторы, Карл Либерхер и Иэн Холланд, рассказывают о проекте «Деметра», дают строгие формулировки для разных языков и обсуждают, когда законом можно пренебречь.

Три способа менять один объект из нескольких потоков. Больше нет

Mutex, CAS, акторы, STM, CRDT, иммутабельность, MVCC, Disruptor…

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

На самом деле их ровно три. Всё остальное — реализации и комбинации.

Эта статья — попытка навести порядок в голове. После неё вы сможете:

за 5 секунд классифицировать любой подход к конкурентности;
понимать, почему Erlang выбрал акторы, а Java предлагает synchronized;
не изобретать велосипеды и не зацикливаться на «единственно правильном» решении;
проектировать многопоточный код, держа в голове простую модель.

Заодно, покажу почему ООП вообще не было изначально спроектировано под многопоток.

Команда Python for Devs подготовила перевод статьи о том, почему автору SQLAlchemy нравится… но не настолько, чтобы не попробовать создать собственный ORM. SQLORM ― минималистичный, прямолинейный и честный: никакой магии, никаких скрытых Unit of Work, максимум контроля над SQL и минимум связности с сессией.

На собеседованиях часто можно услышать вопрос: «Назовите принципы хорошего кода». Даже начинающие, но уже имеющие практический опыт программисты интуитивно понимают: хороший код — это читаемый, переиспользуемый, легко расширяемый и поддерживаемый. Но что обеспечивает эти качества? Ответ кроется в объектно-ориентированном программировании (ООП).

Когда хорошая идея становится популярной - все начинают пересказывать её "как поняли". В итоге в информационном поле от изначальной идеи остаётся настолько мало, что её перестают воспринимать всерьёз. В этой статье я хочу рассказать о двух таких идеях: Scrum и ООП

Всё началось с подготовки к финалу RuCode – масштабному соревнованию для всех увлечённых алгоритмическим программированием. Погружаясь в разбор заданий прошлых лет, мне кое-что совершенно случайно попало в руки, интересная задача: реализовать шахматы с "туманом войны" в консоли

Идея показалась мне настолько вдохновляющей, что я решил пойти дальше, а что если превратить эту консольную головоломку в настоящую игру с графикой и той самой атмосферой тумана войны, который так знаком игрокам в стратегиях

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

Так обычная подготовка к соревнованиям превратилась в увлекательный эксперимент, результатом которого стала эта статья и реализация шахмат с туманом войны на Python

Мат рождается в душе. Больше всего его рождается когда сталкиваешься с чем-то похожим на <подставь свой фреймворк>. Инструмент с прекрасными целями и задачами постепенно превращается во все больший и больший кусок г.. в котором приходиться копаться. Ощущаешь себя жужжащей мухой, летающей вокруг по необходимости.

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

Сейчас все поменялось.
Подключение новой фичи чаще всего присоединяет к твоему коду 100500 дополнительных фиговин, которые мало того, что чаще не нужны, но и которые мешают запустить твой код.
Они подключаются по дефолту сами, и ты ищешь как их отключить. Но так как библиотеки постоянно меняются, это не так просто. Сколько раз подключал <подставь свой фреймворк>, ещё не разу не было одинакового кода. Постоянно меняются названия методов, их параметры, типы.

Раньше было просто. Возьмем для примера <подставь свой фреймворк>. Ты подключал и говорил ему, что нужно делать в первом случае, что во втором, что в третьем.
Сейчас же так просто не работает. Все стало сложнее. Ты указываешь доступный всем метод по старинке, но не тут то было. Клиенты получают в ответ фигу. Ты думаешь, что поменялся синтаксис, ищешь новые незадеприкейчаные методы (которых по количеству уже меньше, чем задеприкейчаных), но все равно клиенты получают фигу. Один и тот же код разрешает пользователям работать с одними запросами, но не разрешает с другими. Уверен, что это как-то объясняется. Просто подключается ещё куча бинов по дефолту, с доп параметрами по дефолту, и т.д. Идеология упрощения.
Но то, что прямо игнорируется команда разработчика, это уже перебор.

В парадигме ООП объекты взаимодействуют друг с другом. Первоначальная идея такого взаимодействия, впервые появившаяся в языке Smalltalk, заключалась в том, что объект A отправлял сообщение объекту B. В языках, разработанных позднее, используется вызов методов. В обоих случаях возникает один и тот же вопрос: как объект ссылается на другие объекты, чтобы достичь желаемых результатов?

В этой статье я рассматриваю проблему передачи зависимостей объекту. Я рассмотрю несколько вариантов и проанализирую их преимущества и недостатки.

Введение

Мы часто говорим об алгоритмах как о «сердце» любой сложной системы. В контексте нашей платформы Гриндаты алгоритмы — это не просто код. Представьте, что данные — это деньги или документы клиентов, а алгоритмы — это инструкции и правила, которые позволяют быстро находить, сортировать, обрабатывать и сохранять эти «деньги/документы».

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

Формулы удачного написания алгоритма не существует, поскольку задачи всегда разного толка и сложности. Однако понимание основных парадигм программирования — это первый и главный ключ к написанию оптимально работающих алгоритмов. Наши алгоритмы являются мультипарадигменными, поэтому рассмотрим два основных подхода, лежащих в их основе: ООП и ФП.

Концептуальная основа: ООП (Объектно‑ориентированное программирование)

Концепция ООП лежит в основе структуры и окружения нашей платформы. Понимание ООП необходимо аналитику для:

Доброго времени суток дорогой читатель!

Всё последующее содержание статьи очевидно является некой формой садизма, так что если если вы пришли за чоколадкой golangом, питоном, ванильным чапманом или другими формами сладкой жизни, лучше уходите.

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

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

Компромиссным решением является выделение идентичных по содержимому (таблицам) схем для каждого нового клиента в одной базе данных. Таким образом мы получаем относительную защиту от утечек данных между клиентами с минимальными затратами на аренду новых серверов. Именно этот вариант мы и будем рассматривать.

Именно с публикации этой статьи в 2000 году берет свое начало формирование лондонской школы тестирования, также известной как «мокистская» школа. В ней авторы не только вводят ключевые концепции мок-объектов и эндотестирования, но и закладывают методологический фундамент подхода, принципиально изменившего практику юнит-тестирования — подхода, основанного на явном определении взаимодействий между объектами, замене зависимостей и тестировании поведения системы изнутри.

Команда Go for Devs подготовила перевод статьи о том, как работает сборщик мусора в Go. Автор подробно объясняет семантику алгоритма триколорной маркировки и очистки, механизмы Stop The World, пейсинг и источники задержек. Главное — не бороться со сборщиком, а работать с ним в унисон: устранять лишние выделения и снижать нагрузку на кучу.

Оригинал

В 2003 году Алан Кей, признанный автор термина «объектно-ориентированное программирование», ответил на вопросы исследователя Штефана Рама. В этом письме он раскрывает первоначальный замысел ООП, который значительно отличается от того, чему большинство из нас учат сегодня. Публикуем перевод этого исторического документа.

Достаточно часто в реализации сервисов есть необходимость оперировать денежными единицами, хранить их в БД, обмениваться по API и выполнять конвертацию

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