В своем кратком тексте 1998 года Энди Хант, отталкиваясь от закона Деметры и принципа разделения команд и запросов, просто и понятно излагает один из важных принципов объектно-ориентированного проектирования — «говори, а не спрашивай». Этот принцип учит делегировать объектам ответственность за их данные, что позволяет создавать слабосвязанные и устойчивые к изменениям системы.
Продолжаем серию публикаций, посвященных истокам лондонской школы тестирования. В статье «Мокируем роли, а не объекты» (2004) авторы совершают ключевой концептуальный переход. Они переосмысливают мок-объекты: из инструмента для изоляции тестов они становятся инструментом для выявления интерфейсов, проектирования взаимодействий между объектами и создания целостной архитектуры системы.
Меня зовут Степан, я C# профессионал уже более 7 лет на рынке и рассказываю об этом в Telegram каналe StepOne. В этой статье я покажу вам личную подборку 9ти underground NuGet пакетов. Вы наверняка не встречали их на работе, потому что они либо решают конкретную специальную задачу, либо решают известные задачи нестандартным подходом, либо ещё недостаточно известны на рынке РФ. Мне же удалось затащить их на прод и пощупать в бою!
Когда я был разработчиком я задавался вопросами: как разделить код на классы? какие модули выделить?
Когда я стал архитектором я задавался вопросами: зачем же мы наплодили 200 микросервисов? стоит ли выделять новый или пора объединять?
Когда я стал руководителем я задавался вопросами: как разделить людей на команды разработки? стоит ли создавать новый отдел или расширить ответственность старого?
И всё это хотелось сделать оптимальным эффективным образом.
И я понял, что все эти вопросы сводятся к ряду единых принципов о том как делить, которые можно применять на любом уровне. И этим важным для себя осознанием, после 20 лет в разработке, я хочу поделиться.
Метод программирования, именуемый аспектно-ориентированным, впервые явился миру в конце девяностых годов прошлого века, когда группа исследователей из Xerox PARC под руководством Грегора Кичалеса решила, что объектно-ориентированного подхода человечеству недостаточно. Они создали AspectJ — расширение для Java, призванное разрешить проблему, которую окрестили «сквозной функциональностью». Суть проблемы проста до безобразия: код логирования, обработки ошибок, проверки прав доступа и прочих служебных радостей размазывается по всему приложению, как масло по по́лу, превращая элегантную бизнес-логику в свалку повторяющихся конструкций.
Аспектно-ориентированное программирование предлагает выделить эти сквозные concerns в отдельные сущности — аспекты, которые можно применять к коду декларативно, не засоряя основную логику техническими деталями. В теории звучит как серебряная пуля. На практике AspectJ оказался инструментом, требующим от программиста понимания магических pointcut expressions и готовности смириться с тем, что код компилируется через специальный компилятор, производящий байткод, который отладить можно только с поллитрой, бубном или молитвенником.
Разработчик, знающий только одну парадигму программирования, напоминает плотника, у которого в ящике с инструментами лежит один-единственный молоток. Конечно, молотком можно идеально забить гвоздь. Или шуруп, если приложить достаточно рвения. Но попробуйте этим молотком распилить или отшлифовать доску — и сразу станет ясно, — при условии, что вам доводилось видеть в жизни пилу или рубанок, — что инструмент выбран неудачно. Так и с парадигмами: знание только императивного программирования или только объектно-ориентированного подхода превращает разработчика в механического исполнителя задач, неспособного увидеть элегантное решение там, где оно лежит на поверхности.
Узость кругозора программиста, застрявшего в одной парадигме, проявляется во всем. Он будет городить циклы там, где достаточно одной функции высшего порядка. Плодить классы и наследование там, где хватило бы чистой функции и композиции. Попытается решить задачу верификации корректности алгоритма отладчиком и тестами вместо того, чтобы доказать её формально на уровне типов. Такой разработчик похож на туриста, который знает только одно слово на иностранном языке и пытается с его помощью объяснить таксисту маршрут через весь город. И хорошо еще, если это слово — не обсценно.
Как работает чистый код?
Ниже моё облыжное мнение о том, почему «Чистый код» — чистой воды инфоцыганщина, и почему если вы слышите в аргументации собеседника эти слова — нужно бежать, ведь разговаривать с зомби бессмысленно.
В октябре 1998 года, разочарованный упрощенным пониманием ООП, Алан Кей написал сообществу Squeak знаковое письмо. В нем он напомнил, что главная идея Smalltalk, о которой все забыли, — это не классы, а отправка сообщений. Это письмо стало манифестом, отделяющим оригинальную философию объектов от ее популярной интерпретации. Публикуем перевод этого короткого, но исторически важного документа.
Python часто начинают осваивать с простых скриптов и функций. Пока задачи простые, этого достаточно. Но когда в коде появляются сущности, например, пользователи, книги или машины, взаимодействие с ними строится по другим принципам.
Для этого в Python используют классы. С их помощью описывают, какие данные есть у таких сущностей (объектов) и что с ними можно делать. Это и есть объектно-ориентированный подход — программа строится вокруг объектов и их взаимодействия.
В этой статье мы разберём основы работы с классами и объектами в Python: как они устроены, как их использовать и какие концепции вокруг них стоит знать, даже если вы пока не планируете углубляться в архитектуру.
Кажется, что оборачивать 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
