Design

Setting up sharded mongodb cluster in localhost

by

I have been playing around with MongoDb, thanks to the M101J Course offered by Mongodb University. These NoSQL datastores are gaining popularity due to a number of reasons and one among them being the ease with which they can be scaled out i.e horizontal scaling. This horizontal scaling in MongoDB can be achieved by creating a sharded cluster of mongodb instances.

You might want to understand the concept of sharding before continuing. The MongoDB reference has a very clear explanation for the same here.

Read more

Getting rid of Getters and Setters in your POJO

by

We all have read in Java books about encapsulation of fields in Java class and also when ever you code you are asked to take special care in encapsulating the fields and providing explicit Getters and Setters. And these are very strict instructions. Lets step back a bit and find out the reason behind encapsulating … Read more

Strategy Pattern using Lambda Expressions in Java 8

by

Strategy Pattern is one of the patterns from the Design Patterns : Elements of Reusable Object book. The intent of the strategy pattern as stated in the book is: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. In this post … Read more

Simple example to illustrate Chain Of Responsibility Design Pattern

by

GoF Design pattern book states the intent of Chain of Responsibility pattern as: Avoid coupling the sender of a request to the receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. The main intention in … Read more

My First steps in Test Driven Development- A Win-Win strategy

by

Agile practitioners talk about Test Driven Development(TDD), so do lot of developers who care about their code quality and workability. And I once upon a time, not so long ago managed to read about TDD. The crux of TDD as I have understood is: Write Test, and fail Code, make the tests succeed Automate the … Read more

Using JDeodorant to refactor java code

by

I got to know about JDeodorant– a tool for identifying bad smells in code and helping it to refactor. I got curious and downloaded its Eclipse plugin, I then picked the first bad smell code which Martin Fowler explains in his book: “Refactoring: Improving the design of existing code”. I tried my hand at refactoring a long method by Extract Method refactor move. Here’s the long method:

Read more

Why is the legacy code is the way it is?

by

google search for define: legacy gives:

leg·a·cy/ˈlegəsē/

Noun: An amount of money or property left to someone in a will.

Adjective: Denoting software or hardware that has been superseded but is difficult to replace because of its wide use.

Most of us would have worked on legacy code OR are working on it OR are even creating legacy code (!!). Just the thought of working on legacy code makes developers spend sleepless nights (yeah, slight exaggeration, but required to highlight the pain). We have yelled and cursed while working on legacy code. Lets step back and reflect a bit about legacy code and see how it can be tackled (if at all!)

Read more

Redundancy – An open enemy to writing good code

by

Those who are working on High Available systems/databases consider Redundancy as one of the possible ways to achieve high availability. Redundancy in this case is helping in positive way. But consider the other side of it- In a high available database systems the data is replicated across different nodes. Any change/update at one node has to be propagated to all other nodes, failure during replication can cause mismatch in the data at different nodes. This shows redundancy is both good and bad. But why I am writing about high available systems when the title says “good code”. Because when it comes to redundancy in code- there is NO goodness in it.

The most common tendency of every programmer is to Copy-Paste. I remember reading somewhere that programmers have to be lazy, but where ever I read it the author didn’t mean that being lazy is to Copy-Paste. Instead its to write code which is concise and clear. One of the possible reasons why we tend to Copy-Paste is because the design of the existing code doesn’t facilitate reuse. Now any change to code at one place would trigger same change at multiple places. This is one of the most common ways of introducing redundancy.

Read more

Another aspect of coupling in Object Oriented paradigm

by

I had previously written a post related to coupling and cohesion here and that was more of a basic definition of both the terms.

In this post I would like to throw some light on the tight dependency on the type of the component in use. Generally we would aim to design classes such that they interact via the interfaces or more generally put via API. Suppose we use interfaces (more of a generic term where we dont have implementations, not specific to keyword interface in Java or C#), but this is not enough, we need to provide some kind of implementation for the interface which is actually consumed by the other client classes.

Read more

SOLID- Liskov Substitution Principle

by

Liskov Substitution principle (LSP) states that,

Methods that use references to the base classes must be able to use the objects of the derived classes without knowing it

This principle was written by Barbara Liskov in 1988.

The idea here is that the subtypes must be replaceable for the super type references without affecting the program execution.

This principle is very closely related to Open Closed Principle(OCP), violation of LSP in turn violates the OCP. Let me explain:

Read more