if (canSend) {
if (cmdtype == "VALCN") {
rtnProtocols(cmdtype, "00000000");
}
else if (cmdtype == "FIRMV") {
rtnProtocols(cmdtype, "00000000");
}
else if (cmdtype == "RQSPC") {
rtnProtocols("GVSPC", "00101201");
rtnProtocols("GVSPC", "30082022");
rtnProtocols("ENSPC", "00000000");
}
}
Это уже выглядит очень закономерно, но на самом деле случаются неровности.
Приведенный выше код с именованными константами (и снова прокомментированный = объясненный) уже подойдет.
Было бы неплохо найти общие бизнес-правила, логику:
if (canSend) {
if (cmdtype == "RQSPC") { // First prepare
rtnProtocols("GVSPC", "00101201");
rtnProtocols("GVSPC", "30082022");
cmdtype = "ENSPC";
}
rtnProtocols(cmdtype, "00000000"); // Do 000
}
Только в том случае, если код действительно отличается или на самом деле является другим системным компонентом, используйте специализированное наследование классов. Неровности не должны влиять на другие случаи, поэтому лучше наследование. Иерархия классов также может быть просто переданным объектом Encoder. То есть сам класс не должен использовать наследование. Код здесь более или менее делает некоторую стратегию. Детали относятся к некоторому классу обработки, с которым вы работаете (Single Responsibility).
Выше cmdtype
может быть перечисление, включающее переключатель. Но это может быть даже лишним, если у вас есть дочерний класс для RSQPC и так далее.
Есть еще один подход: декларативный: критерии как данные. Например в XML. Затем у вас есть один фрагмент кода, интерпретирующий данные.
<rtn cmdtype = "VALCN">
<protocols param = "0000000"/>
</rtn>
...
Это позволяет, например, вести журнал и находить непокрытые случаи. Также этот XML достаточно удобочитаем для деловой стороны. А для множества вариантов отчетов вы можете хранить в отчете информацию о кейсе, например, «номер формы» или другую метаинформацию.
Рекомендую посмотреть эти видео для лучшего погружения в вопрос: