The Adapter or Wrapper Pattern allows you to `translate` one interface into another, expected by the client class. It is especially useful when the adapted object comes from 3rd party library, and you do not want to make your system depending on that interface, creating the so-called `anticorruption layer`. Adaptee interface changes will only affect the `Adapter` and not the rest of the code.
IntelliJ IDEA is pretty good at handling LaTeX. I dare say that it is an even better experience than TexStudio or Texmaker, which are dedicated to this type of project. However, the strength of IntelliJ is not in its out-of-the-box capabilities, but plugins and manual configuration of the build process.
The facade allows you to hide the details of the module from clients. It ensures compliance with `Law Demeter`. Using the generic interface and various implementations greatly simplifies testing. It blends well with other patterns like `Strategy`,` Template Method`, or construction patterns, allowing configuration of the object available for the clients. The facade is a good entry point for libraries, giving customers access to high-level functionality and hiding all internal logic and classes.
The `Strategy` pattern creates a family of algorithms, enclosing the differing logic in separate classes while hiding it from clients behind the interface. It enables the interchangeable use of implementations. The use of the strategy simplifies the customer code, avoids code duplication and conditional statements. Significantly simplifies testing - by separating client testing from strategy algorithms.
`Static Factory Methods` known from Java have their place also in Kotlin, although they look and behave a bit different because there is no `static` word in Kotlin. Here I'll try to show how to use `companion object` for `Static Factory Methods` and more. PS: This whole post was supposed to be about `Factory Method` with just a short mention about static factory methods, but the topic becomes more interesting than I thought :)