Цитаты из книги «Чистая архитектура. Искусство разработки программного обеспечения»

1. «Сначала заставьте его работать». Вы останетесь не у дел, если он не работает. 2. «Затем перепишите его правильно». Реорганизуйте код, чтобы вы и другие смогли понимать и развивать его, когда потребуется что-то изменить или понять. 3. «Затем заставьте его работать быстро». Реорганизуйте код, чтобы добиться «необходимой» производительности.

Все архитектуры подчиняются одним и тем же правилам!

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

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

LSP: Liskov Substitution Principle – принцип подстановки Барбары Лисков. Определение подтипов Барбары Лисков известно с 1988 года. В двух словах, этот принцип утверждает, что для создания программных систем из взаимозаменяемых частей эти части должны соответствовать контракту, который позволяет заменять эти части друг другом.

переменные в функциональных языках не изменяются.

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

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

Код, реализующий высокоуровневую политику, не должен зависеть от кода, реализующего низкоуровневые детали. Напротив, детали должны зависеть от политики.

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