Design pattern Quick Guide

Observer Pattern :  Behavioral pattern

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Real Life example:

• RSS feeds.  When I want to get updates from a particular feed, I add it to my feed reader. Any time that the RSS feed has an update, it will appear in my reader automatically.  This is the Observer pattern in action, a publisher/subscriber relationship with one source having many subscribers 
• The whole concept of listeners is based on this pattern.

Adapter Pattern : Structural pattern


Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

Real Life Example:

• The best example for the adapter pattern is based around AC power adapters.

Downside:
Adapter pattern is just a fix for a badly designed system, which didn't consider all possibilties. While this is a fair point, it is an important part of a pluggable architecture.  It can also add a level of complexity to your code, making debugging more difficult.

The Facade pattern  : Structural pattern

Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

Real Life Example:

• Concept behind facade is to simplify an interface, service oriented architectures make use of the facade pattern. For example, in web services, one web service might provide access to a number of smaller services that have been hidden from the caller by the facade.

Downside:
 By introducing the Facade into your code, you will be hardwiring subsystems into the Facade. This is fine if the subsystem never changes, but if it does, your Facade could be broken. Therefore, developers working on the subsystem should be made aware of any Facade around their code.

Factory method pattern : Creational pattern

Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses

Real Life Example:

• The idea behind the Factory Method pattern is that it allows for the case where a client doesn't know what concrete classes it will be required to create at run-time, but just wants to get a class that will do the job. The FactoryMethod builds on the concept of a simple Factory, but lets the subclasses decide which implementation of the concrete class to use.  You'll see factories used in logging frameworks, and in a lot of scenarios where the client doesn't need to know about the concrete implementations. It's a good approach to encapsulation.

Abstract Factory Pattern : Creational pattern
Provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Strategy Pattern : Behavioral pattern
Defines a set of encapsulated algorithms that can be swapped to carry out a specific behaviour

Real Life Example:

• Compression algorithm

Visitor Pattern : Behavioral pattern
Allows for one or more operation to be applied to a set of objects at runtime, decoupling the operations from the object structure.

Mongo sharding example

### To Start config server instance (config server port: 27019)
mongod.exe --configsvr --dbpath ../../configdb --port 27019

### To start mongos instance (router) (router port: 27017)
mongos.exe --configdb localhost:27019

###Adding a shard
First start mongoDb instance
mongod.exe --config ../../mongo.cfg
mongod.exe --config ../../mongo1.cfg

Config file content:
##store data here
dbpath=C:\poc\mdb\data

##all output go here
logpath=C:\poc\mdb\log\mongo.log

##log read and write operations
##diaglog=3

###Auth detail admin/admin
auth=false

##Port binding
port=27020

###Open a new instance and add above mongodb instance in cluster:
mongo.exe --host localhost --port 27017 
once mongos console connected:
 sh.addShard("localhost:27020")
 sh.addShard("localhost:27021") 

sh.enableSharding("ankur")
use config
db.databases.find()

###Insert bulk data

for (var i = 1; i <= 1000; i++) db.test_collection.insert( { x : i } )

###To know the shard status

sh.status()

###To shard a collection

 sh.shardCollection("ankur.records",{"zip":1, "name":1})

###Data insertion

{
db.records.insert( { zip : 60111 , name: "ankur"})
db.records.insert( { zip : 60111 , name: "goel"})
db.records.insert( { zip : 50111 , name: "ankur"})
db.records.insert( { zip : 50111 , name: "goel"})
db.records.insert( { zip : 70111 , name: "dr"})
} 

###To know chunk distribution
db.records.getShardDistribution()


Source: http://docs.mongodb.org/manual/reference/method/#sharding

A day with Maven

POM: Project Object Model

Maven has three life cycle:

• Clean
• default (build)
• Site

Clean Life cycle has following phases:

• Pre-Clean
• Clean
• Post-Clean

Build(or Default) life cycle has following phase(primarily used) sequence. (Build Life cycle has 23 phases):

• prepare-resources
• compile
• package
• Install

Site life-cycle has following phases:

• pre-site
• site
• post-site
• site-deploy

Syntax for life-cycle and phase:
mvn <life-cycle> : <phase>
ex: mvn clean:clean

Syntax for activating profile:
mvn <life-cycle>/<phase>   -P<profile>
ex: mvn clean -P phix


When a phase is called via Maven command, for example mvn compile, only phases upto and including that phase will execute.

In Maven terminology, a repository is a place i.e. directory where all the project jars, library jar, plugins or any other project specific artifacts are stored and can be used by Maven easily.

Maven repository are of three types

•     local
•     central (by default: http://repo1.maven.org/maven2/) can be browsed: http://search.maven.org/#browse
•     remote (if not available in local and central repository, then if configured searched)

Maven is actually a plugin execution framework where every task is actually done by plugins.

A plugin generally provides a set of goals and which can be executed using following syntax:
mvn <plugin-name>:<goal-name>

Maven provided two types of plugin:

• Build plugins (They execute during the build and should be configured in the <build/> element of pom.xml)
• Reporting plugins (They execute during the site generation and they should be configured in the <reporting/> element of the pom.xml)

Dependency Management:
The dependency management section is a mechanism for centralizing dependency information. When you have a set of projects that inherits a common parent it's possible to put all information about the dependency in the common POM and have simpler references to the artifacts in the child POMs.

For parent:

<dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>test</groupId>
       <artifactId>a</artifactId>
       <version>1.2</version>
     </dependency>

   </dependencies> 

</dependencyManagement>

For child: If below code is not copied in child then no dependency will be included in child project from parent. Need to define all required dependency in child project.

  <dependencies>
    <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-a</artifactId>
    </dependency>

 </dependencies>