Inversion of Control (IoC), Dependency Inversion Principle (DIP) và Dependency Injection (DI)

Inversion of Control (IoC), Dependency Inversion và Dependency Injection

Mục tiêu giới thiệu Inversion of Control (IoC), Dependency Inversion và mối liên quan giữa 2 khái niệm này với Dependency Injection.

Trên Wikipedia và trong series của Rich cũng không define chính xác IoC là gì. Inversion of Control ý muốn đề cập tới các software architecture designs có flow of control ngược với kiến trúc cũ dạng software libraries (traditional architecture of software libraries). Không có gì ghê gớm cả ... :D, cứ cố hiểu đơn giản vậy là được. Trên blog của Martin Flower cũng có một bài viết khá hay 'Inversion of Control Containers and the Dependency Injection pattern', nếu có thời gian thì bạn có thể tham khảo để biết quan điểm của một người chuyên nghiên cứu về software design.

Inversion of Control in Relation to Frameworks

IoC có quan hệ với framework và code re-used. Thông thường khi sử dụng lại code chúng ta thường call một library của ai đó. Ví dụ trong .NET khi gọi method Math.Tan tức là make a call và tức là có control method đó (đơn là hãy nghĩ rằng sử dụng được nó có nghĩ là control được nó).

Nhưng khi thực hiện implement một IComparable hay IEnumerable thì .NET framework sẽ call ngược lại code implement. Trong những trường hợp này thì direction of control bị đảo ngược: something else calling you. Ví dụ implement IComparable thì phải implement method CompareTo. Khi chúng ta gọi hàm Sort thì .NET framework gọi ngược lại method CompareTo mà chúng ta implement.

Inversion of Control và Dependency Injection

Hai khái niệm này thường được coi là đồng nghĩa tuy nhiên DI chỉ là một dạng đặc biệt mô tả cách thực hiện IoC tức IoC có một phạm vi lớn hơn DI.

Inversion of Control và CAB

CAB là một framework IoC và cho phép chúng ta thực hiện DI. Tức CAB có thể thực hiện call us chứ không hoàn toàn là một framework để chúng ta call method và sử dụng. Ví dụ như trong lab về module loader hàm Load() của ModuleInit đã được CAB thực hiện.

Dependency Inversion

Một term có liên quan và dễ gây bối rối là Dependency Inversion. Dependency Inversion còn gọi là Dependency Inversion Principle- DIP, là wider concept của Dependency Injection. DI chỉ là một phần trong DIP, DIP quy định cách thức mà một high-module cần thực hiện khi sử dụng một low-module. Inversion (đảo ngược) ở đây nằm ở chỗ high level thông thường dựa trên low level thì sẽ chuyển lại giở đây cả high level và low level depend upon một shared abstraction. Software consultant Robert C. Martin (tham khảo Agile Software Development, Principles, Patterns, and Practices published by Prentice Hall 10/15/2002 ISBN-10: 0135974445) phát biểu như sau:

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

Đại khái là module cao hơn không nên phụ thuộc vào module bên dưới. Cả hai nên dựa vào một 'trừu tượng'. 'Trừu tượng' không được phụ thuộc vào 'chi tiết' mà 'chi tiết' sẽ phụ thuộc 'trừu tượng'.

DIP và IoC

Trong bài lab về DI chúng ta chỉ thực hiện invert dependent giữa các classes. Chúng ta chưa thấy IoC xuất hiện rõ ràng trong ví dụ đó. Nói chung chúng ta chưa cần đi quá sâu thay vì chỉ cần hiểu có thể làm được gì với CAB.

CAB & SCSF - Part 03: Dependency Injection

Dependency Injection

Tìm hiểu Dependency Injection ở phạm vi chung không phải Dependency Injection cụ thể cài đặt trong CAB. Mục tiêu hiểu khái quát về khái niệm Dependency Injection.

Giả sử class Car có đang có nhu cầu sử dụng class EngineA. Tuy nhiên có khả năng class Engine sẽ thay đổi trong tương lai hoặc có nhu cầu sử dụng nhiều kiểu Engine khác nhau. Nếu sử dụng thông qua một interface IEngine, khi chuyển qua sử dụng một loại Engine khác là EngineB sẽ không cần thực hiện modify lại code mà chỉ cần thực hiện config lại theo 1 cách nào đó.

Scenario thứ 2 là việc sử dụng engine theo kiểu service yêu cầu nhiều dependency services khác tạo thành một dependency graph. Do đó mỗi khi thực hiện tạo một instance của class Car rất mất công và bạn phải biết constructor hay builder của Engine.

var generator = new Generator();
var engine = new Engine(generator);
var car = new Car(engine);

Có thể thấy một chút giống Strategy Pattern chỉ khác Dependency Injection thiên về việc cấu hình để có thể chọn lựa được class sử dụng tại thời điểm run-time. Việc này có thể thực hiện bằng các ngôn ngữ hỗ trợ reflection. Có 3 loại Dependency Injection là thực hiện qua setter injection, constructor injection và interface injection. Việc thực hiện DI còn liên quan đến 1 việc gọi là service locator. Nhiệm vụ của service locator là xác định đúng engine cần dùng thông qua GetCorrectEngine method. Thông thường một class giả sử tên là EngineLocator sẽ thực hiện nhiệm vụ này.

Constructor method

public interface IEngine
{
    void Start();
}

public class Engine : IEngine
{
    public void Start();
}

public class Car
{
    protected IEngine engine;

    public Car(IEngine engine)
    {
        this.engine = engine;
    }
}

Setter method

public class Car
{
    protected IEngine engine;

    public IEngine Engine
    {
        set
        {
            engine = value;
        }
    }
}

Interface method

public interface IInjectEngine
{
    void InjectEngine(IEngine engine);
}

public class Car: IInjectEngine
{
    protected IEngine engine;

    void IInjectEngine.InjectEngine(IEngine engine)
    {
        this.engine = engine;
    }
}

Thông thường việc thực hiện sẽ dùng hướng interface injection. Đến đây nếu chưa hiểu rõ DI chắc chắn bạn vẫn chưa hình dung được việc tách biệt interface và implement là có ý nghĩa như thế nào và tại sao Car không cần thiết phải chỉnh sửa mà chỉ cần chỉnh sửa thông qua file config.

Implementation

Lập một solution tên là Part03A với các project như sau:

1. Car: console application, có một file là Car.cs, assembly name là ConsoleApp, output ConsoleApp.exe.
2. EngineA: library project, chứa EngineA.cs, assembly EngineA.
3. EngineB: library project, chứa EngineB.cs, assembly EngineB.
4. IEngine: library project, chứa định nghĩa interface.

- Để đơn giản các project đang sử dụng cùng một namespace là DI. Cấu hình Assembly name và default namespace trong Properties của project.

- Bước tiếp theo cấu hình Output của các project giả sử là '..\bin\Debug' mục đích các file IEngine.dll, EngineA.dll và EngineB.dll sẽ cùng thư mục với ConsoleApp.exe (vì các projects này không reference đến nhau)

- Thêm vào Car project một application config file App.config. Add reference tới IEngine cho 3 project còn lại. Việc này có nghĩa Car không có reference tới bất kỳ cài đặt nào của Engine: EngineA hoặc EngineB. Việc này cho phép luôn luôn build OK với Car cho dù có hay không có EngineA và EngineB, do đó việc develop Car là hoàn toàn độc lập với Engine.

Thực hiện code của các file như sau:

IEngine.cs

namespace DI
{
    public interface IEngine
    {
        void Start();
    }
}

IInjectEngine.cs

namespace DI
{
    public interface IInjectEngine
    {
        void InjectEngine(IEngine engine);
    }
}

EngineA.cs và EngineB.cs

public class EngineA : IEngine
{

    public void Start()
    {
        Console.WriteLine("Engine A start...")
    }
}

public class EngineB : IEngine
{

    public void Start()
    {
        Console.WriteLine("Engine B start...")
    }
}

Car.cs

namespace DI
{
    public class Car : IInjectEngine
    {
        IEngine engine;

        public void Start()
        {
            engine.Start();
        }

        public void InjectEngine(IEngine engine)
        {
            this.engine = engine;
        }
    }
}

Program.cs

namespace DI
{
    class Program
    {
        static void Main(string[] args)
        {
            // Create our car and inject the dependency
            Car car = new Car();

            // Service locator, get the correct address based on configuration file
            IEngine engine = GetCorrectEngine();
            ((IInjectCar)car).InjectEngine(engine);

            // Use the car, the method references the car
            // so behavior depends on the configuration file
            car.Start();
            Console.ReadLine();
        }

        // Instantiate and return a class conforming to the IEngine interface:
        // which class gets instantiated depends on the ClassName setting in
        // the configuration file
        static IEngine GetCorrectEngine()
        {
            string className = System.Configuration.ConfigurationSettings.AppSettings["ClassName"];
            Type type = System.Type.GetType(className);
            return (IEngine)Activator.CreateInstance(type);
        }
    }
}

- Method GetCorrectEngine đọc file config và tạo một instance của Engine đúng với implement cần chỉ định thông qua reflection.

- Nếu nội dung file config App.config không đúng (không có key ClassName) việc build vẫn OK tuy nhiên sẽ gặp run-time error vì không tạo được object. Cần phải chỉ định assembly name.

xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="ClassName" value="DI.EngineA" />
  </appSettings>
</configuration>

- Chỉnh lại file config tốt nhất là dùng AssemblyQualifiedName hoặc đơn giản chỉ cần dùng "DI.EngineA, EngineA"

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="ClassName" value="DI.EngineA, EngineA, Version=1.0.0.0, Culture=neutral, PublicKey Token=null" />
  </appSettings>
</configuration>

- Thực hiện thay đổi file config dùng EngineB và run lại application, nhận xét và rút ra kết luận.