Giả sử giao diện IReader, triển khai giao diện IReader ReaderImcellenceation và một lớp ReaderConsumer tiêu thụ và xử lý dữ liệu từ đầu đọc.

public interface IReader
{
     object Read()
}

Thực hiện

public class ReaderImplementation
{
    ...
    public object Read()
    {
        ...
    }
}

Khách hàng:

public class ReaderConsumer()
{
    public string location

    // constructor
    public ReaderConsumer()
    {
        ...
    }

    // read some data
    public object ReadData()
    {
        IReader reader = new ReaderImplementation(this.location)
        data = reader.Read()
        ...
        return processedData    
    }
}

Để kiểm tra ReaderConsumer và quá trình xử lý, tôi sử dụng một mock của IReader. Vì vậy, ReaderConsumer trở thành:

public class ReaderConsumer()
{
    private IReader reader = null

    public string location

    // constructor
    public ReaderConsumer()
    {
        ...
    }

    // mock constructor
    public ReaderConsumer(IReader reader)
    {
        this.reader = reader
    }

    // read some data
    public object ReadData()
    {
        try
        {
            if(this.reader == null)
            {
                 this.reader = new ReaderImplementation(this.location)
            }

            data = reader.Read()
            ...
            return processedData    
        }
        finally
        {
            this.reader = null
        }
    }
}

Trong giải pháp này, mocking giới thiệu một câu if cho mã sản xuất vì chỉ có hàm tạo mô phỏng cung cấp một thể hiện của giao diện.

Trong quá trình viết này, tôi nhận ra rằng khối thử cuối cùng có phần không liên quan vì nó ở đó để xử lý người dùng thay đổi vị trí trong thời gian chạy ứng dụng.

Nhìn chung, nó cảm thấy có mùi, làm thế nào nó có thể được xử lý tốt hơn?

Thay vì khởi tạo trình đọc từ phương thức của bạn, hãy di chuyển dòng này

{
    this.reader = new ReaderImplementation(this.location)
}

Vào hàm tạo không tham số mặc định.

public ReaderConsumer()
{
    this.reader = new ReaderImplementation(this.location)
}

public ReaderConsumer(IReader reader)
{
    this.reader = reader
}

Không có thứ gọi là "hàm tạo giả", nếu lớp của bạn có một phụ thuộc mà nó yêu cầu để hoạt động, thì hàm tạo nên được cung cấp thứ đó hoặc tạo nó.

Bạn chỉ cần hàm tạo duy nhất:

public class ReaderConsumer()
{
    private IReader reader = null

    public string location

    // constructor
    public ReaderConsumer(IReader reader)
    {
        this.reader = reader;
    }

trong mã sản xuất của bạn:

var rc = new ReaderConsumer(new ReaderImplementation(0));

trong bài kiểm tra của bạn:

var rc = new ReaderConsumer(new MockImplementation(0));

Nhìn vào tiêm phụ thuộc và đảo ngược kiểm soát

Cả Ewan và RubberDuck đều có câu trả lời tuyệt vời. Nhưng tôi muốn đề cập đến một lĩnh vực khác để xem xét đó là Dependency Injection (DI) và Inversion of Control (IoC). Cả hai cách tiếp cận này đều đưa vấn đề bạn gặp phải vào một khung / thư viện để bạn không phải lo lắng về nó.

Ví dụ của bạn rất đơn giản và nhanh chóng được phân phối, nhưng, chắc chắn bạn sẽ xây dựng nó và bạn sẽ kết thúc với hàng tấn các hàm tạo hoặc các thói quen khởi tạo giống như:

var foo = new Foo (Thanh mới (mới Baz (), Quz mới ()), Foo2 ()) mới;

Với DI / IoC, bạn sử dụng một thư viện cho phép bạn đánh vần các quy tắc để khớp giao diện với các triển khai và sau đó bạn chỉ cần nói "Hãy cho tôi một Foo" và nó tìm ra cách nối tất cả.

Có rất nhiều Container IoC rất thân thiện (như chúng được gọi) ngoài đó, và tôi sẽ khuyên bạn nên xem xét, nhưng, vui lòng khám phá, vì có rất nhiều lựa chọn tốt.

Một cách đơn giản để bắt đầu là:

http://www.ninject.org/

Dưới đây là danh sách để khám phá:

http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx