Inversion of control là gì

     

1. Nguyên lý Inversion of Control là gì?

Trước lúc tới với định nghĩa Inversion of Control là gì? các bạn hãy cùng tôi làm vài cốc trà đá chém gió tí. Vào ghế đơn vị trường tất cả lẽ ai ai cũng sợ tuyệt nhất môn Triết học do mấy lý do, nặng nề hiểu (trìu tượng), nhiều định nghĩa cần học thuộc. Mặc dù vậy Triết học tập lại là khoa học của hầu hết khoa học bởi nó trìu tượng ở một tầng trên cao nhất. Phiên bản thân tôi cũng đã quên tất cả những gì học tập được (nói đúng ra là ở trong được) trong Triết học ngay sau khoản thời gian thi kết thúc môn này, thế nhưng sau một thời gian khá dài bộn bề lo toan với quá trình và cuộc sống, gần như khái niệm, quy luật thời xưa thuộc vào Triết học tự nhiên và thoải mái cứ lởn vởn trong đầu cùng rồi ngẫm lại, đúng thật! Điểm lại chút về 2 nguyên lý, 3 quy luật và 6 cặp phạm trù trong Triết học, hoàn toàn có thể trong phạm vi gọi biết của chính bản thân mình và rất nhiều trải nghiệm đến bây giờ nó đã làm nên tất cả mọi gì đang ra mắt xung xung quanh ta. Sở dĩ viết vài mẩu chuyện phiếm tại chỗ này hầu chuyện chúng ta vì những khái niệm mà bọn chúng ta luận bàn trong nội dung bài viết này tương đối là trìu tượng, nó tương tự như triết học tập là nguyên lý của những nguyên lý. Trong số những quy luật mà tôi hay chiêm nghiệm tuyệt nhất là quy khí cụ lượng chất:

Những biến hóa đơn thuần về lượng, mang đến một nấc độ tuyệt nhất định, đang chuyển trở thành những sự khác biệt về chất.

Bạn đang xem: Inversion of control là gì


Friedrich Engels

Bạn học một cái gì đó, hoặc làm một chiếc gì đó có thể không đọc ngay nhưng cho khi bao gồm một lượng kiến thức, kinh nghiệm nhất định, các bạn sẽ đột nhiên hiểu rõ nó. Do vậy, nếu những định nghĩa về Inversion of Control dưới đây quá trìu tượng, cạnh tranh hiểu các bạn cũng đừng quá quan lại tâm, mang lại một ngày như thế nào đó khi bạn lập trình đầy đủ 100 dự án, bao gồm 10 năm "giờ bay" vào lập trình... Thoải mái và tự nhiên sẽ hiểu. Chuyện phiếm vậy thôi, giờ bọn họ cùng vào phần thiết yếu của bài viết nhé. Định nghĩa nguyên lý Inversion of Control

Inversion of Control (IoC) là một nguyên lý thi công trong công nghệ phần mềm với những đoạn code khi đưa vào một trong những framework sẽ nhận thấy luồng điều khiển từ framework giỏi nói một bí quyết khác là được framework điều khiển. Kiến trúc phần mềm với xây cất này sẽ đảo ngược quyền tinh chỉnh so với xây dựng hướng giấy tờ thủ tục truyền thống. Trong lập trình truyền thống lâu đời các đoạn code chế tạo sẽ gọi những thư viện nhưng với IoC, framework đang gọi những mã thêm vào.

Martin Fowler

Nói thật, tôi cũng nỗ lực đưa ra định nghĩa này về ngữ điệu con người rất có thể hiểu được nhưng lại nó vẫn vượt trìu tượng hoặc vì tôi không đủ "giờ bay" phải cũng chỉ tạm dừng ở một định nghĩa như vậy. Tôi đã và đang thử mày mò các có mang khác trên Internet tuy thế cũng chỉ cảm nhận một câu: "Tốt nhất chúng ta nên quên nó đi". Lại nói về phong thái nhận thức một vấn đề, theo quan điểm phép duy thiết bị biện chứng, hoạt đụng nhận thức của con fan đi từ bỏ trực quan sinh động đến bốn duy trừu tượng, với từ bốn duy trừu tượng cho thực tiễn. Kết luận nếu họ đi vào cái định nghĩa chết tiệt này ngay chính vậy một sai lạc trong cách tìm hiểu về một vấn đề.

Chém gió thôi nhé, Triết học xa xưa mình thi lại mang lại lần lắp thêm 3 mới qua :).

2. Trực quan sinh động về IoC

Inversion of Control là một sự "thi phường" trong việc mở rộng một framework, một quánh tính trong các framework. Chúng ta cùng coi một ví dụ đơn giản về lịch trình nhập thông tin người dùng theo kiểu giấy tờ thủ tục truyền thống:

lúc chạy vận dụng này trong screen dòng lệnh, các dòng code của bọn họ đang gồm quyền kiểm soát, nó đưa ra quyết định được lúc nào đặt câu hỏi, lúc nào đọc dữ liệu người tiêu dùng nhập vào và lúc nào xử lý các công dụng này.

*

Tiếp tục, họ viết lại ứng dụng thực hiện framework Laravel ở dạng giao diện đồ họa. Sự khác biệt lớn tốt nhất giữa hai vận dụng này là luồng điều khiển và tinh chỉnh (flow of control). Trong chương trình dòng lệnh, bọn họ kiểm soát được lúc nào các cách làm được gọi, nhưng lại trong trong công tác dạng bối cảnh thì không. Framework sẽ kiểm soát việc đó bằng một vòng lặp thường xuyên kiểm tra coi có dữ liệu nào được nhập vào không? rất có thể bạn nhập nghề nghiệp và công việc trước lúc nhập tên. Như vậy, trong ứng dụng thứ nhì quyền điều khiển đã biết thành đảo ngược, quyền kiểm soát đã được về framework.

*

Đây là 1 ví dụ trực quan về nguyên tắc Inversion of Control, nguyên tắc này làm fan ta cửa hàng đến một nguyên lý khi thao tác trong Hollywood "Đừng hotline cho chúng tôi, cửa hàng chúng tôi sẽ call cho bạn". Các bạn đã gọi được IoC là gì? tuy nhiên tôi thì chưa, thật sự nó vẫn ...éo thể phát âm được. Tạm thời gác qua câu hỏi đó, bọn họ cần thêm "lượng" để mang đến với cách nhảy vọt về "chất" nghỉ ngơi cuối bài.

Một đặc điểm đặc biệt của framework là những phương thức được có mang bởi người tiêu dùng thông thường được điện thoại tư vấn từ trong bạn dạng thân framework chứ không hẳn từ code ứng dụng của người dùng. Framework đóng vai trò của chương trình chính trong vấn đề điều phối và sắp đến xếp hoạt động ứng dụng. Sự đảo ngược quyền kiểm soát điều hành này tạo nên cho framework mức độ mạnh thông qua việc mở rộng. Các phương thức được viết bởi người tiêu dùng định nghĩa các thuật toán vào framework mang đến một đo lường và tính toán cụ thể. Inversion of Control cho thấy sự biệt lập giữa một framework với một thư viện.

Một thư viện chỉ là tập hợp các tính năng mà chúng ta cũng có thể sử dụng, nó được tổ chứ thành những class. Sau các lần gọi một phương thức, thư viện vẫn làm một số việc và sau đó trả quyền tinh chỉnh về cho tất cả những người dùng.

Framework là một thể hiện của xây dựng trìu tượng với tương đối nhiều hành vi được kiến tạo sẵn bên trong, để thực hiện nó bạn cần chèn các hành vi của chúng ta vào các nơi không giống nhau trong framework bằng những class hoặc plugin. Code của framework sẽ gọi đến code của chúng ta tại những vấn đề cần thiết.

Có nhiều cách để bạn chuyển thêm mã vào framework, trong ví dụ như trên họ sử dụng một textbox, bất kỳ khi nào, textbox phát hiện tại sự kiện người tiêu dùng nhập liệu, nó sẽ gọi đến các code trong một "bao đóng". Một phương pháp khác để làm điều này là để framework định nghĩa những sự kiện cùng code bạn sẽ đăng ký vào những sự khiếu nại này. Trong Laravel, bạn cũng có thể phát sinh một sự kiện khi làm việc với một đoạn code của chính bản thân mình và framework gồm cơ chế kiểm soát điều hành các sự kiện đó, hay nói theo một cách khác bạn vẫn ủy quyền lại đến framework.

Các phương pháp tiếp cận là khôn xiết tốt, nhưng mà thỉnh thoảng bạn có nhu cầu kết hợp những lời gọi cách thức trong một đơn vị chức năng mở rộng, framework buộc phải định nghĩa một interface nhằm client code phải thực hiện nó cho những lời gọi cách làm liên quan. Đây đó là nguyên lý đóng mở trong nguyên lý SOLID cho kiến thiết hướng đối tượng.

Thực sự chúng ta nào đọc được đến đoạn này tôi bắt buộc rất cảm phục vì sự kiên nhẫn của bạn, nhưng lại một đợt nữa cặp phạm trù vì sao và hiệu quả rất xứng đáng để chúng ta phải cố gắng gắng. Nguyên nhân: bạn kiên trì tống vào đầu mớ kim chỉ nan trìu tượng này, kết quả: mang đến cuối bài xích bạn gọi được "Inversion of Control là gì?".

Trong mẫu trực quan gồm cái trực quan liêu hơn, vậy kiếm tìm cái đơn giản nhất để phát âm trước rồi hiểu cái phức tạp sau. Nếu như bạn đã tìm hiểu sơ lược về IoC trên mạng, các bạn sẽ thấy gồm cả một rừng những thuật ngữ liên quan như Dependency Inversion Principle (DIP), Dependency Injection Pattern (DI), IoC Container. Khá là rất khó để phân biệt các khái niệm này, chúng ta cần một khẩu quyết chứa đựng cả một tàng thư.

DI is about wiring, IoC is about direction, và DIP is about shape.

IoC là hướng đi và DIP là định hình rõ ràng của hướng đi còn DI là một thực hiện cụ thể.

Khẩu quyết này tạm bợ vẽ thành hình hình ảnh cho dễ dàng nhớ.

*

Đến phía trên chắc chúng ta đã đống ý với tôi: "Inversion of Control là nguyên lý của những nguyên lý".

Xem thêm: Eps Là File Eps Là Gì ? Phần Mềm & Cách Mở File

3. Inversion of Control được hình thành như vậy nào?

Đôi khi họ tự hỏi, các nguyên lý như IoC, SOLID... được hình thành như vậy nào? tại sao người ta rất có thể nghĩ ra chúng? trở về với lập trình phía đối tượng là một cách giải quyết các vấn đề theo bốn duy phía đối tượng. Phương pháp này tế bào phỏng y hệt như thế giới ko kể đời, vì vậy những nguyên lý thiết kế trong cuộc sống thường ngày thật trả toàn hoàn toàn có thể đưa vào trong lập trình. Tiếp theo đấy là một lấy một ví dụ tôi phát âm được từ cuốn Dependency Injection in .NET, một cuốn sách phân tích và lý giải khá hay về các khái niệm IoC, DI, DIP...

Trong nguyên lý ở đầu cuối Dependency Inversion của SOLID bọn họ có nói đến một lấy ví dụ như về một loại đèn bàn tất cả dây năng lượng điện được đấu nối trực tiếp vào ổ điện trong tường mà không qua ổ cắn và phích cắm, còn trong lấy ví dụ như này bọn họ thay nó bằng chiếc máy sấy tóc. Trường hợp này cho thấy vấn đề không nhỏ khi các đối tượng phụ thuộc chặt chẽ với nhau vào thiết kế.

*

Trong một đợt đi đơn vị nghỉ cùng bạn nữ (giả tưởng thôi nhé), tôi đang giật mình khi bắt gặp hình hình ảnh chiếc thiết bị sấy được nối trực tiếp vào vào ổ điện mà lại không trải qua ổ cắm và phích cắm. Mục đích thì sẽ rõ, mọi kẻ say mê táy máy đang “tắt điện” khi nhận thấy cảnh này. Tuy vậy chuyện gì sẽ xảy ra khi cái máy sấy này hỏng, dù nó tất cả là hàng Nhật xịn mà lại cũng có những lúc hỏng chứ.

*

Để thay thế sửa chữa là tương đối phức tạp, đầu tiên chúng ta phải ngắt át-tô-mát, sau đó mở cái tủ biến thế ra cùng thay chiếc máy sấy bắt đầu vào. Ông thợ làm sao không cảnh giác có thể không nhảy điện lên để chạy thử xem chiếc máy mới gắng có vận động không. Trong thiết kế cũng vậy, nếu các module phụ thuộc chặt chẽ vào nhau (thường sử dụng thuật ngữ tightly coupled) thì lúc một module bao gồm vấn đề, cả khối hệ thống sẽ rối tung, rất cực nhọc để duy trì và vạc triển.

*

Thông thường, chẳng ai chạy dây những thiết bị điện trực tiếp vào khối hệ thống điện, vậy vào đấy là sử dụng một phích gặm và ổ cắm. Một ổ cắm là một trong những interface với chuẩn cắm phải tương xứng với hình trạng phích cắm. Như vậy, thứ sấy tóc với ổ gặm và phích cắm đã hình thành một liên kết không dựa vào (loosely coupled). Có thể có rất nhiều cách phối hợp các thiết bị năng lượng điện này cùng với nhau để ra một hệ thống. Trong lập trình việc phối hợp này có thể so sánh cùng với design pattern cùng các nguyên tắc thiết kế.

Máy sấy tóc sẽ không còn ràng buộc với hệ thống điện, nếu bọn họ cần ổ điện mang đến laptop, đơn giản là rút máy sấy ra với cắm máy tính xách tay vào ổ cắm. Những nhà thi công ổ cắm không suy nghĩ thiết bị điện như laptop, điện thoại, tivi… nhưng những thiết bị này vẫn hoạt động tốt khi cắm vào. Những thiết bị khác nhau hoàn toàn có thể cắm vào ổ cắm mà không ảnh hưởng gì tựa như như nguyên lý thay cầm cố Liskov trong kiến thiết phần mềm. Trong Dependency Inject, nguyên lý Liskov là một trong những nguyên lý quan liêu trọng, nó có thể chấp nhận được đáp ứng đa số yêu cầu sau này thậm chí họ chưa biết được những gì về nó trong hôm nay. Cũng như trong thực tế, giả dụ 10 năm nữa bao gồm một sản phẩm công nghệ điện bắt đầu thì nó vẫn cắm vào chiếc ổ cắm này mà không bắt buộc phải biến hóa bên trong.

*

Khi pin máy vi tính đầy, bạn sẽ rút phích cắm của sản phẩm laptop ra và gửi sang dùng pin. Vào lập trình, chúng ta luôn ước muốn một service/module/class nào chính là đang tồn tại, giả dụ thành phần này đã được gỡ bỏ, chúng ta sẽ chạm mặt lỗi NullReferenceException, với trường hợp này bọn họ sẽ tạo nên một interface cơ mà nó không làm cho gì. Đây là 1 trong design pattern được biết đến với thương hiệu là Null Object, nó đáp ứng việc rút phích cắm thoát khỏi tường.

*

Mọi điều hoàn toàn có thể xảy ra, giả dụ như hệ thống điện của tất cả khu đang gặp mặt vấn đề, các bạn sẽ cần mang lại một cỗ lưu điện UPS nhằm vẫn hoạt động được thêm một thời gian. Máy máy tính xách tay và bộ lưu điện tất cả những trách nhiệm khác nhau, đây chính là nguyên lý đơn chức năng (single responsibility) trong kiến tạo phần mềm. Cả UPS và máy tính đều được cung cấp bởi những nhà đồ vật khác nhau, được thiết lập ở đều thời điểm khác nhau nhưng hoàn toàn có thể sử dụng kết hợp được cùng với nhau, thậm chí bạn cũng có thể cắm cả thứ sấy tóc khi máy tính xách tay không cắn vào bộ lưu điện.

*

Một thực tế là các nhu cầu luôn thay đổi, các hệ thống luôn mở rộng và yêu cầu thêm tính năng, vấn đề mở rộng đôi lúc chỉ là phương pháp lắp ghép các thành phần với nhau theo những cách khác nhau. Decorator pattern là chủng loại lập trình giúp thêm tính năng cho một class cơ mà không buộc phải viết lại hoặc biến hóa các code bao gồm sẵn. Một giải pháp khác để thêm tính năng được cải thiện vào một code bao gồm sẵn là tổng hợp các implement hiện tất cả cửa một interface áp dụng Composite pattern. Với việc sử dụng ổ cắn dài, chúng ta có thể thêm vào hoặc bớt đi những thiết bị điện cần chạy. Cùng với cùng giải pháp này Composite pattern thuận tiện thêm bớt tính năng bằng cách thay thay đổi tập những interface.

*

Đôi khi họ có một lắp thêm được cài ở nước ngoài với chuẩn đầu cắm khác với ổ cắm đang có, chúng ta cần một bộ chuyển đổi. Adapter pattern cũng thực hiện cùng một nhiệm vụ với những bộ đưa đổi. Chưa đến một ví dụ thực tiễn về hệ thống điện 1-1 giản, bọn họ đã thấy có không ít các ý tưởng phát minh đã được thực hiện ở trong thế giới hướng đối tượng người sử dụng trong lập trình.

4. Nguyên nhân dùng Inversion of Control

Chuyện phiếm, nói phét kèm theo bao nhiêu cốc trà đá rồi mà lại vẫn bắt buộc hiểu được đang nói tới cái gì? Hic...

Ngay bao gồm trong khái niệm Inversion of Control đang nói nên mục đích chính của nguyên lý này chính là tính không ngừng mở rộng của một hệ thống. Quay trở về với câu chuyện về vật dụng sấy tóc, các thiết kế ở không tính đời giúp cho việc mở rộng một khối hệ thống là quá đối kháng giản. Trong thiết kế cũng vậy, nhờ triển khai những định hình ví dụ từ những nguyên lý, một khối hệ thống ứng dụng sẽ có được tính mở rộng. Tuy nhiên để đã có được tính mở rộng cho một áp dụng thì trước tiên ứng dụng này cần vứt bỏ sự phụ thuộc giữa một đối tượng người sử dụng này cùng với một đối tượng khác.

Tính mở rộng rất có thể mở rộng ra không chỉ có thế ở góc độ duy trì và cải cách và phát triển ứng dụng. Một hệ thống được thiết kế theo phong cách đơn giản đã dễ không ngừng mở rộng hơn một hệ thống phức tạp. Hơn nữa các hệ thống áp dụng nguyên lý Inversion of Control sẽ tiện lợi trong kiểm thử ứng dụng do những thành phần có sự hòa bình nhất định.

5. Quán mang lại giờ đóng góp cửa, không còn trà đá!

"Em ơi! Anh thêm cốc nữa đê...", không một giờ đồng hồ đáp lại, miệng khô đắng, giọng gằn lên "Chủ quán...", mịa nó chứ vẫn vắng lặng như tờ, cúi cong người xuống định vớ đại bé Chaco 81 lỗ quăng vào... Úi vượt nửa tối roài, con mưa ảnh hưởng bão cũng đã tạnh, chỉ với chút gió vi vu... "Quán đến giờ đóng cửa, hết trà đá!" các giọng nói lanh lảnh chứa lên từ 1 khuôn khía cạnh bây bi con bà chủ quán.

Xem thêm: " Rat Race Là Gì ? Làm Thế Nào Thoát Khỏi Rat Race 2021? * Web Tài Chính

Mải chém gió, giờ bắt đầu nhớ ra, new được nửa đoạn đường từ trực quan đến tư duy trìu tượng. Cố kỉnh còn từ bốn duy trìu tượng mang đến thực tiễn, thôi hứa hẹn bữa không giống mạn đàm tiếp...