In looking at the "simple" problem, I think there were a couple of factors that weren't taken into account for the solution. To me the key was "incoming message from OUTSIDE our application boundaries." The OUTSIDE part is important. Why would you hard code anything that was coming from an application that is outside of your control? This is an interface mapping exercise and IMHO it should be handled through configuration (either config file or database), simplifying the code even more and allowing changes to the message mapping without requiring a developer to make a code change a redeploy in the case of a change in the outside system.
Yeah, I can see that, but the perspective of not changing a single class is tempting. It makes sense to me to keep the configuration of the integration responses separated from the application logic. But in practice, as you say, changing this structure in the code itself shouldn't be harmful anyway. Thanks!
Hi iplaykeys, I agree with your point, it could be placed in a separate file or database that didn't require a source code change when the external system changes. Thanks to the cloud structure deploying a new version of an application isn't as hard as it used to, but that shouldn't be an excuse for messing around with the source code when you can prevent it.
Thanks for the input!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In looking at the "simple" problem, I think there were a couple of factors that weren't taken into account for the solution. To me the key was "incoming message from OUTSIDE our application boundaries." The OUTSIDE part is important. Why would you hard code anything that was coming from an application that is outside of your control? This is an interface mapping exercise and IMHO it should be handled through configuration (either config file or database), simplifying the code even more and allowing changes to the message mapping without requiring a developer to make a code change a redeploy in the case of a change in the outside system.
The map IS your config file. With a good CI/CD setup changing the code to add an item to the map is no more difficult than updating a config file.
Yeah, I can see that, but the perspective of not changing a single class is tempting. It makes sense to me to keep the configuration of the integration responses separated from the application logic. But in practice, as you say, changing this structure in the code itself shouldn't be harmful anyway. Thanks!
Hi iplaykeys, I agree with your point, it could be placed in a separate file or database that didn't require a source code change when the external system changes. Thanks to the cloud structure deploying a new version of an application isn't as hard as it used to, but that shouldn't be an excuse for messing around with the source code when you can prevent it.
Thanks for the input!