Всего за 0.01 руб. Купить полную версию
Время, необходимое для понимания класса, падает почти до нуля.
Вероятность того, что одна из функций нарушит работу другой, ничтожно мала.
Принцип открытости-закрытости: классы должны быть открыты для расширений, но закрыты для модификации.
Структура системы должна быть такой, чтобы обновление системы создавало как можно меньше проблем.
В идеале новая функциональность должна реализовываться расширением системы, а не внесением изменений в существующий код.
С помощью интерфейсов и абстрактных классов класс изолируется от конкретных подробностей.
Принцип обращения зависимостей: классы системы должны зависеть от абстракций, а не от конкретных подробностей.
В программных системах фаза инициализации, в которой конструируются объекты приложения и «склеиваются» основные зависимости, должна отделяться от логики времени выполнения, получающей управление после ее завершения.
Инициализация область ответственности.
Код инициализации пишется системно и отделен от логики времени выполнения.
Удобные идиомы не ведут к нарушению модульности.
Приложение ничего не знает о main или о процессе конструирования.
Все аспекты конструирования помещаются в main или в модули, вызываемые из main.
Если момент создания объекта должен определяться приложением, то использовать паттерн «Фабрика».
Вся информация о конструировании хранится на стороне main.
Приложение изолировано от подробностей построения.
Использовать внедрение зависимостей Dependency Injection или обращение контроля Inversion of Control для отделения конструирования от использования.
Итеративная разработка сегодня реализуем текущие потребности, а завтра перерабатываем и расширяем систему для реализации новых потребностей.
Архитектура программных систем может развиваться последовательно, если обеспечить правильное разделение ответственности.
Компонент-сущность (entity bean) представление реляционных данных в памяти.
Применять АОП модульные конструкции, называемые аспектами, определяют, в каких точках системы поведение должно меняться некоторым последовательным образом в соответствии с потребностями определенной области ответственности (изменения вносит инфраструктура без необходимости вмешательства в целевой код).
Посредники (proxies) хорошо подходят для простых ситуаций вызова методов отдельных объектов или классов.
Использовать POJO-объекты.
DAO Data accessor object объект доступа к данным.
Использовать aspectJ.
Не полагаться на BDUF.
На каждом уровне абстракции архитектура должна оставаться простой и обладать минимальными привязками.
Хороший API должен исчезать из вида большую часть времени.
Один человек не может принять все необходимые решения.
Принятие решений лучше всего откладывать до последнего момента.
Стандарты применяются разумно, когда они приносят очевидную пользу.
Главная задача реализовать интересы клиента.
Использовать DSL (их код читается как структурированная форма текста, написанного экспертом в данной предметной области).
Используйте самое простое решение из всех возможных.
Четыре правила простой архитектуры:
архитектура обеспечивает прохождение всех тестов;
не содержит дублирующегося кода;
выражает намерения программиста;
использует минимальное количество классов и методов.
Система должна делать то, что задумано ее проектировщиком.
Существует простой способ убедиться в том, что система действительно решает свои задачи.
Система, тщательно протестированная и прошедшая все тесты, контролируема.
Обеспечение полной контролируемости системы повышает качество проектирования.
Для системы необходимо написать тесты и постоянно выполнять их.
Рефакторинг последовательная переработка кода.
Рефакторинг проводится при наличии полного набора тестов.
В системе не дублируется реализация.
Применять повторное использованием даже в мелочах.
Дублирование главный враг системы.
Код системы возможно понять без глубокого понимания решаемой проблемы.
Постараться сделать код выразительным.
Неравнодушие драгоценный ресурс.
Использовать прагматичный подход взамен бессмысленного догматизма.
Применять нагрузочное тестирование.
Многопоточность стратегия устранения привязок.
Многопоточность аналогия работы нескольких компьютеров.
Многопоточность повышает быстродействие не всегда.
Многопоточность может изменить архитектуру.
При многопоточности нужно предусмотреть проблемы многопоточной взаимной блокировки, одновременное обновление.
Многопоточность требует больше производительности и кода.
Правильная реализация многопоточности сложна.
Ошибки в многопоточности обычно не воспроизводятся.
Многопоточность обычно требует фундаментальных изменений в стратегии проектирования.
Предусмотреть перебивание потоками друг друга (требуется знание обработки байт-кода и атомарных операций модели памяти).
Многопоточные архитектуры должны отделяться от основного кода.
Код реализации многопоточности имеет собственный цикл разработки, модификации и настройки.
При написании кода многопоточности возникают специфические сложности.
Предусмотреть обработку обращений к общему объекту.
Инкапсулировать данные: жестко ограничить доступ и область видимости общих данных.
Вместо использования общего объекта каждому потоку можно предоставить копию.
Использовать синхронизацию.
Потоки должны быть как можно более независимы.
Постараться разбить данные на независимые подмножества, с которыми могут работать независимые потоки (возможно, на разных процессорах).
Использовать потоково-безопасные коллекции.
Использовать неблокирующие решения.
Изучать доступные классы на предмет потоково-безопасности.
Модели логического разбиения поведения программы при многопоточности:
производители-потребители: потоки-производители создают задания и помещают в буфер или очередь. Потоки-потребители извлекают задания из очереди и выполняют их. Производители перед записью дожидаются появления свободного места в очереди, а потребители дожидаются появления заданий в очереди. Производитель записывает задание и сигнализирует о том, что очередь непуста. Потребитель читает задание и сигнализирует о том, что очередь не заполнена. Обе стороны готовы ждать оповещения о возможности продолжения работы;
модель читатели-писатели: писатели пишут в общий ресурс, который считывают читатели. Писатель может блокировать читателей. Нужно найти баланс между потребностями читателей и писателей, чтобы обеспечить правильный режим работы, нормальную производительность и избежать зависания;
модель обедающих философов: за круглым столом сидят философы-потоки и думают, в центре тарелка еды. Каждому философу для еды доступно 2 вилки-ресурсы по 1 от соседей. Когда философ проголодается берет вилки, поел кладет обратно. Сложности проектирования взаимные блокировки, обратные блокировки, падение производительности и эффективность работы.
Изучать базовые алгоритмы, разбираться в решениях.
Избегать использования нескольких методов одного совместно используемого объекта.
Избегать зависимостей между синхронизированными методами.
Или использовать 3 стандартных решения:
блокировка на стороне клиента;
блокировка на стороне сервера;