As we learned in the previous blog Achieve thread-safety with immutability the builder pattern is a very good design to follow to make your code safer. Another common, perhaps the most common, error that occurs in applications is the NullPointerException. So in this article, we are going to look at how we can use design to eliminate null.
Mutable objects are different control in a multi-threaded environment and are prone to cause strange bugs and unexpected behaviors in your code. We are going to investigate why it’s usually better to work with immutable objects and learn good design patterns to help you as a developer achieve immutability.
Have you ever felt that your code was difficult to test because of your classes, for example, depends on something external? A typical issue is that you have some class managing database operations and during your tests, you don’t want to query the database as it is usually considered out of scope from unit tests. Well, no worries Mockito has got you covered.
Temporary hick-ups occurs from time to time and are quite difficult, if not impossible to entirely avoid. For example, if you are integrating with a REST service, or using a database to manage your data it is likely that at some point that your application won’t be able to reach the service or database. For example, Azure, which is considered to be a highly available service with almost no downtime can still only guarantee an uptime of 99.9%.