предисловие

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

Например, вы обычно пишете такой код:

if(a){
	//dosomething
}else if(b){
	//doshomething
}else if(c){
	//doshomething
} else{
	////doshomething
}

Чем меньше состояние, тем лучше, один разelse ifСлишком много логики здесь сбивает с толку и чревато ошибками.

Например:

Взято изcimУсловие оценки для клиентской команды в .

В начале было мало условий, поэтому я не особо заботился о написании напрямую, сейчас функций стало больше, что приводит к добавлению каждый раз по одномуelseЯ должен тщательно проверить условия, чтобы не повлиять на предыдущую логику.

В этот раз я, наконец, не выдержал и сделал рефакторинг, после рефакторинга структура здесь такая:

В итоге это превратилось сразу в две строчки кода, что гораздо проще.

Вся предыдущая логика реализации извлекается отдельно в другие классы реализации.

Таким образом, всякий раз, когда мне нужно добавить новыйelseЛогика, нужно только добавить новый класс для реализации того же интерфейса, чтобы завершить. Каждая логика обработки независима друг от друга и не мешает друг другу.

выполнить

Эскиз рисуется согласно текущей реализации.

Общая идея такова:

• определитьInnerCommandинтерфейс, который имеетprocessФункция передается конкретной бизнес-реализации.
• В соответствии с вашим бизнесом будет несколько реализаций классовInnerCommandинтерфейс; эти классы реализации зарегистрированы вSpring Beanв контейнере для последующего использования.
• Вводить команды через клиент, изSpring Beanполучить контейнерInnerCommandпример.
• выполнить финалprocessфункция.

Основная цель достижения состоит в том, чтобы не иметь множественных условий суждения, а нужно только динамически получать в соответствии с текущим состоянием клиента.InnerCommandпример.

С точки зрения исходного кода наиболее важным являетсяInnerCommandContextкласс, который будет динамически получен по текущей клиентской командеInnerCommandпример.

• Первый шаг – получить всеInnerCommandСписок экземпляров.
• Получите тип класса из списка экземпляров на первом шаге в соответствии с командой, введенной клиентом.
• По типу класса отSpringПолучите конкретный объект экземпляра из контейнера.

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

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

Таким образом, для замены предыдущего сложного кода требуется всего две строки кода.if else, но и гибкое расширение.

InnerCommand instance = innerCommandContext.getInstance(msg);
instance.process(msg) ;

Суммировать

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

Просто сканируйте все реализации при запуске приложения.InnerCommandКласс интерфейса может быть, вcicadaЕсть похожие реализации, если интересно, можете сделать самиПроверять.

Надеюсь, эти маленькие советы помогут вам.

Весь приведенный выше исходный код можно посмотреть здесь:

GitHub.com/crossover J я…

Ваши лайки и репост - лучшая поддержка для меня