предисловие
Кодировщики, знакомые с oop, определенно знакомы с шаблонами проектирования.Например, в программировании на Java шаблоны проектирования можно увидеть повсюду в реализации классов библиотеки jdk, промежуточного программного обеспечения и т. д. Шаблоны проектирования Задумывались ли вы когда-нибудь при проектировании и написании кода, для чего существуют шаблоны проектирования и на каких принципах они основаны? Ответив на эти вопросы, давайте вместе взглянем на следующий контент. В этой статье в основном описываются соответствующие знания в области проектирования программного обеспечения, шесть принципов проектирования, за которыми следуют шаблоны проектирования, а также некоторый практический опыт нашей команды в реальной производственной среде. Или модель не очень опытный.Если пример неправильный или использование неправильное, пожалуйста, свяжитесь и исправьте его вовремя.
1. Знание дизайна программного обеспечения
Вообще говоря, следующие параметры могут использоваться в качестве справочного стандарта для оценки хорошего дизайна программного обеспечения:
- Удобочитаемость: достаточно ли полна проектная документация программного обеспечения и может ли она быть понята другими сборщиками. Есть также разумные аннотации кода, которые очень важны при эксплуатации и обслуживании некоторых средних и крупных программных систем.
- **Повторное использование:** архитектура, классы, компоненты и другие элементы программной системы легко повторно используются в других частях проекта или других проектах.
- Масштабируемость: когда программное обеспечение сталкивается с изменениями в различных бессмысленных требованиях, может ли программное обеспечение «оставаться неизменным» и могут ли эти требования быть легко выполнены за счет функционального расширения или расширения производительности.
- Ремонтопригодность: степень сложности обслуживания программного обеспечения (в основном относится к модификации программных ошибок, добавлению отсутствующих функций и т. д.).
Однако эти характеристики могут быть абстрактными и трудными для рассмотрения, мы можем рассматривать их по степени сплоченности и связанности.Все шаблоны или принципы проектирования предназначены для решения этих проблем при разработке программного обеспечения и, в конечном итоге, для повышения эффективности исследований и разработок или эксплуатации и обслуживания, а также для лучшей поддержки бизнеса в качестве конечной цели.
Вот еще два важных объяснения существительных:
Степень связи: степень взаимного влияния и зависимости между программными модулями; в реальной разработке, если мы модифицируем класс, если степень связи высока, связанные классы должны быть более или менее приспособлены для адаптации к изменениям этого класса. Если связь низкая, изменения в связанных классах очень малы, что значительно снижает сферу влияния и повышает эффективность.
Сплоченность: естественное расширение концепций сокрытия и локализации информации, оно показывает, насколько тесно компоненты внутри модуля объединены друг с другом. (Есть несколько уровней сплоченности, на своем уровне я могу только осмыслить, но не выразить словами. Заинтересованные друзья могут сами проверить информацию)
2. Принципы проектирования
Выше было упомянуто много знаний, связанных с проектированием программного обеспечения. Это королевский способ применить то, что вы узнали. Если вы внезапно приступите к применению шаблонов проектирования, некоторые мелкие партнеры все еще будут чувствовать себя резкими. Здесь мы представим шесть основных конструкций, которым следуют шаблоны проектирования Принципы, и в сочетании с реальным боевым опытом нашей команды, чтобы объяснить случай.
Принцип единой ответственности (SRP, Принцип единой ответственности):
определение: Представляет функциональные зависимости между составными элементами модуля, а класс отвечает только за одну обязанность.
Случай:Ниже приведена логика метода для сохранения информации о пользователе. Перед сохранением будет проверена целостность информации о пользователе. Она включает в себя много логики проверки. Во время обслуживания этот огромный метод saveUser необходимо исправить. Локальная переменная может иметь большое влияние. После оптимизации часть логики проверки отделяется в частный метод, что значительно упрощает логическую сложность кода функции основной ветви.Однако, когда необходимо добавить или изменить логику проверки, убедитесь, что область влияния ограничена проверкой , чтобы это не повлияло на основную бизнес-логику.
public void saveUser(User user) {
if (StringUtils.isEmpty(user.getName()) {
throw new RuntimeException("用户名为空");
}
if (user.getRole() != null) {
throw new RuntimeException("角色为空");
}
............ 一大堆的校验逻辑
saveInMysql(user);
saveCache(user);
}
private void check(User user) {
if (StringUtils.isEmpty(user.getName()) {
throw new RuntimeException("用户名为空");
}
if (user.getRole() != null) {
throw new RuntimeException("角色为空");
}
............ 一大堆的校验逻辑
}
public void saveUser(User user) {
check(user);
saveInMysql(user);
saveCache(user);
}
Класс обслуживания в поле устройства изначально включал четыре метода: конфигурация загрузки/конфигурация шаблона/статус обновления/получение статуса, но с итерацией функций продукта этот класс обслуживания также быстро расширяется, от конфигурации шаблона/конфигурации функции/конфигурации разрешений до различные Существуют различные методы настройки, но мониторинг устройства, такой как обновление состояния и получение, не часто меняются.Чтобы уменьшить сложность этого класса, он разделен на класс обслуживания состояния устройства и класс конфигурации устройства в соответствии с различными функциями Воздействие контролируется в классе обслуживания Device Configuration.
выгода:**1. Принцип единой ответственности может уменьшить сложность классов/методов, а класс/метод отвечает только за одну ответственность;**2. Улучшить читаемость кода и повысить ремонтопригодность системы; 3. Принцип, которым я больше всего люблю пользоваться, ведь простые вещи не сделают человека неправым.
Принцип открытия-закрытия (OPC, открытие для расширения, закрытие для модификации):
Определение: Указывает, что программные объекты (классы, модули, функции и т. д.) должны быть расширяемыми, но не модифицироваться.
кейс: это часть схемы отчетности и обработки данных о посещаемости. Для каждого процесса отчетности о посещаемости требуются два метода проверки и обработки данных. В настоящее время в этой области существуют различные устройства и сценарии посещаемости, а также логика формат данных также варьируется.Да, в исходном дизайне обработка if..else выполнялась в соответствии с полем типа формата данных, что приводило к тому, что два метода проверки/обработки были очень многословными и полными различных совместимых логика обработки Когда новое устройство посещаемости было добавлено, просто бросьте его в этот огромный if...else для обработки, каждый раз, когда добавляется новое подключение данных о посещаемости, это приведет к большим изменениям в handleService. После оптимизации эти классы обслуживания обработки упаковываются в контейнер, а объект класса реализации выбирается для обработки в соответствии с форматом данных.Теперь добавление устройства посещаемости требует только реализации нового класса обработки для реализации расширения и завершения передачи данных. нового устройства Проверьте и обработайте.
выгода:**1. Возможность расширять существующие системы/функции, предоставлять новые функции для удовлетворения новых требований и делать программное обеспечение/функции легко адаптируемыми и гибкими;**2. Можно не вносить изменений или вносить небольшое количество изменений в важные абстрактные модули, чтобы система/функция обладала высокой стабильностью и долговечностью.
**Принцип замены урока (**LSP, Liskov Substitution Principle) :
Определение: Подкласс может расширять функции родительского класса, но не может изменять исходные функции родительского класса.Наследование включает в себя такой смысловой слой: все методы, которые были реализованы в родительском классе, на самом деле задают ряд спецификаций и контракты. , хотя и не требует, чтобы все подклассы соответствовали этим контрактам, но если подклассы произвольно модифицируют эти неабстрактные методы, это нанесет ущерб всей системе наследования.
**Случай:** Ниже приведен случай, который мы используем при синхронизации данных со сторонними поставщиками. Раньше у нас не было этого шаблона синхронизации, и код логики задачи после стыковки с несколькими платформами выглядел некрасиво, что приводило к плохой читаемости и ремонтопригодности кода стыковки, часто возникали ошибки npe или неверные форматы данных. После оптимизации мы стандартизировали логику процесса синхронизации.Синхронизация данных в разных полях разработана через наследование по этой спецификации синхронизации.В последствии ни разу не было исключения npe или данных не соответствующих требованиям,что значительно улучшает читабельность кода. и ремонтопригодность.
**выгода:**При расширении исходного проекта риск и объем изменений исходной реализации могут быть уменьшены.
**Принцип инверсии зависимостей (**DIP, Dependence Inversion Principle):
**определение:**Модули высокого уровня не должны зависеть от модулей низкого уровня, оба должны быть абстрагированы. Абстракция не должна зависеть от деталей, детали должны зависеть от абстракции, популярным моментом является интерфейсно-ориентированное программирование.
Случай:Ниже приведены сценарии реализации, с которыми мы часто сталкиваемся в развитии бизнеса.Интерфейс данных dao имеет множество методов реализации для разных источников данных.В то время, когда трафик не подходил, в качестве источника данных для хранения, и не было глубокого понимания этого. . Когда появляется трафик, когда требуется как кэширование, так и поиск, важность этой схемы отражается, поскольку такая схема может защитить влияние изменений в реализации базового источника данных на бизнес-уровень.
Преимущества: Уменьшите связь между классами, улучшите стабильность системы и уменьшите риск изменения программы.
Принцип разделения интерфейса (ISP, принцип разделения интерфейса):
определение**: Клиент не должен зависеть от ненужного ему интерфейса, для проверяющей стороны зависимость от другого класса должна строиться на наименьшем интерфейсе, а для проверяющей стороны не должно быть слишком много бесполезных интерфейсов. **
Случай:На самом деле принцип изоляции интерфейса очень похож на принцип одинарной ответственности.Мы сделали очень много разбиения интерфейсов в случаях, похожих на одиночную ответственность., повторные случаи не хочу вдаваться в подробности.
выгода: Идея принципа изоляции интерфейса состоит в том, чтобы установить единый интерфейс, который может сделать обязанности интерфейса очень четкими, что очень полезно для пользователей интерфейса.
Закон Деметры (LoD, Закон Деметры):
определение: Минимизируйте взаимодействие между объектами и, таким образом, уменьшите связь между классами.
Случай:Ниже приведен пример нашей службы в области рассылки.До оптимизации служба рассылки зависит от службы ресурсов и службы приложений.После тщательного изучения кода обнаружено, что информация о приложении, полученная в классе службы рассылки, используется в качестве входных данных для вызова класса службы ресурсов (операция больших парней на уровне бога), после оптимизации класс службы сообщений не зависит напрямую от класса службы приложения, а вызывается и обрабатывается классом сервера ресурсов.
выгода: Это может уменьшить связь между классами и улучшить связность модулей.
Суммировать
Эта статья представляет собой подборку некоторых знаний о разработке программного обеспечения и принципах проектирования.Благодаря этой статье вы можете узнать, почему существует шаблон проектирования? Чтобы решить какую проблему? Какие принципы проектирования необходимо соблюдать? В определении и понимании или падеже могут быть небольшие отклонения, но это не влияет на введение. Совместное использование дел позволяет вам просмотреть технический долг, который вы похоронили в проповедническом служении, чтобы не дать никому снова наступить на яму. Хотя отрасли промышленности разные, логика и принципы, лежащие в их основе, одинаковы. Позже я организую обмен знаниями о шаблонах проектирования. На прошлой неделе нас ждал небольшой сюрприз: количество пользователей в прошлом году превысило установленную цель.