Tôi đang gặp khó khăn trong việc tìm kiếm tài nguyên về lý do tại sao tôi nên sử dụng tiêm phụ thuộc . Hầu hết các tài nguyên mà tôi thấy giải thích rằng nó chỉ chuyển một thể hiện của một đối tượng sang một thể hiện khác của một đối tượng, nhưng tại sao? Đây có phải chỉ dành cho kiến ​​trúc / mã sạch hơn hay điều này ảnh hưởng đến toàn bộ hiệu suất?

Tại sao tôi nên làm như sau?

class Profile {
    public function deactivateProfile(Setting $setting)
    {
        $setting->isActive = false;
    }
}

Thay vì sau đây?

class Profile {
    public function deactivateProfile()
    {
        $setting = new Setting();
        $setting->isActive = false;
    }
}

Ưu điểm là không cần tiêm phụ thuộc, lớp Hồ sơ của bạn

• cần biết cách tạo đối tượng Cài đặt (vi phạm Nguyên tắc Trách nhiệm Đơn lẻ)
• Luôn tạo đối tượng Cài đặt của nó theo cùng một cách (tạo khớp nối chặt chẽ giữa hai)

Nhưng với tiêm phụ thuộc

• Logic để tạo các đối tượng Cài đặt là ở một nơi khác
• Thật dễ dàng để sử dụng các loại đối tượng Cài đặt khác nhau

Điều này có vẻ (hoặc thậm chí) không liên quan trong trường hợp cụ thể này, nhưng hãy tưởng tượng nếu chúng ta không nói về một đối tượng Cài đặt, mà là một đối tượng DataStore, có thể có các triển khai khác nhau, một lưu trữ dữ liệu trong tệp và một đối tượng khác lưu trữ dữ liệu đó Một cơ sở dữ liệu. Và đối với các bài kiểm tra tự động, bạn cũng muốn thực hiện giả. Bây giờ bạn thực sự không muốn lớp Hồ sơ mã hóa cái mà nó sử dụng - và thậm chí quan trọng hơn, bạn thực sự, thực sự không muốn lớp Hồ sơ biết về đường dẫn hệ thống tệp, kết nối DB và mật khẩu, vì vậy việc tạo các đối tượng DataStore có thể xảy ra ở một nơi khác.

Dependency Injection làm cho mã của bạn dễ kiểm tra hơn.

Tôi đã học được điều này khi tôi được giao nhiệm vụ sửa một lỗi khó bắt gặp trong tích hợp PayPal của Magento.

Một vấn đề sẽ nảy sinh khi PayPal nói với Magento về khoản thanh toán thất bại: Magento sẽ không đăng ký thất bại đúng cách.

Việc kiểm tra bản sửa lỗi tiềm năng "thủ công" sẽ rất tẻ nhạt: bạn cần bằng cách nào đó kích hoạt thông báo PayPal "Không thành công". Bạn sẽ phải gửi một kiểm tra điện tử, hủy bỏ nó và chờ cho nó lỗi. Điều đó có nghĩa là hơn 3 ngày để kiểm tra thay đổi mã một ký tự!

May mắn thay, có vẻ như các nhà phát triển lõi Magento đã phát triển chức năng này đã thử nghiệm và sử dụng mô hình tiêm phụ thuộc để làm cho nó trở nên tầm thường. Điều này cho phép chúng tôi xác minh công việc của mình với một trường hợp thử nghiệm đơn giản như thế này:

<?php
// This is the dependency we will inject to facilitate our testing
class MockHttpClient extends Varien_Http_Adapter_Curl {
    function read() {
        // Make Magento think that PayPal said "VERIFIED", no matter what they actually said...
        return "HTTP/1.1 200 OK\n\nVERIFIED";
    }
}

// Here, we trick Magento into thinking PayPal actually sent something back.
// Magento will try to verify it against PayPal's API though, and since it's fake data, it'll always fail.
$ipnPayload = array (
  'invoice'        => '100058137',         // Order ID to test against
  'txn_id'         => '04S87540L2309371A', // Test PayPal transaction ID
  'payment_status' => 'Failed'             // New payment status that Magento should ingest
);

// This is what Magento's controller calls during a normal IPN request.
// Instead of letting Magento talk to PayPal, we "inject" our fake HTTP client, which always returns VERIFIED.
Mage::getModel('paypal/ipn')->processIpnRequest($ipnPayload, new MockHttpClient());

Tôi chắc chắn rằng mẫu DI có nhiều lợi thế khác, nhưng khả năng kiểm tra tăng lên là lợi ích lớn nhất trong tâm trí tôi .

Nếu bạn tò mò về giải pháp cho vấn đề này, hãy xem repo GitHub tại đây: https://github.com/bubbleupdev/BUCorefix_Paypalstatus

Tại sao (vấn đề thậm chí là gì)?

Tại sao tôi nên sử dụng tiêm phụ thuộc?

Cách ghi nhớ tốt nhất tôi tìm thấy cho điều này là " mới là keo ": Mỗi khi bạn sử dụng newmã của mình, mã đó được gắn với triển khai cụ thể đó . Nếu bạn liên tục sử dụng mới trong các hàm tạo, bạn sẽ tạo ra một chuỗi các triển khai cụ thể . Và bởi vì bạn không thể "có" một thể hiện của một lớp mà không xây dựng nó, bạn không thể tách chuỗi đó.

Ví dụ, hãy tưởng tượng bạn đang viết một trò chơi video về xe đua. Bạn đã bắt đầu với một lớp Game, tạo một RaceTrack, tạo 8 Cars, mỗi lớp tạo một Motor. Bây giờ nếu bạn muốn thêm 4 Carsvới gia tốc khác nhau, bạn sẽ phải thay đổi mọi lớp được đề cập , ngoại trừ có thể Game.

Mã sạch hơn

Đây có phải chỉ dành cho kiến ​​trúc / mã sạch hơn

Có .

Tuy nhiên, nó có vẻ rất rõ ràng trong tình huống này, bởi vì đó là một ví dụ về cách thực hiện nó . Lợi thế thực tế chỉ thể hiện khi một số lớp có liên quan và khó chứng minh hơn, nhưng hãy tưởng tượng bạn sẽ sử dụng DI trong ví dụ trước. Mã tạo ra tất cả những thứ đó có thể trông giống như thế này:

List<Car> cars = new List<Car>();
for(int i=0; i<8; i++){
    float acceleration = 0.3f;
    float maxSpeed = 200.0f;
    Motor motor = new Motor(acceleration, maxSpeed);
    Car car = new Car(motor);
    cars.Add(car);
}
RaceTrack raceTrack = new RaceTrack(cars);
Game game = new Game(raceTrack);

Thêm 4 chiếc xe khác nhau bây giờ có thể được thực hiện bằng cách thêm các dòng sau:

for(int i=0; i<4; i++){
    float acceleration = 0.5f;
    float maxSpeed = 100.0f;
    Motor motor = new Motor(acceleration, maxSpeed);
    Car car = new Car(motor);
    cars.Add(car);
}

• Không có thay đổi trong RaceTrack, Game, Car, hoặc Motorlà cần thiết - có nghĩa là chúng ta có thể chắc chắn 100% rằng chúng tôi không giới thiệu bất kỳ lỗi mới đó!
• Thay vì phải nhảy giữa một số tệp, bạn sẽ có thể thấy sự thay đổi hoàn toàn trên màn hình của mình cùng một lúc. Đây là kết quả của việc xem sáng tạo / thiết lập / cấu hình là trách nhiệm của riêng mình - đó không phải là công việc của một chiếc xe hơi để chế tạo một động cơ.

Cân nhắc hiệu suất

hoặc điều này ảnh hưởng đến hiệu suất nói chung?

Không . Nhưng để hoàn toàn trung thực với bạn, nó có thể.

Tuy nhiên, ngay cả trong trường hợp đó, đó là một số tiền nhỏ đến mức nực cười mà bạn không cần phải quan tâm. Nếu tại một thời điểm nào đó trong tương lai, bạn phải viết mã cho một tamagotchi với tương đương CPU 5Mhz và RAM 2 MB, thì có lẽ bạn có thể phải quan tâm đến điều này.

Trong 99,999% * các trường hợp, nó sẽ có hiệu suất tốt hơn, vì bạn đã dành ít thời gian hơn để sửa lỗi và có nhiều thời gian hơn để cải thiện các thuật toán nặng tài nguyên của bạn.

* hoàn toàn tạo thành số

Đã thêm thông tin: "mã hóa cứng"

Đừng nhầm lẫn, đây vẫn là rất nhiều "mã hóa cứng" - các số được viết trực tiếp trong mã. Không được mã hóa cứng có nghĩa là một cái gì đó như lưu trữ các giá trị đó trong tệp văn bản - ví dụ: ở định dạng JSON - và sau đó đọc chúng từ tệp đó.

Để làm điều đó, bạn phải thêm mã để đọc một tệp và sau đó phân tích cú pháp JSON. Nếu bạn xem xét ví dụ một lần nữa; trong phiên bản không phải DI, giờ đây Carhoặc Motorphải đọc tệp. Điều đó không có vẻ như nó quá nhiều ý nghĩa.

Trong phiên bản DI, bạn sẽ thêm nó vào mã thiết lập trò chơi.

Tôi luôn luôn bị cản trở bởi tiêm phụ thuộc. Nó dường như chỉ tồn tại trong các quả cầu Java, nhưng những quả cầu đó đã nói về nó với sự tôn kính lớn. Đó là một trong những Mẫu tuyệt vời, bạn thấy, được cho là mang lại trật tự cho sự hỗn loạn. Nhưng các ví dụ luôn luôn phức tạp và giả tạo, thiết lập một vấn đề và sau đó đặt ra để giải quyết nó bằng cách làm cho mã phức tạp hơn.

Nó có ý nghĩa hơn khi một đồng nghiệp Python phát triển cho tôi sự khôn ngoan này: nó chỉ truyền các đối số cho các hàm. Nó hầu như không phải là một mô hình; giống như một lời nhắc nhở rằng bạn có thể yêu cầu một điều gì đó như là một đối số, ngay cả khi bạn có thể tự mình cung cấp một giá trị hợp lý.

Vì vậy, câu hỏi của bạn gần tương đương với "tại sao chức năng của tôi nên lấy đối số?" và có nhiều câu trả lời giống nhau, cụ thể là: để người gọi đưa ra quyết định .

Tất nhiên, điều này đi kèm với một chi phí, bởi vì bây giờ bạn buộc người gọi phải đưa ra một số quyết định (trừ khi bạn đưa ra đối số tùy chọn) và giao diện có phần phức tạp hơn. Đổi lại, bạn có được sự linh hoạt.

Vì vậy: Có lý do chính đáng nào bạn cần sử dụng Settingloại / giá trị cụ thể này không? Có một lý do chính đáng để gọi mã có thể muốn một Settingloại / giá trị khác nhau ? (Hãy nhớ rằng, các bài kiểm tra là mã !)

Ví dụ bạn đưa ra không phải là tiêm phụ thuộc theo nghĩa cổ điển. Việc tiêm phụ thuộc thường đề cập đến việc truyền các đối tượng trong một hàm tạo hoặc bằng cách sử dụng "setter tiêm" ngay sau khi đối tượng được tạo, để đặt giá trị trên một trường trong một đối tượng mới được tạo.

Ví dụ của bạn chuyển một đối tượng làm đối số cho một phương thức thể hiện. Phương thức cá thể này sau đó sửa đổi một trường trên đối tượng đó. Phụ thuộc tiêm? Không phá vỡ đóng gói và ẩn dữ liệu? Chắc chắn rồi!

Bây giờ, nếu mã là như thế này:

class Profile {
    private $settings;

    public function __construct(Settings $settings) {
        $this->settings = $settings;
    }

    public function deactive() {
        $this->settings->isActive = false;
    }
}

Sau đó tôi sẽ nói bạn đang sử dụng tiêm phụ thuộc. Sự khác biệt đáng chú ý là một Settingsđối tượng được truyền vào hàm tạo hoặc Profileđối tượng.

Điều này hữu ích nếu đối tượng Cài đặt tốn kém hoặc phức tạp để xây dựng hoặc Cài đặt là giao diện hoặc lớp trừu tượng nơi có nhiều triển khai cụ thể tồn tại để thay đổi hành vi thời gian chạy.

Vì bạn đang truy cập trực tiếp vào một trường trên đối tượng Cài đặt thay vì gọi một phương thức, bạn không thể tận dụng Đa hình, đây là một trong những lợi ích của việc tiêm phụ thuộc.

Có vẻ như Cài đặt cho Cấu hình dành riêng cho cấu hình đó. Trong trường hợp này tôi sẽ làm một trong những điều sau đây:

1. Khởi tạo đối tượng Cài đặt bên trong hàm tạo Cấu hình

2. Truyền đối tượng Cài đặt trong hàm tạo và sao chép qua các trường riêng lẻ áp dụng cho Cấu hình

Thành thật mà nói, bằng cách chuyển đối tượng Cài đặt vào deactivateProfilevà sau đó sửa đổi trường bên trong của đối tượng Cài đặt là mùi mã. Đối tượng Cài đặt phải là người duy nhất sửa đổi các trường bên trong của nó.

Tôi biết tôi sẽ đến bữa tiệc muộn nhưng tôi cảm thấy một điểm quan trọng đang bị bỏ lỡ.

Tại sao tôi nên làm điều này:

class Profile {
    public function deactivateProfile(Setting $setting)
    {
        $setting->isActive = false;
    }
}

Bạn không nên. Nhưng không phải vì Dependency Injection là một ý tưởng tồi. Đó là bởi vì điều này đang làm sai.

Hãy nhìn vào những thứ này bằng cách sử dụng mã. Chúng tôi sẽ làm điều này:

$profile = new Profile();
$profile->deactivateProfile($setting);

khi chúng ta nhận được điều tương tự từ điều này:

$setting->isActive = false; // Deactivate profile

Vì vậy, tất nhiên nó có vẻ như một sự lãng phí thời gian. Đó là khi bạn làm theo cách này. Đây không phải là cách sử dụng tốt nhất của Dependency Injection. Nó thậm chí không phải là cách sử dụng tốt nhất của một lớp.

Bây giờ nếu như thay vào đó chúng ta đã có điều này:

$profile = new Profile($setting);

$application = new Application($profile);

$application.start();

Và bây giờ, applicationcó thể tự do kích hoạt và hủy kích hoạt profilemà không cần phải biết bất cứ điều gì cụ thể về việc settingnó thực sự thay đổi. Tại sao cái đó lại tốt? Trong trường hợp bạn cần thay đổi cài đặt. Điều applicationnày được ngăn chặn từ những thay đổi đó để bạn có thể thoải mái đi vào một không gian an toàn mà không phải xem mọi thứ bị hỏng ngay khi bạn chạm vào thứ gì đó.

Điều này tuân theo việc xây dựng riêng biệt từ nguyên tắc hành vi . Mẫu DI ở đây là một mẫu đơn giản. Xây dựng mọi thứ bạn cần ở mức thấp nhất có thể, nối chúng lại với nhau, sau đó bắt đầu tất cả các hành vi tích tắc bằng một cuộc gọi.

Kết quả là bạn có một nơi riêng biệt để quyết định kết nối với cái gì và một nơi khác để quản lý những gì nói với cái gì.

Hãy thử điều đó trên một cái gì đó bạn phải duy trì theo thời gian và xem nếu nó không giúp đỡ.

Là một khách hàng, khi bạn thuê một thợ máy để làm một cái gì đó cho chiếc xe của bạn, bạn có mong đợi rằng người thợ đó sẽ chế tạo một chiếc xe từ đầu chỉ để làm việc với nó không? Không, bạn cung cấp cho thợ máy chiếc xe bạn muốn họ làm việc .

Là chủ sở hữu nhà để xe, khi bạn hướng dẫn một thợ máy làm một cái gì đó cho một chiếc xe hơi, bạn có mong đợi các thợ máy tạo ra tuốc nơ vít / cờ lê / phụ tùng xe hơi của riêng mình? Không, bạn cung cấp cho thợ máy các bộ phận / công cụ anh ta cần sử dụng

Tại sao chúng ta làm việc này? Vâng, hãy nghĩ về nó. Bạn là chủ nhà xe muốn thuê ai đó trở thành thợ cơ khí của bạn. Bạn sẽ dạy họ trở thành một thợ cơ khí (= bạn sẽ viết mã).

Điều gì sẽ dễ dàng hơn:

• Dạy một thợ máy làm thế nào để gắn một cánh lướt gió vào xe bằng tuốc nơ vít.
• Dạy một thợ máy tạo ra một chiếc xe hơi, tạo ra một spoiler, tạo ra một tuốc nơ vít và sau đó gắn spoiler mới được tạo ra cho chiếc xe mới được tạo ra với tuốc nơ vít mới được tạo ra.

Có những lợi ích to lớn khi không có thợ máy của bạn tạo ra mọi thứ từ đầu:

• Rõ ràng, đào tạo (= phát triển) được rút ngắn đáng kể nếu bạn chỉ cung cấp cho thợ máy của mình các công cụ và bộ phận hiện có.
• Nếu cùng một thợ máy phải thực hiện cùng một công việc nhiều lần, bạn có thể chắc chắn rằng anh ta sử dụng lại tuốc nơ vít thay vì luôn vứt cái cũ ra và tạo ra một công việc mới.
• Ngoài ra, một thợ máy đã học cách tạo ra mọi thứ sẽ cần nhiều hơn một chuyên gia, và do đó sẽ mong đợi một mức lương cao hơn. Điểm tương đồng về mã hóa ở đây là một lớp có nhiều trách nhiệm khó bảo trì hơn nhiều so với một lớp có một trách nhiệm được xác định nghiêm ngặt.
• Ngoài ra, khi các phát minh mới được tung ra thị trường và các chiến lợi phẩm hiện đang được chế tạo từ carbon thay vì nhựa; bạn sẽ phải đào tạo lại (= tái phát triển) thợ máy chuyên gia của bạn. Nhưng thợ máy "đơn giản" của bạn sẽ không phải đào tạo lại miễn là spoiler vẫn có thể được gắn theo cùng một cách.
• Có một thợ máy không dựa vào chiếc xe mà họ tự chế tạo có nghĩa là bạn có một thợ máy có thể điều khiển bất kỳ chiếc xe nào họ có thể nhận. Bao gồm cả những chiếc xe thậm chí còn chưa tồn tại vào thời điểm đào tạo thợ máy. Tuy nhiên, thợ máy chuyên gia của bạn sẽ không thể chế tạo những chiếc xe mới hơn đã được tạo ra sau khi đào tạo.

Nếu bạn thuê và đào tạo thợ cơ khí chuyên nghiệp, bạn sẽ kết thúc với một nhân viên tốn nhiều tiền hơn, mất nhiều thời gian hơn để thực hiện công việc đơn giản và sẽ cần phải được đào tạo lại bất cứ khi nào một trong số nhiều trách nhiệm của họ cần để được cập nhật.

Điểm tương đồng về phát triển là nếu bạn sử dụng các lớp có phần phụ thuộc được mã hóa cứng, thì bạn sẽ khó có thể duy trì các lớp sẽ cần tái phát triển / thay đổi liên tục bất cứ khi nào một phiên bản mới của đối tượng ( Settingstrong trường hợp của bạn) được tạo ra, và bạn 'sẽ phải phát triển logic bên trong cho lớp để có khả năng tạo các loại Settingsđối tượng khác nhau .

Hơn nữa, bất cứ ai tiêu thụ lớp của bạn bây giờ cũng sẽ phải yêu cầu lớp tạo Settingsđối tượng chính xác , trái ngược với việc đơn giản là có thể vượt qua lớp bất kỳ Settingsđối tượng nào mà nó muốn vượt qua. Điều này có nghĩa là sự phát triển bổ sung cho người tiêu dùng để tìm ra cách yêu cầu lớp tạo ra công cụ phù hợp.

Có, đảo ngược phụ thuộc phải mất một chút nỗ lực để viết thay vì mã hóa phụ thuộc. Vâng, thật khó chịu khi phải gõ nhiều hơn.

Nhưng đó là lý lẽ tương tự như việc chọn mã hóa các giá trị bằng chữ bởi vì "khai báo biến mất nhiều nỗ lực hơn". Về mặt kỹ thuật chính xác, nhưng sự chuyên nghiệp vượt trội hơn nhiều so với nhược điểm .

Lợi ích của việc đảo ngược phụ thuộc không có kinh nghiệm khi bạn tạo phiên bản đầu tiên của ứng dụng. Lợi ích của việc đảo ngược phụ thuộc được trải nghiệm khi bạn cần thay đổi hoặc mở rộng phiên bản ban đầu đó. Và đừng tự lừa mình rằng bạn sẽ hiểu đúng ngay từ lần đầu tiên và sẽ không cần gia hạn / thay đổi mã. Bạn sẽ phải thay đổi mọi thứ.

điều này có ảnh hưởng đến hiệu suất nói chung không?

Điều này không ảnh hưởng đến hiệu suất thời gian chạy của ứng dụng. Nhưng nó ồ ạt tác động đến thời gian phát triển (và do đó là hiệu suất) của nhà phát triển .

Giống như tất cả các mẫu, rất hợp lệ để hỏi "tại sao" để tránh các thiết kế cồng kềnh.

Đối với tiêm phụ thuộc, điều này có thể dễ dàng nhận thấy bằng cách nghĩ về hai khía cạnh quan trọng nhất của thiết kế OOP ...

Khớp nối thấp

Khớp nối trong lập trình máy tính :

Trong công nghệ phần mềm, khớp nối là mức độ phụ thuộc lẫn nhau giữa các mô-đun phần mềm; một thước đo về mức độ kết nối chặt chẽ giữa hai thói quen hoặc mô-đun; sức mạnh của các mối quan hệ giữa các mô-đun.

Bạn muốn đạt được khớp nối thấp . Hai thứ được kết hợp mạnh mẽ có nghĩa là nếu bạn thay đổi một thứ, bạn rất có thể phải thay đổi thứ khác. Lỗi hoặc hạn chế trong một khả năng sẽ gây ra lỗi / hạn chế ở bên kia; vân vân

Một đối tượng khởi tạo lớp của các đối tượng khác là một khớp nối rất mạnh, bởi vì người này cần biết về sự tồn tại của lớp kia; nó cần biết làm thế nào để khởi tạo nó (đối số mà hàm tạo cần) và các đối số đó cần có sẵn khi gọi hàm tạo. Ngoài ra, tùy thuộc vào việc ngôn ngữ có cần giải cấu trúc rõ ràng (C ++) hay không, điều này sẽ giới thiệu thêm các biến chứng. Nếu bạn giới thiệu các lớp mới (nghĩa là a NextSettingshoặc bất cứ thứ gì), bạn phải quay lại lớp ban đầu và thêm nhiều cuộc gọi đến các hàm tạo của chúng.

Độ kết dính cao

Sự gắn kết :

Trong lập trình máy tính, sự gắn kết liên quan đến mức độ mà các yếu tố bên trong một mô-đun thuộc về nhau.

Đây là mặt khác của đồng tiền. Nếu bạn nhìn vào một đơn vị mã (một phương thức, một lớp, một gói, v.v.), bạn muốn có tất cả mã bên trong đơn vị đó để có càng ít trách nhiệm càng tốt.

Một ví dụ cơ bản cho điều này sẽ là mẫu MVC: bạn tách biệt rõ ràng mô hình miền khỏi chế độ xem (GUI) và một lớp điều khiển gắn kết chúng lại với nhau.

Điều này tránh sự phình to mã nơi bạn có được khối lớn làm nhiều việc khác nhau; nếu bạn muốn thay đổi một phần của nó, bạn cũng phải theo dõi tất cả các tính năng khác, cố gắng tránh các lỗi, v.v.; và bạn nhanh chóng lập trình cho mình vào một cái lỗ nơi rất khó thoát ra.

Với phép nội xạ phụ thuộc, bạn ủy quyền việc tạo hoặc theo dõi, phụ thuộc vào bất kỳ lớp nào (hoặc tệp cấu hình) nào thực hiện DI của bạn. Các lớp khác sẽ không quan tâm nhiều đến chính xác những gì đang diễn ra - họ sẽ làm việc với một số giao diện chung và không biết triển khai thực tế là gì, điều đó có nghĩa là họ không chịu trách nhiệm cho những thứ khác.

Bạn nên sử dụng các kỹ thuật để giải quyết vấn đề mà họ giỏi trong việc giải quyết khi bạn gặp phải những vấn đề đó. Phụ thuộc đảo ngược và tiêm không khác nhau.

Nghịch đảo phụ thuộc hoặc tiêm là một kỹ thuật cho phép mã của bạn quyết định việc triển khai phương thức nào được gọi trong thời gian chạy. Điều này tối đa hóa lợi ích của ràng buộc muộn. Kỹ thuật này là cần thiết khi ngôn ngữ không hỗ trợ thay thế thời gian chạy của các chức năng phi thể hiện. Ví dụ, Java thiếu một cơ chế để thay thế các cuộc gọi đến một phương thức tĩnh bằng các cuộc gọi đến một triển khai khác; tương phản với Python, trong đó tất cả những gì cần thiết để thay thế lời gọi hàm là liên kết tên với một hàm khác (gán lại biến giữ chức năng).

Tại sao chúng ta muốn thay đổi việc thực hiện chức năng? Có hai lý do chính:

• Chúng tôi muốn sử dụng hàng giả cho mục đích thử nghiệm. Điều này cho phép chúng tôi kiểm tra một lớp phụ thuộc vào tìm nạp cơ sở dữ liệu mà không thực sự kết nối với cơ sở dữ liệu.
• Chúng tôi cần hỗ trợ nhiều triển khai. Ví dụ: chúng ta có thể cần thiết lập một hệ thống hỗ trợ cả cơ sở dữ liệu MySQL và PostgreQuery.

Bạn cũng có thể muốn lưu ý đảo ngược các container điều khiển. Đây là một kỹ thuật nhằm giúp bạn tránh những cây xây dựng khổng lồ, rối rắm trông giống như mã giả này:

thing5 =  new MyThing5();
thing3 = new MyThing3(thing5, new MyThing10());

myApp = new MyApp(
    new MyAppDependency1(thing5, thing3),
    new MyAppDependency2(
        new Thing1(),
        new Thing2(new Thing3(thing5, new Thing4(thing5)))
    ),
    ...
    new MyAppDependency15(thing5)
);

Nó cho phép bạn đăng ký các lớp học và sau đó thực hiện việc xây dựng cho bạn:

injector.register(Thing1); // Yes, you'd need some kind of actual class reference.
injector.register(Thing2);
...
injector.register(MyAppDepdency15);
injector.register(MyApp);

myApp = injector.create(MyApp); // The injector fills in all the construction parameters.

Lưu ý rằng nó đơn giản nhất nếu các lớp được đăng ký có thể là các singletons không trạng thái .

Lời cảnh báo

Lưu ý rằng đảo ngược phụ thuộc không nên là câu trả lời của bạn cho logic tách rời. Tìm kiếm cơ hội để sử dụng tham số hóa thay thế. Hãy xem xét phương pháp mã giả này chẳng hạn:

myAverageAboveMin()
{
    dbConn = new DbConnection("my connection string");
    dbQuery = dbConn.makeQuery();
    dbQuery.Command = "SELECT * FROM MY_DATA WHERE x > :min";
    dbQuery.setParam("min", 5);
    dbQuery.Execute();
    myData = dbQuery.getAll();
    count = 0;
    total = 0;
    foreach (row in myData)
    {
        count++;
        total += row.x;
    }

    return total / count;
}

Chúng ta có thể sử dụng nghịch đảo phụ thuộc cho một số phần của phương pháp này:

class MyQuerier
{
    private _dbConn;

    MyQueries(dbConn) { this._dbConn = dbConn; }

    fetchAboveMin(min)
    {
        dbQuery = this._dbConn.makeQuery();
        dbQuery.Command = "SELECT * FROM MY_DATA WHERE x > :min";
        dbQuery.setParam("min", min);
        dbQuery.Execute();
        return dbQuery.getAll();
    }
}


class Averager
{
    private _querier;

    Averager(querier) { this._querier = querier; }

    myAverageAboveMin(min)
    {
        myData = this._querier.fetchAboveMin(min);
        count = 0;
        total = 0;
        foreach (row in myData)
        {
            count++;
            total += row.x;
        }

        return total / count;
    }

Nhưng chúng ta không nên, ít nhất là không hoàn toàn. Lưu ý rằng chúng tôi đã tạo ra một lớp trạng thái với Querier. Bây giờ nó giữ một tham chiếu đến một số đối tượng kết nối toàn cầu về cơ bản. Điều này tạo ra các vấn đề như khó khăn trong việc hiểu trạng thái chung của chương trình và cách các lớp khác nhau phối hợp với nhau. Cũng lưu ý rằng chúng tôi buộc phải giả mạo bộ kiểm tra hoặc kết nối nếu chúng tôi muốn kiểm tra logic trung bình. Hơn nữa Một cách tiếp cận tốt hơn sẽ là tăng tham số hóa :

class MyQuerier
{
    fetchAboveMin(dbConn, min)
    {
        dbQuery = dbConn.makeQuery();
        dbQuery.Command = "SELECT * FROM MY_DATA WHERE x > :min";
        dbQuery.setParam("min", min);
        dbQuery.Execute();
        return dbQuery.getAll();
    }
}


class Averager
{
    averageData(myData)
    {
        count = 0;
        total = 0;
        foreach (row in myData)
        {
            count++;
            total += row.x;
        }

        return total / count;
    }

class StuffDoer
{
    private _querier;
    private _averager;

    StuffDoer(querier, averager)
    {
        this._querier = querier;
        this._averager = averager;
    }

    myAverageAboveMin(dbConn, min)
    {
        myData = this._querier.fetchAboveMin(dbConn, min);
        return this._averager.averageData(myData);
    }
}

Và kết nối sẽ được quản lý ở cấp độ cao hơn, chịu trách nhiệm cho toàn bộ hoạt động và biết phải làm gì với đầu ra này.

Bây giờ chúng ta có thể kiểm tra logic trung bình hoàn toàn độc lập với truy vấn và chúng ta có thể sử dụng nó nhiều hơn trong nhiều tình huống khác nhau. Chúng tôi có thể đặt câu hỏi liệu chúng tôi thậm chí có cần MyQueriervà Averagercác đối tượng hay không, và có thể câu trả lời là chúng tôi không nếu chúng tôi không có ý định kiểm tra đơn vị StuffDoer, và không kiểm tra đơn vị StuffDoersẽ hoàn toàn hợp lý vì nó được kết hợp chặt chẽ với cơ sở dữ liệu. Nó có thể có ý nghĩa hơn khi chỉ để cho các bài kiểm tra tích hợp bao gồm nó. Trong trường hợp đó, chúng ta có thể thực hiện tốt fetchAboveMinvà averageDatathành các phương thức tĩnh.