Friday, 15 December 2017

Clean Factory Design Pattern with IoC container


This article expects audience have familiarity with Dependency Inversion Principle (DIP) and Factory Design Pattern. For simplicity, the code is not defensive and there is no guarded statements. The code is using Simple Injector, but the described principles applies to other IoC container frameworks as well. The source code of the examples can be found in github by following this link


When implementing a factory class in a project which uses a Inversion of Control (IoC) container, and you arrive to the solution described below, then this article is for you:
using System;
using DirtyFactory.Dependencies;

namespace DirtyFactory.Processors
 internal class ProcessorFactory : IProcessorFactory
  private readonly IDependencyOne _depOne;
  private readonly IDependencyTwo _depTwo;
  private readonly IDependencyThree _depThree;

  public ProcessorFactory(IDependencyOne depOne, IDependencyTwo depTwo, IDependencyThree depThree)
   _depOne = depOne;
   _depTwo = depTwo;
   _depThree = depThree;

  public IProcessor Create(RequestType requestType)
    case RequestType.Internal:
     return new InternalProcessor(_depOne, _depTwo);
    case RequestType.External:
     return new ExternalProcessor(_depOne, _depThree);
     throw new NotImplementedException();

Monday, 21 August 2017

Deep Dive into OWIN Katana

I was asked to give a presentation about OWIN and Web API to a different development team, as they wanted an introduction to the technology and no one in the team had exposure to that technology before. Prior to that, I have developed a number of internal API for our company. With the presentation slides and materials, I decide to write them down as a blog post as well, so it will be documented properly. I put a lot of extra information compared to the original presentation to cover a broader audience in the internet.

Saturday, 25 March 2017

Generic Pattern: How to do Fluent-API on both Derived and Base classes

I would like to share a lesson learned from work. I am working on a FHIR (Fast Healthcare Interoperability Resources) project. The task at hand was to create builder classes, which basically populate properties of different kinds of resource objects (e.g Patient, Order, Schedule , etc). All these resources are derived from the same object called Resource, which comprises properties such as Id, Meta (contains VersionId and Profile). The derived classes may have their own specialization properties/fields.

Saturday, 28 January 2017

SNOMED CT (Systemized Nomenclature of Medicine Clinical Term)

With recent NHS initiative to replace their clinical terminology, READ Version 3(or CTV3), with SNOMED CT (Systemized Nomenclature of Medicine Clinical Term), there may be a lot of questions raised about this terminology. I first knew about this terminology, in 2008,

Saturday, 21 May 2016

Dependency Inversion Principle: Part 5 - Using DIP/IoC container

(Note: you should read Part4 - Refactoring Using DIP before in order to understand this section)

I can just stop after refactoring code in previous section. I don't really need to use a DIP/IoC container. However most containers will have some additional features which enable us to tidy up the class composition code. You can even write your own IoC container with the features you really need.

Dependency Inversion Principle: Part 4 - Refactoring Using DIP

You have known the basic concepts of DIP, now it is time to apply it to the code. If the code is written without DIP principles, this means the code needs a refactoring by abstracting and inverting the dependencies. The code will normally have many interactions between classes. This mean that a class may have dependencies, but in turn the class will be the dependency of other class.

Refactoring the code using DIP will eventually create a tree structure which represents the class composition. Normally there will be one composition root, which is the class at the top of the tree.

Dependency Inversion Principle: Part 3 - Dependency Inversion Methods

After various parts of the class have been abstracted, the next thing to do is inverting the dependencies. The actual implementation of the abstraction, or dependencies, need to be provided from outside of the class. By doing so, the class now does not depend on the implementation, but only the abstraction of it.