Month: May 2014

IoC vs Dependency Injection (DI) vs. Service Locator (SL)

IoC vs DI (Dependency Injection)? IoC is the general concept where control of flow is *Inverted* from client code to framework, which “Does something for the client”. SL (Service Locator) and DI (Dependency Injection) are two design patterns stem off from IoC.
1. In case of DI (Dependency Injection), the application framework returns to client pre-configured dependencies. Dependencies are configured by way of Constructor|Setter|Method “Injection” – Injection is just a big word for simply “Setting member variables” via Constructor|Setter|Method.
In Spring.NET, dependency config are stored in xml config file, further reduces what “client” need to know about the dependencies in order to use them.

2. In case of SL (Service Locator), the application framework, containing all services instances, returns relevant Service instance by looking up a map, with a *key* specified by client. Service Locator which is basically a map.
Example, 3 of 10 dependencies, which your team develop, we use Spring.NET. 7 of 10 use Unity – developed by another application team. SL look up the type of dependency client requests, and instantiate+configure the requested dependency using either Spring.NET, or Unify, depending on mapping. (See example below)


Here’s one example to show difference between Service Locator, and Dependency Injection:

public interface IIoCService
Object GetProxy(Type T, string Name);

public class UnityIoC
IUnityContainer UnityCtx = new UnityContainer();

public UnityIoC()
… type registrations …

public Object GetProxy(Type T, string Name)
return UnityCtx.Resolve(T, Name); // Unity we get proxy via “Resolve” method, unlike Spring, takes argument Type T

public class SpringIoC : IIoCService
private IApplicationContext SpringCtx = ContextRegistry.GetContext();

public Object GetProxy(Type T, string Name)
return SpringCtx.GetObject(Name); // DI: Spring get proxy via “GetObject” – Spring Framework instantiate + pre-configure proxy in accordance to specification from app|web.config

public class IoCServiceLocator
private IDictionary<Type, IIocService> map = …

public static Object GetProxy(Type type)
IIoCService Service = map[type];
return Service.GetProxy(type, type.Name);

From client code,
ISomeImpl1 Proxy1 = (ISomeImpl1) IoCServiceLocator.GetProxy(typeof(Depend_1));
ISomeImpl4 Proxy4 = (ISomeImpl4) IoCServiceLocator.GetProxy(typeof(Depend_4));

In this example,

(a) Instantiation and Configuration of Proxy1 and Proxy4 are done via DI (Dependency Inject) with Spring.NET and Unity respectively.
(b) IoCServiceLocator implements Service Locator patterns which locates *mapped* IoC container based on type client is requesting.

Hope this clears some of the confusion around the subject IoC vs DI vs SL.


Java Road Tripping

Again, while reading through the Spring documentation, I came across this article of Martin Fowler.
I’ll try to give a summary of his article and my opinions about it.


Every professional software engineer should know what dependency injection or inversion of control is about, but i’ll try to explain it for those who don’t.
I’ll use quite the same examples as Martin did in his article, which I’ll try to update a little. You can find a link to the source code at the bottom of this blog post (Maven is required to build the source).

Imagine you have to display a list of movies directed by a specified director.
I have an interface and a concrete implementation for finding movies.

To list the movies with a specified director, the following code is used:

Especially the MovieFinder at line 02 is of importance here.
You need to have a…

View original post 2,214 more words


Monte Carlo – Estimate π (Pi) and Option Pricing

Here’s elaboration on John Hull’s “Options, Futures, and Other Derivatives”, chapter on “Basic Numerical Procedures”. What I’ve added is graphics to help understand the procedure.

Assume a circle fits inside a square with dimension 1 x 1. Now imagine, you’re throwing random darts at it. What are the chances it will hit inside the circle?

Monte Carlo basically is a numerical method where you randomly generate random numbers “a” and “b” a hundred times.  Each time, if sq(a) + sq(b) < sq(r), then it’s inside the circle. At the end of the hundred trials, count # hits inside circle. # hits inside circle / 100 = probability of hitting the circle = Area of Circle / Area of Square. Then, solve for π.

Detail as follows,

Estimate π using Monte Carlo 1

Estimate π using Monte Carlo 2


Estimate π using Monte Carlo 3

To do this from Excel,

A = RAND()

B = RAND()

C = sq (A-r) =(A2-0.5)^2

D = sq (B-r) = =(B2-0.5)^2

E = sq (A-r) + sq (B-r) =C2+D2

F =IF(E2<(0.5^2), 1, 0)

(i.e. If dart inside circle, F = 1, if dart outside circle, F = 0)

I2 = COUNTIF(F2:F1001, 1)


I4 = I3 x 4

Shown below Excel sheet simulation.

Estimate π using Monte Carlo 4


Monte Carlo in Option Pricing (Quantitative Finance)

There’re basically three ways you can price an option,

a. Black Sholes



  • European option/can’t exercise early
  • constant vol/rates
  • no provision for dividend, transaction fee
  • assume you can always short underlier
  • Price movement is normally distributed

Advantage? Fast


b. Lattice/Binomial Tree

Advantage? Much fewer assumptions but slow.

Disadvantage? A 20 steps non-recombining tree can contain a million nodes.


c. Monte Carlo

Monte Carlo simulation is also used in pricing options where option price is dependent on price history of underlying asset (for example, look-back or Asian options – i.e. Path Dependent) or those where underlying spot movement doesn’t follow “Normal Distribution” (which is foundation of Black Sholes and lattice based price tree generation)

In essence, Monte Carlo, in context of option pricing, is just a methodology where market variable (may it be spot price of underlying stock of an equity option, or interest/Exchange rate) is randomly generated over time from time=0 to time=maturity. Underlying spot at maturity is then used to calculate option payoff. Repeat this procedure over a hundred times, take the average payoff calculated over these hundred iterations, discount it to present value: That’s your option value from Monte Carlo simulation

Advantage? Less Computationally intensive than binomial tree.

Disadvantage? Every time you run the same calculation you have a different number if # trials too small. (Should converge otherwise)

Option Pricing using Monte Carlo



For European options, you can:

STEP 1. Run Numerical Approximation from time=0 to time=maturity to estimate underlying spot at Maturity

STEP 2. Calculate payoff based on that estimation on underlying spot @ maturity

STEP 3. Repeat STEP 1-2 a hundred times

STEP 4. Take average over the hundred runs as payoff of option value