I think there area couple of competing guidelines here: Don’t Repeat Yourself versus Let the Complexity Emerge. But let’s start with your previous article on Naive Implementations.
The very first implementation should be Naive, changing as little code as possible. As such, the example at the start where you pull the initials out in the calling location is possibly the right one. It does, however, split the logic up to two places, so it might even be easier to pass the whole object in, and pull the initials out in the display code.
This could get into a discussion of model-view-controller approach. Are the initials part of the model or part of the view? Here is where we let the complexity emerge. If it is only ever used in this one location, you can think of it as part of the view. If the initials get any wider use, they start migrating toward the model. Thus, I would need more context before I could say what the right design is for them.
The calling fragment is in some HTML template language. What is not said is how often the Initials are going to be used of for what. But more important, with initials you are going to want to be able to customize them. How do I know?
Because my initials spell AMY. And it was painful in when my sister’s sixth grade teacher came in and announced this to my 4th grade class. I don’t tend to use my full initials.. Although when I worked at walker.com my email was email@example.com, and many people thought my actual name was Amy, at least until the met me in person.
The above example uses first and last. But names are hard. A couple examples:
- Jules Henri Poincaré When by Henry, and would probably have confused people if the initials JP showed up next to his name.
- The full name for the current King of Spain is Felipe Juan Pablo Alfonso de Todos los Santos de Borbón y Grecia. His initials should possibly be FA.
Thus, in this particular instance, I would create an editable initials field on the object and use that consistently where-ever the initials are to be used. You can use the “initial” algorithm above to pre-populate the field, but then let people customize. Initials are a short-hand identifier, and thus should be calculated from the object they are identifying. I suspect that you will also need a way to distinguish between two people with identical initials, and thus you would probably change the background color or something around where the initials are used, and that, too, should be part of the identifying information for a user. And you are going to want a link assuming this is HTML to the appropriate person for the end user to see which person is indicated.
Complexity will creep in.
So, start Naive, and refactor to the appropriate solution as dictated by the usage, following the principal of don’t repeat yourself to keep the logic in a single location.
Thanks for this thoughtful response, Adam!
Your point about where we build the initials in the MVC is well-taken. The model is an option that I didn’t explore, and perhaps one a frontend developer might miss.
Building initials is a potentially complicated problem! I think your ideas about solving it are great. It’s another reminder to me to choose simple code examples for my arguments. Thanks again.
Heh…there are no simple problems. Only iteratively more complex solutions….
There are very few “Trivial examples” and I think that this one was appropriate for your discussion. Most examples, when pushed, become non-trivial. A lot depends on how much effort you are willing to put in to a solution, and what are the needs of the users.