You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding the use of the library, keeping an enum such as CardTypes means that users will mostly have to use a huge switch to parse the type of card (for instance, in order to add some css class to display the card logo or in order other things, true story here).
Having an object hierarchy would allow for simpler overrides and usage, and keeping the object paradigm.
Your thoughts on that? I volunteer for this task if it is accepted
The text was updated successfully, but these errors were encountered:
It seems the Enum values can be grouped in categories.. Visa/Maestro/Amex.
If the problem for the logo is to group them, it would be neat to define another enum for these categories, and have a function type -> category.. The switch on category would be shorter, and less prone to change.
The hierarchy would probably not help here, switching on it would be weird even with C# pattern matching. ( that would be more natural with DUs).
Regarding the use of the library, keeping an enum such as CardTypes means that users will mostly have to use a huge switch to parse the type of card (for instance, in order to add some css class to display the card logo or in order other things, true story here).
Having an object hierarchy would allow for simpler overrides and usage, and keeping the object paradigm.
Your thoughts on that? I volunteer for this task if it is accepted
The text was updated successfully, but these errors were encountered: