Introduction to Factory Pattern (1): Simple Factory Pattern

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.

But if we think back, these design patterns are actually useful experiences extracted from practice. They do improve readability and scalability of programs to some extent. On the other hand, as well known conventions, design patterns deepen understanding between author and reader. In this sense, they can be considered as a medium of communication. Of course, this has to be used at correct scenarios. In terms of correct scenarios, we are talking about suitable scenarios — not using because we want to use, but for practical purpose.

In this blog post, I will introduce one of the most used design patterns: Factory Pattern, and talk about my understanding on it. … 


Golang’s ridiculous common initialisms

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.

You may think this is no big deal? Ok, what if you want to use some naming like this in your code: makeHttpUrlConnection, getHttpApiUrl and isHttpsApiHost. Writing these might lead go lint to give you following suggestions: makeHTTPURLConnection, getHTTPAPIURL and isHTTPSAPIHost. Totally ridiculous and hard-reading namings.

Want to mute the crazy complaints? Sorry, go lint does not support customization. It’s hard-coded here: Apparently they don’t think it’s a problem at all, see discussion:

.golintrc for enabling and disabling rules


Weird NumberFormatException Using SimpleDateFormat

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.

Let’s see an example first.

Above program starts 5 threads, each of which parses a date string using shared SimpleDateFormat. Run above program several times, very likely you will get one of the below unexpected results or exceptions.

  1. Exception in thread "Thread-4" java.lang.NumberFormatException: For input string: ""
  2. Exception in thread "Thread-1" java.lang.NumberFormatException: multiple points
  3. Thu Jun 27 10:33:09 CST 2024
  4. Exception in thread "Thread-2" java.lang.NumberFormatException: empty String
  5. Fri Jun 27 10:33:09 CST 2200
  6. ......

As shown above, sometimes you get an exception (mostly the NumberFormatException: For input string: ""), sometimes it just gives incorrect values.

To avoid the problem, you can create a SimpleDateFormat each time when you parse a string. Of course, this is not efficient enough. If you want a more superior solution, you can use ThreadLocal to make sure each thread has its own copy, you probably also want to cache the created instances. To see the details of this solution, you can refer to up Jesper’s blog post, it also provides a performance comparison of several solutions.