An actor model gives us outstanding solution for building of high scale and high load systems. Those of you who work with Akka, know that in the Actor model everything should be represented as an actor. In some sense this axioma simplifies a software development. Is this circumstance as good as it seems? In this article I'm going to demonstrate some approaches which may be applied to actors which need to interact with a database. Just imagine, what sense in a high scale and high load system if it does not communicate with a database?
This article will be about State design pattern. It is one of behavioral design patterns. You don't need to know many theory to understand the main concepts of the pattern. The post will be break in several parts where I will provide information about situations where the pattern need to be applied, cons and pros which it has and an example of usage.
This time I want to talk about Strategy design pattern. In this way I start articles about behavioral design patterns. These kind of patterns represent some schemas of interaction between objects to make a code more flexible and well organized.The most essential point of this approach is loose coupling between objects.
The one of creational design patterns is a Prototype design pattern. Despite that the Prototype is the creational pattern it distinguishes from other patterns by a concept. I mean that the Prototype in some sense creates itself. I'm going to explain it bellow. All magic of the Prototype pattern is based on a clone() method of a java Object. So…
Sometimes there is a need to create a complex object in application. The one solution for this is a Factory pattern, the another one is a Builder design pattern. In some situation you even can combine these two patterns. But in this article I want to examine the Builder design pattern. The first thing which I need to say that it is a creational pattern.