Wondershare EdrawMind
MindMap Gallery Искусство проектирования программной среды
- 7
Искусство проектирования программной среды
Когда мы хотим передать другим знания об искусстве проектирования программных инфраструктур, нам будет сложно убедить их принять наши знания, поскольку у них нет опыта, подобного нашему.
Edited at 2024-04-10 17:25:12
Искусство проектирования программной среды
- Recommended to you
- Outline
Искусство проектирования программной среды
Предисловие
«Как только API будет выпущен, это облегчит наше вечное сосуществование»
Когда мы хотим передать знания другим, нам будет трудно убедить их принять наши знания, поскольку у них нет опыта, подобного нашему.
Теория и причины
«Искусство» или «Инженерное дело»
Важная уникальность API: согласованность.
Какова согласованность действий внутри группы?
Идеальная командная работа
Общее видение
общественный срок
П2 Год спустя я подтвердил эту догадку. Поскольку Netbeans — это проект с открытым исходным кодом, существует API, который привлекает внешних разработчиков. Вначале этот внешний разработчик кода в основном выполнял работу по исправлению ошибок. Позже он стал самостоятельно отвечать за подпроект и разрабатывать соответствующие API. Человек, который изначально отвечал за разработку этого API, сказал, что он обнаружил, что API этого подпроекта становится все хуже и хуже, но он не мог найти причину и надеялся, что я смогу помочь. Он сказал: Ему не очень нравятся эти новые API, и он не хочет интегрировать их в проекты, за которые он отвечает. Но он также не мог сказать, в чем проблема с этими новыми API. Наконец, он сказал, что эти новые API не соответствуют его первоначальному видению. Однажды я сказал ему нечто подобное. По моим меркам, API, который он написал, не соответствует идее API NetBeans!
методология
рационализм
Эмпиризм
Без эмоций
Поверхностное понимание
Степень понимания чего-либо ограничивается знанием того, как это использовать.
глубокое понимание
Поймите принципы и законы, лежащие в основе чего-либо.
В большинстве случаев «поверхностного понимания» достаточно.
избирательное невежество
Некоторый контент требует глубокого понимания
Безпоточный принцип разработки приложений
Постарайтесь позволить соответствующему персоналу, который в конечном итоге несет ответственность за интеграцию, хорошо поработать над интеграцией без необходимости глубокого понимания системы.
Объект: люди
Критерии оценки качества API
Почему?
Мы хотим иметь возможность «безпоточно» собирать большие строительные блоки в приложения.
что?
Метод, класс, сигнатура поля
Файл (канал unix)
Переменные среды и параметры командной строки
Текстовая информация (toString)
протокол
Поведение
Наиболее важным способом оценки совместимости является «нормальная работа», но это определяется конкретной внутренней реализацией.
нулевое возвращаемое значение
глобализация
…
Качество
понятность
Пути общения между дизайнерами и разработчиками
Важность примеров
последовательность
Снизьте кривую обучения
оставайтесь совместимыми
видимость
Предоставьте «портал» для поиска нужных вам решений.
На основе фактических или ожидаемых целей и задач
Пользователей не волнуют конкретные классы
Простые задачи должны иметь простые решения
обычный пользователь
расширенный пользователь
защитить инвестиции
Думайте больше о пользователях
Изменение целей
обратная совместимость
Совместимость с исходным кодом
Двоичная совместимость
Функционально совместим
легко пропустить
Отношение, «хорошие начальники» на клиентов не жалуются.
Важность ориентации на варианты использования
Пример
Что я должен делать
Сцены
Сначала ты должен сделать это, а потом это
Обзор дизайна API (отличные правила API)
Проектирование API на основе сценариев использования
При проектировании API необходимо провести абстрактный анализ, основанный на некоторых конкретных сценариях и понимании API, и, наконец, предоставить проект.
Согласованность дизайна API
API часто создаются несколькими дизайнерами, но вся команда должна быть в состоянии поддерживать некоторые основные принципы «лучших практик». Независимо от того, насколько хорошо спроектирован интерфейс, пока он нарушает согласованность действий всей команды, мы предпочитаем довольствоваться вторым лучшим.
Простой и понятный API
Простые и распространенные задачи должны выполняться легче. Если вы разрабатываете проект на основе подхода, основанного на сценариях использования, вы можете легко проверить, могут ли эти API реализовать эти важные сценарии использования с помощью сценариев, которые можно легко реализовать.
меньше - больше
Функции, предоставляемые API внешнему миру, должны включать только функции, описанные в вариантах использования. Это позволяет избежать расхождений между требуемой функциональностью и тем, что фактически предоставляется.
Поддержка улучшений
Библиотеку необходимо постоянно поддерживать. Даже если возникнут новые потребности или уйдет первоначальный автор, эта библиотека классов не будет заброшена.
Практика проектирования
Публикуйте только то, что вы хотите опубликовать
Легко добавить, сложно удалить
При выпуске первой версии удалите ненужный контент
Методы над полями
За исключением статических и окончательно объявленных базовых типов, строковых констант, перечислений и неизменяемых объектов, никакие другие поля не должны предоставляться.
Фабричные методы лучше функций
Возвращаемое значение фабричного метода не обязательно является экземпляром объявленного типа, но может быть экземпляром подкласса.
Объект, возвращаемый каждый раз, не обязательно является вновь созданным объектом, его можно кэшировать.
Контроль синхронизации, унифицированная обработка кода до и после создания объекта
Сделать все неизменным
Если вы не хотите иметь подклассы, вам следует сделать их ненаследуемыми.
Избегайте злоупотребления методами установки
Никогда не объявляйте методы установки в формальных API без необходимости.
setEnable
Может быть контекстно-зависимым
Решение isEnable делает setEnable бессмысленным
По возможности раскрывайте функциональность через дружественные методы.
Метод доступа к пакету Java по умолчанию, внутренний класс
Предоставьте создателям объектов больше прав
разрешение доступа
Избегайте раскрытия глубокого наследования
повторное использование кода
Повторное использование функции
«Наследование» используется не для изменения конкретного поведения, а для добавления некоторых дополнительных действий.
Если вы наследуете класс только для переключения пути выполнения определенных методов, такого подхода следует избегать.
Рекомендация: избегайте глубокого наследования, определите программные интерфейсы и позвольте пользователям реализовывать эти интерфейсы.
Программа ориентирована на интерфейсы, а не на реализации
Разделение абстрактного определения (интерфейса) и реализации
сотрудничать
Дайте понять пользователям API: при использовании API следует следовать правильным принципам. Если вам необходимо использовать API, вы должны соблюдать принципы API и не нарушать его.
Четко объясните требования API, определите соответствующие варианты использования и помогите разработчикам API реализовать такие API.
Защищенные методы не могут быть удалены, что приводит к модификации подклассами.
Добавление абстрактного метода в интерфейс заставит его неабстрактные подклассы реализовать этот метод.
Модульная архитектура
Объектно-ориентированное программирование не исключает спагетти-программирования.
Цель модульности: добиться слабой связи различных компонентов.
Модульная архитектура отделяет спецификацию от реализации.
В модуле, где находится спецификация, будет хотя бы небольшая "запись"
внедрение зависимости
Весна
Поиск в Netbean
Расширять
P111 В 2001 году мы представили тему «Позиционирование и взаимодействие компонентов» на конференции JavaOne. Содержание этой темы в некоторой степени связано с этой главой. Мы считаем, что содержание этой темы важно для всех модульных программ. Однако оргкомитет конференции JavaOne в это время может просто посчитать, что название темы недостаточно крутое, а может быть, потому, что почувствует, что словом «компонент» злоупотребляют, а слово «компонент» включает в себя практически все, что только можно себе представить. поэтому вопрос не был принят. До 2006 года мы с моим коллегой Тимом Будро представляли аналогичную тему под названием «Шаблоны внедрения открытий и внедрения зависимостей в модульные архитектуры». Разумеется, как мы и ожидали, тема была принята оргкомитетом. Это означает, что вы должны найти термины, которые близки вашей целевой аудитории, чтобы произвести на нее впечатление. Когда они услышали слово «инъекция зависимости», их сердца взорвались. Как и слово API, подходящее имя облегчает общение. Для пользователей, чем легче им понять слово API, тем легче им принять контент, связанный с API.
На самом деле есть еще несколько слов: архитектура, узор.
При разработке API различайте целевые группы пользователей.
API
Можно добавить, но нельзя удалить
Вызван другими для выполнения определенных функций
последний урок
сплоченный, самодостаточный
СПИ
Интерфейс поставщика услуг
Можно удалить, но нельзя добавить
Чтобы другие могли расширить функциональность API
интерфейс
Избегайте смешивания двух
Разумно декомпозировать API
API
СПИ
Классификация NetBeans
Основной API
Поддержка API
Базовый SPI
Поддержка SPI
Организуйте структуру API в соответствии с различными потребностями ваших групп пользователей.
Помните о тестируемости
Макет объекта
Предоставьте Mock-объекты для API.
Тестовый код является частью спецификации
Хорошие инструменты упрощают проектирование API
волшебник
Позвольте клиентам начать работу как можно скорее
Первая цель проекта — быстро вывести его на рынок.
Каждая важная технология в NetBeans имеет соответствующий мастер для создания начальной базовой структуры.
Набор тестов совместимости
Для пользователей SPI и разработчиков API
Сотрудничать с другими API
Используйте сторонние API с осторожностью
режим упаковки
Публикуйте только абстрактный контент
Чем больше открытий, тем меньше места для эволюции.
Укрепить согласованность API
Агенты и портфели
Избегайте неправильного использования API
Между всеми уровнями должна быть согласованность.
Некоторое содержимое конкретной среды выполнения API
«Печально известный» — вместо того, чтобы жаловаться на пользователей, лучше изменить свое отношение
«Гардиан» - автоматизированное тестирование
Синхронизация и взаимоблокировка
Правильно и адекватно опишите свою модель резьбы.
Подводные камни в Java-мониторах
Наследование влияет на синхронизацию
Для общедоступных API внешние методы не могут быть объявлены как синхронизированные.
Синхронизация Java и взаимоблокировки с подводными камнями повсюду
декларативное программирование
Основная идея: вместо того, чтобы позволять пользователям API шаг за шагом указывать программе, что делать, им нужно только сообщить программе свои результаты, а затем позволить API выполнить всю работу.
Реализация NetBeans Lookup требует только простого XML-описания и не требует регистрации или выхода пользователя из системы.
самоописательный
ежедневная жизнь
Реальная жизнь полна меняющихся факторов, и теоретические вещи не могут применяться в жизни без изменений. Вам нужно не только знать, что работает, а что не работает, но вам также нужно знать, как работать, чтобы это делать.
Экстремальные мнения скорее вредны, чем полезны
Требуется API
красивый
верно
Если простота использования принесена в жертву ради правильности, может возникнуть больше проблем.
Меркуриал и СВН
Будь проще
это высокая производительность
Абсолютно совместим
симметричен
Противоречия в дизайне API
противоречивый
Определение Wiki: «Вера в две противоречивые точки зрения одновременно, не осознавая, что они противоречивы».
Отдел безопасности
Безопасность самолетов
Разработчики постоянно жалуются на такие вещи, как обзоры, стандарты программирования и т. д. Но хранителям API необходимо всегда быть начеку, иначе из-за небольшой оплошности могут возникнуть проблемы. С другой стороны, это не просто незначительная проблема, это, по крайней мере, показывает, что работа, которую вы делаете, действительно полезна.
отчет меньшинства
Улучшить API
Командная работа
Проведение проверок кода перед отправкой кода
Убедите разработчиков предоставить документацию для своих API.
Обратное рассуждение
перед написанием кода
Обзор
Часто задаваемые вопросы
Добросовестный наблюдатель
Инструменты отслеживают все изменения, требующие внимания
Если у вас нет инструментов, вам нужен кто-то «всезнающий и всемогущий».
Получайте исправления API
Принимайте только хорошие советы
Разработать требования
Требования не могут быть слишком сложными
Используйте соревновательные игры, чтобы улучшить навыки проектирования API.
Предоставлено для скачивания с сайта www.xmindchina.net.