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

Все аспекты конструирования помещаются в main или в модули, вызываемые из main.

Если момент создания объекта должен определяться приложением, то использовать паттерн «Фабрика».

Вся информация о конструировании хранится на стороне main.

Приложение изолировано от подробностей построения.

Использовать внедрение зависимостей Dependency Injection или обращение контроля Inversion of Control для отделения конструирования от использования.

Итеративная разработка – сегодня реализуем текущие потребности, а завтра перерабатываем и расширяем систему для реализации новых потребностей.

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

Компонент-сущность (entity bean) – представление реляционных данных в памяти.

Применять АОП – модульные конструкции, называемые аспектами, определяют, в каких точках системы поведение должно меняться некоторым последовательным образом в соответствии с потребностями определенной области ответственности (изменения вносит инфраструктура без необходимости вмешательства в целевой код).

Посредники (proxies) хорошо подходят для простых ситуаций – вызова методов отдельных объектов или классов.

Использовать POJO-объекты.

DAO – Data accessor object – объект доступа к данным.

Использовать aspectJ.

Не полагаться на BDUF.

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

Хороший API должен исчезать из вида большую часть времени.

Один человек не может принять все необходимые решения.

Принятие решений лучше всего откладывать до последнего момента.

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

Главная задача – реализовать интересы клиента.

Использовать DSL (их код читается как структурированная форма текста, написанного экспертом в данной предметной области).

Используйте самое простое решение из всех возможных.

Четыре правила простой архитектуры:

– архитектура обеспечивает прохождение всех тестов;

– не содержит дублирующегося кода;

– выражает намерения программиста;

– использует минимальное количество классов и методов.

Система должна делать то, что задумано ее проектировщиком.

Существует простой способ убедиться в том, что система действительно решает свои задачи.

Система, тщательно протестированная и прошедшая все тесты, контролируема.

Обеспечение полной контролируемости системы повышает качество проектирования.

Для системы необходимо написать тесты и постоянно выполнять их.

Рефакторинг – последовательная переработка кода.

Рефакторинг проводится при наличии полного набора тестов.

В системе не дублируется реализация.

Применять повторное использованием даже в мелочах.

Дублирование – главный враг системы.

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

Постараться сделать код выразительным.

Неравнодушие – драгоценный ресурс.

Использовать прагматичный подход взамен бессмысленного догматизма.

Применять нагрузочное тестирование.

Многопоточность – стратегия устранения привязок.

Многопоточность – аналогия работы нескольких компьютеров.

Многопоточность повышает быстродействие не всегда.

Многопоточность может изменить архитектуру.

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

Многопоточность требует больше производительности и кода.

Правильная реализация многопоточности сложна.

Ошибки в многопоточности обычно не воспроизводятся.