In my last article about Factory Pattern, a simple and intuitive method was introduced to encapsulate product creation logic without exposing details. The problem is that once we add a new concrete product call we have to modify the Factory class. It is not very flexible and requires the factory depending all concrete product types. Although class registration techniques can be used to eliminate the couplings in some extent, they still have some major drawbacks that prevent them to be used extensively.

Nowadays, design patterns are not that popular to talk about. This could be related to the rapid iteration of web services, and the popularity of Micro Services. Design patterns were once considered useless dogma, thus as an anti-pattern, during the hype of Function Programming. Of course, design patterns might have been thrown away as the essence of Object-Oriented Programming, because Functional Programming was preferred to OOP and was a hype during the time.

Golang is well known for its opinionated in coding style. It provides a lint tool thoughtfully, which is good, but failed to provide any mechanism to override or config it, except not using it at all. As one coming from Java world, knowing Go’s in favor of camel case is pleasant. Not that much when realizing it treats common acronym words as all caps in variable or function names, such as userID instead of userId.

The SimpleDateFormat from JDK is not thread-safe, so be careful when it is used in a concurrent environment. Although it is clearly stated in the JavaDoc of the API that it’s not synchronized, I think many would not notice it until we encounter problems caused by the issue.