Мы строим программные приложения на разных языках уже несколько лет. За это время появились новые рамки, новые инструменты, новые методологии. Особенно в платформе Java, где у нас есть множество вариантов в каждой области, следуя различным шаблонам и принципам проектирования, таким как MVC, FrontController и т. Д.
У нас есть много принципов разработки, таких как KISS (Keep It Simple Stupid), DRY (Don’t Repeat Yourself), которые поощряйте разработчиков писать более качественный и более понятный код. В частности, принцип DRY — очень хороший принцип, который каждый разработчик должен понимать и соблюдать.
Принцип СУХОЙ гласит: «Каждая часть знаний должна иметь одно, однозначное, авторитетное представление в системе».
Таким образом, принцип DRY гласит: если вам нужно писать один и тот же фрагмент кода во многих местах, а не вставлять его в копию, сделайте его отдельным методом и вызывайте этот метод везде, где это необходимо. Это применяет DRY на уровне кода.
Я действительно ценю авторов Jakartha-Commons Utils за практическую реализацию принципа DRY. Всякий раз, когда мне нужна такая утилита, как какая-либо операция со строкой, вычисление даты, регулярное выражение, загрузка свойств и т. Д., Я просто открываю веб-сайт Jakartha-Commons и уверен, что смогу найти то, что мне нужно.
Несмотря на то, что каждое приложение имеет свой собственный набор бизнес-требований, есть много вещей, которые являются общими для веб-приложений и приложений для предприятий. Особенно инфраструктурный код, который может быть похож на многие приложения.
Теперь я думаю, что настало время вывести СУХОЙ принцип на следующий уровень, я имею в виду применить на функциональном уровне.
Давайте посмотрим, где мы можем применить DRY на функциональном уровне. Ниже приведены некоторые вещи, где мы можем создавать повторно используемые компоненты / небольшие проекты, которые мы можем напрямую использовать с другими проектами.
1. Многоуровневая строка меню приложения:
Я видел много приложений с горизонтальной строкой меню в верхней части страницы с одно / многоуровневыми подменю. Панель меню может быть построена с использованием Javascript или пользовательских тегов. Я предлагаю, если мы сможем создать CustomTag для генерации строки меню из конфигурации xml и таблицы стилей, которые компонент может использовать в любом проекте.
Например:
мы можем создать структуру xml для нашего меню следующим образом и создать собственный тег для анализа этого xml и визуализации строки меню с таблицей стилей по умолчанию. Если пользователь предоставил пользовательскую таблицу стилей, пользовательский тег будет использовать ее.
<menubar>
<menu>
<index>1</index>
<name>File</name>
<item>
<index>1</index>
<name>New</name>
<item>
<item>
<index>2</index>
<name>Save</name>
<item>
.....
.....
</menu>
<menu>
<index>2</index>
<name>Edit</name>
<item>
<index>1</index>
<name>Cut</name>
<item>
<item>
<index>2</index>
<name>Copy</name>
<item>
.....
.....
</menu>
</menubar>
2. Система аутентификации и авторизации на основе ролей:
я участвовал во многих проектах, где пользователи приложения будут иметь одну или несколько ролей, а каждая роль имеет одну или несколько привилегий. Каждая привилегия — это не что иное, как действие, которое пользователь будет вызывать в приложении. События приложения будут управляться авторизацией на основе ролей. А также может возникнуть требование создания групп пользователей и назначения привилегий группам пользователей, а не отдельным пользователям.
Я думаю, что эта Система авторизации на основе ролей также может быть построена как компонент, который мы можем подключить к любому проекту.
3. Планирование заданий:
для многих предприятий может быть несколько пакетных заданий, которые должны выполняться по определенному расписанию. Я думаю, что необходимо создать веб-приложение для планирования заданий со следующими функциями:
a) Интерфейс на основе веб-интерфейса для создания и планирования новых заданий.
b) Предоставление для отслеживания состояния выполняемых заданий.
c) Предоставление для выполнения заданий в режиме ad-hoc.
d) Предоставление для перепланирования, прекращения задания.
e) Информирование заинтересованных групп о статусе. заданий по электронной почте
е) Автоматические уведомления по электронной почте о сбоях заданий
Мы можем создать веб-приложение с вышеупомянутыми функциями и оставить реализацию бизнес-логики в заданиях для разработчиков.
4.
Сложная система каротажа:
При разработке приложений ведение журнала играет важную роль в устранении проблем. Мы можем использовать AOP для входа в систему с более чистым подходом. Часто разработчик должен проверить, какие параметры отправляются в методы и где он генерирует исключение.
Для этого мы можем написать MethodParamsDumperAspect, используя SpringAOP + AspectJ, который будет отображать значения параметров метода с помощью отражений / commons-beanutils. Единственное, что нужно настроить разработчику — это имя базового пакета.
5. Настраиваемый и настраиваемый механизм рабочего процесса :
я видел много интранет-порталов с приложениями HelpDesk со следующими функциями.
1. Клиент поднимет запрос.
2. Система определит рабочий процесс для обработки запроса, и запрос будет направлен заинтересованному лицу.
3. Запрашивающая сторона может просматривать состояние своей заявки по мере выполнения каждого шага.
Подобно этому, существует много систем на основе WorkFlow. Мы можем создать общий механизм рабочего процесса, в котором администратор может настроить метаданные, такие как типы запросов, шаги для каждого запроса, коды состояния запроса и т. Д.
Так что здесь я хочу сказать, что все эти дни мы следовали за DRY в написании кода. Давайте возьмем его на следующий уровень в создании компонентов / подпроектов. Если бы архитектор или разработчик получил требование создать повторно используемый компонент, было бы здорово, если бы он / она могла опубликовать свой подход (и код, если это возможно) так что другие разработчики в сообществе Java могут использовать подход / код вместо того, чтобы изобретать велосипед.
От: http://sivalabs.blogspot.com/2011/01/next-level-of-dont-repeat-yourselfdry.html