Manju

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. Products There are many broker systems available. These are just few of them. Apache ActiveMQ, Apache Kafka, RabbitMQ, Websphere ESB, JBoss ESB, Amazon MQ Advantages Loose coupling between components. Scalable and maintainable as long as the interface remain the same. Components are reusable. Disadvantages Introduce single point of failure. Degrade performance due to additional routing. https://en.wikipedia.org/wiki/Message_broker

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...

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. Advantages Extensible - plugin can be developed outside the main program and extend the behaviour without touching ...

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 co...

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....