Move all user visible messages to the Messages class

[MightyCupcakes]

Right now some commands have their own static constants to define their various success/failure messages; while others (like select command) has one failure message in the Messages class and one success message in the class itself. This behaviour seems to be very inconsistent.

I propose moving all user-related messages to the Messages class with each command having their own Map of various common messages to their respective strings. A possible implementation for add command (within the Messages class) could be:

public static final ImmutableMap<MessageType, String> ADD_MESSAGES = ImmutableMap.<MessageType, String>builder()
            .put(MessageType.SUCCESS_MESSAGE, "New person added: %1$s")
            .put(MessageType.MESSAGE_USAGE,
                    "add: Adds a person to the address book. "
                    + "Parameters: NAME p/PHONE e/EMAIL a/ADDRESS  [t/TAG]...\n"
                    + "Example: "
                    + "add John Doe p/98765432 e/[email protected] a/311, Clementi Ave 2, #02-25 t/friends t/owesMoney")
            .put(MessageType.MESSAGE_FAILURE, "This person already exists in the address book")
            .build();

Comments welcome.

[pyokagan]

@MightyCupcakes

I propose moving all user-related messages to the Messages class with each command having their own Map of various common messages to their respective strings.

Consistency is good, yes. However, how does this compare with going the other direction: Moving the messages of each command to the command class itself, therefore reducing the coupling? What's the benefit of centralizing everything in the Messages class?

.put(MessageType.MESSAGE_FAILURE, "This person already exists in the address book")

What if there are different ways a command could fail?

[damithc]

I think this is a good example of 'cross-cutting aspects' that are not easy to handle in OOP. On the one hand it is beneficial to have all user visible messages in one place e.g. for copy-editing, translating, etc. But it seems odd to put a message related to AddCommand in a class not related to that command. So let's choose one approach and stick to it (a mixture is worse). I'm ok with either one.