Đảo ngược kiểm soát là gì?

1826

Inversion of Control (IoC) có thể khá khó hiểu khi lần đầu tiên gặp phải.

Nó là gì?
Vấn đề nào nó giải quyết?
Khi nào thì thích hợp để sử dụng và khi nào thì không?

oop design-patterns inversion-of-control

— Mike Minutillo
nguồn

292

Vấn đề với hầu hết các câu trả lời này là thuật ngữ được sử dụng. Container là gì? Nghịch đảo? Phụ thuộc? Giải thích nó trong điều khoản cư sĩ mà không có những từ lớn.

— kirk.burleson

13

Xem thêm trên Lập trình viên. E: Tại sao Inversion of Control được đặt tên theo cách đó?

— Izkata

8

Đó là Tiêm phụ thuộc (DI) - xem phần suy giảm của Martin Fowlers tại đây: martinfowler.com/articles/injection.html#InversionOfControl

— Ricardo Sanchez

7

Bức ảnh này tổng hợp lại

— totymedli

Nó là một tính từ, không phải danh từ, nó không phải là một thứ, nó là một mô tả về một sự thay đổi được thực hiện cho mã, trong đó sự kiểm soát dòng chảy nằm trong đại biểu, không phải là container.

— Martin Spamer

1523

Các mẫu Inversion of Control (IoC) và Dependency Injection (DI) là tất cả về việc loại bỏ các phụ thuộc khỏi mã của bạn.

Ví dụ: giả sử ứng dụng của bạn có thành phần soạn thảo văn bản và bạn muốn cung cấp kiểm tra chính tả. Mã tiêu chuẩn của bạn sẽ trông giống như thế này:

public class TextEditor {

    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

Những gì chúng tôi đã làm ở đây tạo ra một sự phụ thuộc giữa TextEditorvà SpellChecker. Thay vào đó, trong kịch bản IoC, chúng ta sẽ làm một cái gì đó như thế này:

public class TextEditor {

    private IocSpellChecker checker;

    public TextEditor(IocSpellChecker checker) {
        this.checker = checker;
    }
}

Trong ví dụ mã đầu tiên, chúng tôi đang khởi tạo SpellChecker( this.checker = new SpellChecker();), có nghĩa là TextEditorlớp trực tiếp phụ thuộc vào SpellCheckerlớp.

Trong ví dụ mã thứ hai, chúng ta đang tạo ra một sự trừu tượng hóa bằng cách có SpellCheckerlớp phụ thuộc trong TextEditorchữ ký của hàm tạo (không khởi tạo phụ thuộc trong lớp). Điều này cho phép chúng ta gọi phần phụ thuộc sau đó chuyển nó đến lớp TextEditor như sau:

SpellChecker sc = new SpellChecker; // dependency
TextEditor textEditor = new TextEditor(sc);

Bây giờ ứng dụng khách tạo TextEditorlớp có quyền kiểm soát SpellCheckerviệc sử dụng triển khai nào vì chúng ta sẽ thêm phụ thuộc vào TextEditorchữ ký.

— urini
nguồn

50

Tốt ví dụ rõ ràng. Tuy nhiên, giả sử thay vì yêu cầu giao diện ISpellChecker được chuyển đến hàm tạo của đối tượng, chúng tôi đã hiển thị nó dưới dạng một thuộc tính có thể thiết lập (hoặc phương thức SetSpellChecker). Điều này vẫn sẽ tạo thành IoC?

— devios1

25

chainguy1337 - vâng. Sử dụng setters như thế được gọi là tiêm setter trái ngược với tiêm xây dựng (cả hai kỹ thuật tiêm phụ thuộc). IoC là một mô hình khá chung chung, nhưng tiêm chích phụ thuộc đạt được IoC

— Jack Ukleja

257

Mặc dù có nhiều lượt bình chọn, câu trả lời này không chính xác. Vui lòng xem martinfowler.com/articles/injection.html#InversionOfControl . Cụ thể, lưu ý phần "Inversion of Control là một thuật ngữ quá chung chung, và do đó mọi người thấy nó khó hiểu. Kết quả là có rất nhiều cuộc thảo luận với những người ủng hộ IoC khác nhau, chúng tôi đã giải quyết cái tên Dependency Injection".

— Rogério

45

Tôi đồng ý với @Rogeria. điều này không giải thích tại sao nó được gọi là IoC và tôi ngạc nhiên về số lượng phiếu bầu tăng lên ;-)

— Aravind Yarram

31

Tôi bên cạnh @Rogerio và @Pangea. Đây có thể là một ví dụ tốt cho tiêm xây dựng nhưng không phải là một câu trả lời tốt cho câu hỏi ban đầu. IoC, như được định nghĩa bởi Fowler , có thể được nhận ra mà không cần sử dụng bất kỳ loại tiêm nào, ví dụ: bằng cách sử dụng công cụ định vị dịch vụ hoặc thậm chí là kế thừa đơn giản.

— mtsz

642

Inversion of Control là những gì bạn nhận được khi gọi lại chương trình, ví dụ như chương trình gui.

Ví dụ: trong thực đơn trường học cũ, bạn có thể có:

print "enter your name"
read name
print "enter your address"
read address
etc...
store in database

từ đó kiểm soát luồng tương tác của người dùng.

Trong một chương trình GUI hoặc somesuch, thay vào đó chúng ta nói:

when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase

Vì vậy, bây giờ điều khiển được đảo ngược ... thay vì máy tính chấp nhận đầu vào của người dùng theo một thứ tự cố định, người dùng sẽ kiểm soát thứ tự nhập dữ liệu và khi dữ liệu được lưu trong cơ sở dữ liệu.

Về cơ bản, bất cứ điều gì có vòng lặp sự kiện, cuộc gọi lại hoặc kích hoạt thực thi đều thuộc loại này.

— Đánh dấu Harrison
nguồn

161

không đánh dấu anh chàng này xuống. về mặt kỹ thuật, anh ấy đúng martinfowler.com/bliki/InversionOfControl.html IoC là một hiệu trưởng rất chung chung. Luồng kiểm soát bị "đảo ngược" bởi việc tiêm phụ thuộc vì bạn đã ủy thác hiệu quả các phụ thuộc vào một số hệ thống bên ngoài (ví dụ: container IoC)

— Jack Ukleja

38

Đồng ý với nhận xét của Schneider. 5 điểm hạ gục? Kính râm, vì đây là câu trả lời duy nhất thực sự đúng. Lưu ý phần mở đầu: ' giống như một chương trình gui.' Việc tiêm phụ thuộc chỉ là sự hiện thực hóa thường thấy nhất của IoC.

— Jeff Sternal

40

Thật vậy, đây là một trong số ít các anwsers chính xác ! Các bạn, IoC không cơ bản về sự phụ thuộc. Không có gì.

— Rogério

13

+1 - Đây là một mô tả hay (ví dụ) về tuyên bố sau của Martin Fowler - "Giao diện người dùng sớm được điều khiển bởi chương trình ứng dụng. Bạn sẽ có một chuỗi các lệnh như" Nhập tên "," nhập địa chỉ "; chương trình sẽ điều khiển các lời nhắc và nhận phản hồi cho từng người. Với các UI đồ họa (hoặc thậm chí dựa trên màn hình), khung UI sẽ chứa vòng lặp chính này và thay vào đó chương trình của bạn cung cấp các trình xử lý sự kiện cho các trường khác nhau trên màn hình. chương trình đã bị đảo ngược, chuyển từ bạn sang khuôn khổ. "

— Ashish Gupta

14

Bây giờ tôi hiểu lý do tại sao đôi khi nó được gọi một cách vô tình là "Nguyên tắc Hollywood: Đừng gọi cho chúng tôi, chúng tôi sẽ gọi cho bạn"