ООП *

Привет, Хабр! В последнее время уделяю много внимание архитектуре и решил поделиться с сообществом переводом статьи Clean Architecture with Typescript: DDD, Onion автора André Bazaglia.

Введение

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

Целью данной статьи является не детальное покрытие сложных тем по DDD и Слоистой архитектуре, а пример реализации этих двух подходов в Typescript. Используемый проект является базовым и может быть доработан и расширен, например с использованием подхода CQRS.

Многим не хватает графиков в Notion'e. Поэтому я решил напилить автоматическую штуку для их генерации.

Вот как это выглядит с моей стороны:


Всех интересующихся, как это реализовано, прошу под кат.

Я решил написать конспект книги, которая всем известна, а сам автор называет ее «Школой учителей Чистого кода». Пристальный взгляд Мартина как бы говорит:

«Я тебя насквозь вижу. Ты опять не следуешь принципам чистого кода?»

Привет, Хабр! Представляю вашему вниманию перевод статьи "Functional PowerShell with Classes.
I promise it’s not an oxymoron" автора Christopher Kuech.

Объектно-ориентированная и функциональная парадигмы программирования могут казаться не в ладах друг с другом, но обе в равной мере поддерживаются в Powershell. Практически все программные языки, функциональные и нет, имеют средства расширенного связывания имён и значений; Классы, подобно struct-ам и record-ам, это всего лишь один подход. Если мы ограничим использование Классов связыванием имён и значений и станем избегать таких "тяжёлых" объектно-ориентированных программных концепций, как наследование, полиморфизм, или изменяемость (mutability), мы сможем использовать их преимущества, не усложняя наш код. Далее, добавляя неизменяемые (immutable) методы преобразования типов, мы можем обогатить Классами наш функциональный код.

Магия кастов

Касты одна из самых мощных фич в Powershell. Когда вы подвергаете значение касту, вы полагаетесь на добавляемую средой в ваше приложение возможность неявных инициализации и валидации. Например, простой каст строки в [xml] прогонит её через код парсера и сгенерирует полное дерево xml. Мы можем в своём коде использовать Классы с той же целью.

Вы наверняка слышали это знаменитое высказывание от GoF: «Предпочитайте композицию наследованию класса». И дальше, как правило, шли длинные размышления на тему того, как статически определяемое наследование не настолько гибко по сравнению с динамической композицией.

Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования тоже проблемы. «И что же теперь, не использовать наследование вообще?» – спросите Вы.

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

Проблема хрупкого базового класса

— Сколько нужно архитекторов, чтобы реализовать язык программирования?
— Сто. Один будет писать реализацию, а 99 — говорить, что могут сделать лучше.

В этой статье я хочу затронуть не столько сам язык, сколько детали реализации CPython и его стандартной библиотеки, которые гарантируют, что у вас не будет никаких простых способов сделать приложение на питоне ни многопоточным, ни быстрым, ни легко поддерживаемым, и почему было создано столько альтернативных реализаций (PyPy, Cython, Jython, IronPython, Python for .NET, Parakeet, Nuitka, Stackless, Unladen Swallow), половина из которых уже умерла; и мало кто понял, почему у альтернатив не было шансов победить в борьбе за выживание против других языков. Да, есть GDScript, который призван решить проблемы с производительностью, есть Nim, который призван решить вообще все проблемы, не обязывая при этом пользователя чрезмерно явно объявлять типы. Однако, учитывая огромную инертность индустрии, я осознаю, что в ближайшие 10 лет новые языки точно не займут значимой ниши. Однако, я верю в то, что питон возможно сделать эффективным, изменив стиль написания кода, по большей части сохранив оригинальный синтаксис, и полностью сохраняя возможность взаимодействия кода нового и старого стиля. Я буду концентрироваться на проблемах CPython, а не ближайшего его конкурента, PyPy, поскольку PyPy на самом деле прыгает вокруг всё тех же проблем CPython.

Источник: Ward Cunningham

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

Если необходимо переключиться на другой язык, транспилеры помогут разработчикам сохранить бóльшую часть существующего кода, не переписывая весь код вручную. Например, при преобразовании программ из Python 2 в Python 3, или при переносе софта от старого API в новый.

Термины «транспилер» и «транскомпилятор» часто взаимозаменяемы, но все же считается, что различия есть. Например, для преобразования кода C++ в C потребуется транспилер, а для конвертации Python-Ruby — транскомпилятор. Babel для JavaScript — это транспилер, а TypeScript — транскомпилирумый язык.

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

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

Однажды подобный код попался мне на глаза.

Что такое магия в PHP? Обычно под этим подразумевают методы вроде _construct() или __get(). Магические методы в PHP — это лазейки, которые помогают разработчикам выполнять удивительные вещи. В сети полно инструкций по их использованию, с которыми вы наверняка знакомы. Но что если мы скажем, что вы даже не видели настоящую магию? Ведь, чем больше вам кажется, что вы знаете все, тем больше магии ускользает от вас.



Давайте отбросим установленные рамки правил ООП и сделаем невозможное возможным в школе магии PHP. Главный и первый волшебный преподаватель школы — Александр Лисаченко (NightTiger). Он научит магическому мышлению и, возможно, вы полюбите магические методы, нестандартные способы доступа к свойствам, изменение контекстов, аспектно-ориентированное программирование и потоковые фильтры.

В этой статье я постараюсь рассказать о принципе проектирования, называемом Inversion of Control / Инверсия управления (IoC), называемом еще Голливудским принципом. Покажу, какое отношение это имеет к принципу подстановки Барбары Лисково (LSP), а также внесу свою лепту в священную войну private vs protected.

Руководящая философия

1. Языки программирования для людей

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

Оглавление

Предисловие
Краткий обзор ES7
1. Object.entries
2. Object.values
3. String.prototype.padEnd
4. String.prototype.padStart
5. Object.getOwnPropertyDescriptor
6. Trailing commas
7. SharedArrayBuffer
8. Atomics
9. Async functions

Предисловие

Здравствуйте, в прошлом я уже рассматривал нововведения в ES6 и теперь время разобрать ES8 так как он принёс много нового. Рассматривать отдельно ES7 (2016), я не стал так как этот релиз принёс всего 2 нововведения. Это Array.prototype.includes() и оператор возведения в степень. Но всё же прежде чем приступить к ES8, давайте рассмотрим нововведения из ES7.

Краткий обзор ES7

Метод includes() определяет, содержит ли массив определённый элемент, возвращая в зависимости от этого true или false.

Array.prototype.includes(searchElement[, fromIndex = 0]) : Boolean

searchElement — Искомый элемент.

fromIndex — Позиция в массиве, с которой начинать поиск элемента searchElement. При отрицательных значениях поиск производится начиная с индекса array.length + fromIndex по возрастанию. Значение по умолчанию равно 0.

Если вы иногда задаете себе вопрос: «а всё ли хорошо мне в этот метод приходит?» и выбираете между «а вдруг пронесет» и «лучше на всякий случай проверить», то добро пожаловать под кат…

C++ — язык запутанный, и существенным его недостатком является сложность создания изолированных блоков кода. В типовом проекте всё зависит от всего. Эта статья показывает, как писать высокоизолированный код, который минимально зависит от конкретных библиотек (включая стандартные), имплементаций, сведя зависимость любого куска кода к набору интерфейсов. Помимо этого будут предложены архитектурные решения по параметризации кода, которые могут заинтересовать не только программистов на C++, но и программистов на Java. И что важно, предложенное решение весьма экономично по времени разработки.

Привет, Хабр!

Сегодня мы затронем важнейшую тему: интероперабельность Java и Kotlin. Авторы предлагаемой публикации разумно предполагают, что переписать на Kotlin базу кода, сделанную на Java, маловозможно. Поэтому правильнее обеспечить взаимодействие кода на Java и Kotlin. Читайте, как это можно сделать при помощи аннотаций.

Рассказ про специфичную предметную модель, где многие допустимые значения полей зависят от значений других.

Задача

Разобрать легче на конкретном примере: надо конфигурировать датчики с множеством параметров, но параметры зависят друг от друга. Например, порог срабатывания зависит от типа датчика, модели и чувствительности, а возможные модели зависят от типа датчика и т.д.

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

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

Привет, Хабр! Перед вами перевод статьи Роберта Мартина Open-Closed Principle, которую он опубликовал в январе 1996 года. Статья, мягко говоря, не самая свежая. Но в рунете статьи дяди Боба про SOLID пересказывают только в урезанном виде, поэтому я подумал, что полный перевод лишним не будет.

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

• Ни одну программу нельзя «закрыть» на 100%.
• Объектно-ориентированное программирование (ООП) оперирует не физическими объектами реального мира, а понятиями — например, понятием «упорядочивание».

Привет, Хабр!

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

В своей предыдущей статье "Рукоблудие вокруг ImmutableList в Java" я предложил вариант решения поднятой в статье "Неизменяемых коллекций в Java не будет – ни сейчас, ни когда-либо" проблемы отсутствия в Java неизменяемых списков.

Решение тогда было проработано только на уровне «есть такая идея», а реализация в коде была кривовата, поэтому и воспринято всё было несколько скептически. В данной статье предлагаю доработанный вариант решения. Логика использования и API доведены до приемлемого уровня. Реализация в коде – до уровня бета-версии.