The Liskov Substitution Principle, introduced by Barbara Liskov, represents the “L” in SOLID. It states that every implementation of a class should be replaceable with an implementation of any class that extends it. In other words, every instance of a parent class should be replaceable by any instance of its child classes so that the application continues to work.
Code Soapbox Posts
The Open/Closed Principle represents the “O” in SOLID. In the words of Bertrand Meyer (who originated the term), it states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification“. What it means is that one should be able to extend the behavior of an entity without modifying its code.
The Single Responsibility Principle represents the “S” in SOLID. It means that a software module should only have one responsibility – in other words, there should never be more than one reason to modify that module (excluding, of course, refactoring and bug fixes). The responsibility of a module should be entirely encapsulated within that module and all services within it should be narrowly aligned with it.
The Java Stream API is a wonderful tool, but not without its shortcomings. There is a bug in Java 8 & 9 which affects the number of threads used by a parallel stream in a seemingly unpredictable way. Beware!
By default, Spring Boot uses an OpenEntityManagerInViewInterceptor which “binds a JPA EntityManager to the thread for the entire processing of the request […] to allow for lazy loading in web views despite the original transactions already being completed”.
In other words, in every
@RestController action, instead of throwing a
LazyInitializationException when you forget to fetch a lazy-loaded property, Spring will now fetch the property outside of the original transaction. The pattern (or antipattern) is called Open Session In View (OSIV) and, while it sounds fairly useful, is not a good choice for production environments.
The following is a short case study of my latest learning venture and how it lead me to create an app that solves a real-world issue and might earn me some money in the future.
The Builder pattern helps us create complex objects that can have different representations, simplifying the process and (optionally) preserving immutability – encapsulating the code responsible for assembling an object in a separate Builder class.
In simpler terms, it delegates the responsibility of creating a complex object to its Builder, whose job it is to make sure that the object is never created in an invalid state.
Spring Boot, by default, uses Thymeleaf 2 as its template engine. You can, however, make it use the newer version.