Timeline for Where to store translations for values to their corresponding display texts?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 17, 2017 at 18:04 | history | edited | Arseni Mourzenko | CC BY-SA 3.0 | added 353 characters in body |
| Jan 17, 2017 at 18:00 | comment | added | Arseni Mourzenko | @Achilles: no, not really. If the behavior is different depending on status, you have an abstract TransactionState with its children: CompletedState, PendingState and CancelledState. It's simply the “replace conditional with polymorphism” refactoring technique, nothing more. If the behavior for a completed debit transaction is different from the one for a completed credit transaction and also different from the one for a pending debit transaction, then you probably need to use composition over inheritance. | |
| Jan 17, 2017 at 1:52 | comment | added | Achilles | Thank you. A question about what you said about creating separate classes - CreditTransaction for credit and DebitTransaction for debit type transactions. It works well for this case but what happens when there are more fields like TransactionType. For example, let's say that our table "Transaction" contains the following fields - TransactionType (Debit and Credit), Status (Completed, Pending, Cancelled), IsActive (True, False) etc. Now we're looking at 12 different classes for different combinations of the different values for various fields. Did you mean this or did I get it wrong? | |
| Jan 14, 2017 at 8:38 | history | edited | Arseni Mourzenko | CC BY-SA 3.0 | added 1013 characters in body |
| Jan 14, 2017 at 8:33 | history | answered | Arseni Mourzenko | CC BY-SA 3.0 |