Ваше программное обеспечение сломается! Или... скажите своему коду согнуть колено перед мощью разъединения!
Закон Деметры
Вот! Принцип слабой связи для вашего процесса разработки, Закон Деметры. Просто речь идет о том, чтобы не взаимодействовать с незнакомой сущностью. На практике этот принцип используется для каждой функции (для объектно-ориентированной системы), чтобы определить, минимизирует ли она связь или нет.
Любая функция объекта должна вызывать только функции (методы), принадлежащие самой себе, любым параметрам, которые были переданы методу, любому созданному им объекту и любому непосредственно удерживаемому компоненту.
Как я уже писал в своем предыдущем посте, всегда есть компромисс. В этом случае вы получаете более адаптивный и надежный модуль (свободно связанный). Но при затратах вы получите больше времени выполнения и накладных расходов на пространство. Выбирайте с умом и сбалансируйте их с вашей системой.
Метаданные
В своей простой форме метаданные подобны конфигурации. Они могут помочь вам определить поведение вашего приложения, просто изменив его. Это заставляет вас помещать детали в метаданные и абстракции в код.
Это отделит ваш дизайн и сделает систему более гибкой и адаптируемой при некоторых изменениях в деталях. Откладывая детали из самого кода, он будет более надежным и настроит систему без повторной компиляции для каждого изменения в метаданных. Хотя это похоже на конфигурацию системы, она может создать другую систему с другим поведением с тем же движком, поскольку она будет использовать другие метаданные.
Не будь Додо
Не действуйте и не приспосабливайтесь, как додо. Додо — птицеподобное животное, вымершее много десятилетий назад или, может быть, столетия назад. Забавно, что он не похож на других животных, никто не знает, как Додо похож. Но одно можно сказать наверняка, они вымерли, потому что они не могут выжить (не приспособиться) к своему положению и условиям, при которых в то время большинство людей на острове охотятся на них ради их жизни. До тех пор не осталось Додо и заменить на что-нибудь другое.
Из этой истории биологии мы можем реализовать и наш код. Код, который не работает в масштабе или не может адаптироваться, будет заменен. Почему-то код больше не будет работать по мере роста новых технологий и требований бизнеса. Если код не может следовать тенденциям, то его заменят чем-то другим. Какой бы хорошей ни была система, на самом деле мы должны выполнить и удовлетворить бизнес-ценность с помощью нашего кода.
параллелизм
Представьте, что у вас есть 5 строк кода (LoC) для одной функции, которые не зависят друг от друга, но поведение вашего языка программирования не позволяет вам сделать это с таким же параллелизмом, как его выполнение по умолчанию. Это ваш шанс сделать его более эффективным!
Скажем, когда вы запускаете приложение, каждая строка кода выполняет свою работу 3 секунды. Если мы подсчитаем, потребуется 15 секунд, чтобы функция произвела всю строку кода. Что делать, если ваши данные становятся больше? Что, если он увеличится до 10 раз? Что произойдет с вашим нынешним механизмом?
Ответ в том, что это выиграет больше времени, чтобы сделать работу! Как мы могли бы преодолеть эти проблемы? Параллелизм в помощь! Если ваш язык программирования синхронный, сделайте так, чтобы он работал асинхронно, когда это необходимо. В предыдущей задаче мы масштабировались, и наша система, скорее всего, заставит нас сварить кофе, прежде чем она сделает свою работу. Мы могли бы запускать каждую строку кода, не дожидаясь окончания выполнения предыдущей строки.
При такой скорости это заняло бы больше всего времени на любую из тех строк, которые были выполнены. Он будет ожидать выполнения всех этих асинхронныхвыполнений. Это действительно прибыль за счет затрат времени, но опять же, всегда есть компромисс. В этом случае память или любые другие вычислительные ресурсы будут использоваться больше, чем обычно/по умолчанию.
Параллелизм заставит вас подумать о том, чтобы отделить зависимости в любое время и в любом порядке. Это определит, как вы можете управлять ресурсом, а также использовать возможности языка программирования. Будь мудр!
Источники:
Прагматичный программист: от подмастерья до мастера Эндрю Хант и Дэвид Томас
