There are couple of strategies regarding of placement of message string constants:
- Divide all message constants to classes by core purpose.
All message constants are divided in 3 classes:
- Business logic messages and anything that does not fit #2 and #3. (Msg.as or Note.as)
- Data change messages. (DataMsg.as or DataNote.as)
- View interaction messages. (ViewMsg.as or ViewNote.as)
There will be cases then some messages will have more then one purpose(for instance sent by view object and command), but then just try to identify main purpose .
- Single class to hold them all
This will centralize message constant management in one class. Someone use main application module class for it, some create dedicated class.
Downside of this approach is that in big application you will end up having huge list of constants in one class that will be hard to navigate.
- Main sender is the constant holder
This strategy sounds like good idea, as it will keep message constants there they intuitively belong – main object that sends it. But then every time you will want to use that constant outside of main sender you will have to remember and import that class. In the long run it will waste time.
Dont use constants, leave it as string literals
I don’t consider this as an option. It’s hard to remember such message, its easy to miss spell, and hard to rename. You will waste much time and put your application under not needed risk if you go tihs path.