Diego Pacheco Tech blog

Once upon a time, Design Patterns was a big thing. In current times, perceptions have shifted and the industry has mixed feelings about them. I've thought a lot of blogging about design patterns was worth it or not. I used a lot of patterns in my life, there were moments when I was completely okay with design patterns, and other times not so okay. I got some mixed feelings but today I think they are fine. IMHO there are some fairness and some misconceptions. There are hundreds of Design Patterns, there are patterns for everything you can imagine. Usually when people complain about patterns they are talking about OOP patterns, more specifically from the 90s book from the GOF .   Patterns are not limited to OO, there are functional programming patterns, system programming patterns, OS patterns, cloud computing patterns, frontend patterns, and mobile patterns. Lots of these patterns are very similar, at the end of the day not all problems are that different, and are all about ideas an...

Factory and Builder and super popular design patterns and still relevant and useful. However what happens if you need to allow others to create objects? That's like a reverse factory where the user needs to define the creational rules. So how can we do that and also have some guardrails and fences to drive some control and even some abstractions, is that possible? yes - that's the factory-kit pattern. Hold one a second why the heck I would need that? Let's say you are creating a game or a modular solution and you need to allow you consider defining customizations within some constraints. 

Reading and writing configs and objects can be more challenging than it looks. As your application evolves and your contract is used across several services, you might need to have Backward Compatibility. Easily we can think about 2 scenarios, the first scenario let's say you have a distributed monolith and you have multiple apps using the same database. The second scenario considers you have an Event Sourcing + CQRS application using Kafka for instance where you emit and read domain events. In both scenarios, there will be breaking changes, so how we can make your parsers and serializers to be more efficient and resilient to change, well: The Tolerant Reader Pattern is here to rescue.

The lazy Loading pattern is very interesting because allows us to make the code starter and also delays expensive computations to an appropriate moment. There is a way to combine this pattern with Java 8 Functional Interfaces and make it even more interesting and java idiomatic. This pattern is used by Spring and Hibernate. You can use it too. So today I have a video and some POC code. Let's get started!

There are several architectural patterns we can follow when we need to distribute a shared piece of software. My favorite and default pattern is Service Pattern. However, there are other patterns for software distribution.  If we think about startups for instance there is a popular tool called Lean business Canvas where you model the business model of your startup and there are many dimensions there but one particular dimension called "Distribution Channels" is highly related to the subject of this blog post. We, as engineers often just think about one dimension with is either a Service or Binary shared library.  However, there are other dimensions we could explore. The other options are Tooling, Internal Services / Self-Service Platforms, Runtime Platforms, and Service Mesh. So for this blog post, I want to cover a little bit more the Sidecar Pattern. 

In previous post i was talking about some alternatives to classical IoC/DI. I`m not here to argue whats bets or worst, the 2 approaches have advantages and cons. Most classical OO languages like JAVA and .NET tend to fix things at runtime. Java for instance all happens in runtime, spring context. JSF context, Hibernate/JPA context, reflection(memory), CGlib, proxies, etc.. In FP languages that are children of haskell like F# and Scala things tend to happen as much as possible close to the compiler and thats has good and bad things like everything in life. In java or .NET you dont have multiple inheritance like you do in C++. So another approach would be do inheritance and work with the ideas of Modules. Some people call this: Thin Cake Pattern, for me is just multiple inheritance with syntactic sugar. As long as you do it only for classes/traits and dont do it for values i think is ok and IMHO cleaner than the cake pattern.