Skip to main content

Posts

Showing posts from May, 2020

Message Broker

When we are building systems with multiple components, we need a way to communicate between components. One failed attempt will be direct communication between components. In this solution, components are higly depending on each other.


A better solution will be to use a centralized middleman. All necessary components register with middleman. Middleman recieve all the requests where it find corresponding service to send it.

A broker can:Register, unregister services.Locate services.Recieve and send messages.Error handling.
ProductsThere are many broker systems available. These are just few of them. Apache ActiveMQ, Apache Kafka, RabbitMQ, Websphere ESB, JBoss ESB, Amazon MQ
AdvantagesLoose coupling between components.Scalable and maintainable as long as the interface remain the same.Components are reusable.
DisadvantagesIntroduce single point of failure.Degrade performance due to additional routing.
https://en.wikipedia.org/wiki/Message_broker

Pipes and Filters Architecture

In Linux, when we want to combine results of varies commands to filer out our desired result we use pipe. We feed output of one program as the input of the next. This is fine example of Pipes and Filters pattern.
$ ps aux | grep java
Pipes and filters is a very helpful architectural design pattern for stream of data. Also, it is helpfull when there are data transformations through the sequence.
Source code for the example application.


It consists of number of components called Filters that transform data before handing over to next Filter via connectros called Pipes. Filter - transforms or filters data it receives via the pipe.Pipe - is the connector that passes data from and to filters.Pump - is the data producer.Sink - is the end consumer of the target data. A pipeline consists of a chain of processing elements, arranged so that the output of each element is the input of the next (Wikipedia).
Filter can be a small class as well as a big component. Input, output can be decided by the projec…

Plugin Architechture

If you have used IDE like Ecllipse you may have noticed that you can extend the functionality by adding plugins. Eclipse is an extensible platform. We can add new tools using pluggable components called Eclipse plug-ins. We can create our own plugin by using Eclipse plug-in model.
When we develop softwares we also want to create our applications extensible and modular. We can use plugin architecture to fulfill our needs.

What is a Plug-in?A plug-in (or plugin, add-in, addin, add-on, or addon) is a software component that adds a specific feature to an existing computer program. (Wikipedia)
In plugin architecture, core modules may not know all existing features, instead we plug them at loading time. We are taking advantage of separation of concerns. Plugins is a fine example of open closed principle where we are extending existing functionality without changing main logic. AdvantagesExtensible - plugin can be developed outside the main program and extend the behaviour without touching it.In…

Tail of list.remove()

When I was checking a code I saw this suspicous line,
list.remove(object) However, I'm in differenct team hence this is not related to me. Anyway, I informed the developer, who is a Lead, probably senior to me. Since there team is OK with this and it is working for their use case (but not that safe) I have nothing to do but share the knowledge in my blog.

If you google how to remove a value form a list you sure will hit List.remove(E element). Question is, are you using it correctly?

Working scenario Let's check this out with a String first.
  @Test
  public void testStringListRemove() {
    List<String> list = new ArrayList<>();
    list.add("AB");
    list.add("CD");
    list.add("EF");
    list.remove("CD");
    Assertions.assertEquals(2, list.size());
  } Test is passing. Does that mean i'm wrong. No, Java String uses a pool hence "CD" is same object. This is completely correct.

Failing Scenario Now let's see this …

Dependency Inversion Principle (DIP)

D of the SOLID principle is Dependency Inversion Principle also known as DIP.

This is one of those very powerful principle to build highly-decoupled well structured software.



What is Dependency Inversion Principle? The dependency inversion principle is a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. (wikipedia)
Depend on abstractions, not on concretions.
Robert C. Martin’s definition of the Dependency Inversion Principle consists of two parts:
High-level modules should not depend on low-level modules. Both should depend on abstractions.Abstractions should not depend on details. Details should depend on abstractions.



The idea here is that high-level module should not depend on low-level modules. Both should only depend on the a…

Layered Architecture

When our project start growing, eventually we end up where to put my code delima. It is quite hard organize the code if we are not careful.

This is when we can use well known three-tier architecture. It helps us to divide the codebase into three separate layers with clear distinctive responsibilities.


But why?Before taking any architectural decision we better ask the question ourself. Why do we need to do this. It is all about simplification. End of the day we need not only a working system, but we need a highly maintainable system.
Layer isolation gives us possibility to separate the concerns with clear responsibilities. But why, we can do our changes without inpacting other layers. Any new business requirement will have very small change. There will be zero breaking changes.
For an example we should never do any SQL operation in presentation layer.

We can build, deploy our layers separately.

Introducing our layersPresentation layer - represents user interface.Business logic layer - all …