Tại sao IoC / DI không phổ biến trong Python?

Trong Java IoC / DI là một thực tiễn rất phổ biến được sử dụng rộng rãi trong các ứng dụng web, gần như tất cả các khung có sẵn và Java EE. Mặt khác, cũng có rất nhiều ứng dụng web Python lớn, nhưng bên cạnh Zope (mà tôi đã nghe thấy nên rất kinh khủng khi viết mã) IoC dường như không phổ biến trong thế giới Python. (Vui lòng kể tên một số ví dụ nếu bạn nghĩ rằng tôi sai).

Tất nhiên, có một số bản sao của các khung công tác Java IoC phổ biến có sẵn cho Python, springpython chẳng hạn. Nhưng không ai trong số họ dường như được sử dụng thực tế. Ít nhất, tôi chưa bao giờ vấp phải một ứng dụng web dựa trên Django hoặc sqlalchemy + <insert your favorite wsgi toolkit here>sử dụng cái gì đó tương tự.

Theo tôi, IoC có những lợi thế hợp lý và sẽ giúp dễ dàng thay thế mô hình người dùng mặc định django, nhưng việc sử dụng rộng rãi các lớp giao diện và IoC trong Python có vẻ hơi kỳ lạ và không »pythonic«. Nhưng có lẽ ai đó có một lời giải thích tốt hơn, tại sao IoC không được sử dụng rộng rãi trong Python.

Tôi không thực sự nghĩ rằng DI / IoC là rằng không phổ biến trong Python. Có gì là phổ biến, tuy nhiên, DI / IoC khuôn khổ / container .

Hãy nghĩ về nó: một container DI làm gì? Nó cho phép bạn

1. kết nối các thành phần độc lập với nhau thành một ứng dụng hoàn chỉnh ...
2. ... trong thời gian chạy.

Chúng tôi có tên cho "nối với nhau" và "trong thời gian chạy":

1. kịch bản
2. năng động

Vì vậy, một container DI không là gì ngoài trình thông dịch cho ngôn ngữ kịch bản động. Trên thực tế, hãy để tôi nói lại rằng: một thùng chứa Java / .NET DI điển hình không là gì ngoài một trình thông dịch nhảm nhí cho một ngôn ngữ kịch bản động thực sự xấu với cú pháp xấu xí, đôi khi dựa trên XML.

Khi bạn lập trình bằng Python, tại sao bạn muốn sử dụng một ngôn ngữ kịch bản xấu, xấu khi bạn có một ngôn ngữ kịch bản đẹp, tuyệt vời theo ý của bạn? Trên thực tế, đó là một câu hỏi chung chung hơn: khi bạn lập trình bằng bất kỳ ngôn ngữ nào, tại sao bạn lại muốn sử dụng một ngôn ngữ kịch bản xấu, xấu khi bạn có Jython và IronPython theo ý của bạn?

Vì vậy, để tóm tắt lại: việc thực hành DI / IoC cũng quan trọng trong Python như trong Java, vì những lý do chính xác như vậy. Việc thực hiện của DI / IoC tuy nhiên, được xây dựng vào ngôn ngữ và thường rất nhẹ rằng nó hoàn toàn biến mất.

. sắp xếp cho nó bằng cách nào đó quay trở lại chương trình con của bạn khi nó kết thúc, đặt các đối số ở đâu đó mà callee có thể tìm thấy chúng, v.v. Fortran có các cuộc gọi chương trình con được xây dựng, mọi người đang xây dựng "khung chương trình con" của riêng họ. Bạn có nói rằng các cuộc gọi chương trình con là "không phổ biến" trong Python, chỉ vì bạn không sử dụng khung chương trình con?)

BTW: cho một ví dụ về những gì có vẻ như để tận DI để kết luận hợp lý của nó, hãy nhìn vào Gilad Bracha 's Newspeak Lập trình Ngôn ngữ và tác phẩm của ông về đề tài này:

• Nhà xây dựng được coi là có hại
• Tiêm thuốc độc
• Một lệnh cấm nhập khẩu ( tiếp theo )

Một phần của nó là cách hệ thống mô-đun hoạt động trong Python. Bạn có thể nhận được một loại "singleton" miễn phí, chỉ bằng cách nhập nó từ một mô-đun. Xác định một thể hiện thực tế của một đối tượng trong một mô-đun, và sau đó bất kỳ mã máy khách nào cũng có thể nhập nó và thực sự có được một đối tượng hoạt động, được xây dựng / xây dựng đầy đủ.

Điều này trái ngược với Java, nơi bạn không nhập các thể hiện thực tế của các đối tượng. Điều này có nghĩa là bạn luôn phải tự khởi tạo chúng, (hoặc sử dụng một số cách tiếp cận kiểu IoC / DI). Bạn có thể giảm thiểu rắc rối khi phải tự khởi tạo mọi thứ bằng cách có các phương thức tĩnh của nhà máy (hoặc các lớp nhà máy thực tế), nhưng sau đó bạn vẫn phải chịu chi phí tài nguyên của việc thực sự tạo ra các phương thức mới mỗi lần.

IoC và DI là siêu phổ biến trong mã Python trưởng thành. Bạn không cần một khung để thực hiện DI nhờ gõ vịt.

Ví dụ tốt nhất là cách bạn thiết lập ứng dụng Django bằng cách sử dụng settings.py:

# settings.py
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': REDIS_URL + '/1',
    },
    'local': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'snowflake',
    }
}

Django Rest Framework sử dụng DI rất nhiều:

class FooView(APIView):
    # The "injected" dependencies:
    permission_classes = (IsAuthenticated, )
    throttle_classes = (ScopedRateThrottle, )
    parser_classes = (parsers.FormParser, parsers.JSONParser, parsers.MultiPartParser)
    renderer_classes = (renderers.JSONRenderer,)

    def get(self, request, *args, **kwargs):
        pass

    def post(self, request, *args, **kwargs):
        pass

Hãy để tôi nhắc ( nguồn ):

"Dependency Injection" là một thuật ngữ 25 đô la cho khái niệm 5 xu. [...] Tiêm phụ thuộc có nghĩa là đưa ra một đối tượng các biến đối tượng của nó. [...].

Django sử dụng tuyệt vời của đảo ngược kiểm soát. Ví dụ, máy chủ cơ sở dữ liệu được chọn bởi tệp cấu hình, sau đó khung cung cấp các phiên bản trình bao bọc cơ sở dữ liệu thích hợp cho các máy khách cơ sở dữ liệu.

Sự khác biệt là Python có các loại hạng nhất. Các kiểu dữ liệu, bao gồm các lớp, chính chúng là các đối tượng. Nếu bạn muốn một cái gì đó để sử dụng một lớp cụ thể, chỉ cần đặt tên cho lớp. Ví dụ:

if config_dbms_name == 'postgresql':
    import psycopg
    self.database_interface = psycopg
elif config_dbms_name == 'mysql':
    ...

Mã sau này có thể tạo giao diện cơ sở dữ liệu bằng cách viết:

my_db_connection = self.database_interface()
# Do stuff with database.

Thay vì các hàm nhà máy soạn sẵn mà Java và C ++ cần, Python thực hiện nó với một hoặc hai dòng mã thông thường. Đây là sức mạnh của lập trình chức năng so với mệnh lệnh.

Nó cho thấy rằng mọi người thực sự không nhận được những gì Phụ thuộc tiêm và đảo ngược kiểm soát có nghĩa là nữa.

Việc sử dụng nghịch đảo điều khiển là có các lớp hoặc hàm phụ thuộc vào các lớp hoặc hàm khác, nhưng thay vì tạo các thể hiện với lớp mã chức năng, tốt hơn là nhận nó như một tham số, do đó có thể lưu trữ khớp nối lỏng lẻo. Điều đó có nhiều lợi ích như khả năng kiểm tra nhiều hơn và để lưu trữ nguyên tắc thay thế liskov.

Bạn thấy, bằng cách làm việc với các giao diện và phép tiêm, mã của bạn sẽ dễ bảo trì hơn, vì bạn có thể thay đổi hành vi một cách dễ dàng, vì bạn sẽ không phải viết lại một dòng mã (có thể là một hoặc hai dòng trên cấu hình DI) của bạn lớp để thay đổi hành vi của nó, vì các lớp thực hiện giao diện mà lớp bạn đang chờ có thể thay đổi độc lập miễn là chúng tuân theo giao diện. Một trong những chiến lược tốt nhất để giữ cho mã tách rời và dễ bảo trì là tuân theo ít nhất các nguyên tắc đảo ngược, thay thế và phụ thuộc duy nhất.

Thư viện DI có ích gì nếu bạn có thể tự khởi tạo một đối tượng trong một gói và nhập nó để tự tiêm? Câu trả lời được chọn là đúng, vì java không có các phần thủ tục (mã bên ngoài các lớp), tất cả đều đi vào cấu hình nhàm chán của xml, do đó cần một lớp để khởi tạo và tiêm các phụ thuộc vào thời trang tải lười biếng để bạn không thổi bay hiệu suất của bạn, trong khi trên python, bạn chỉ cần mã hóa các mũi tiêm trên các phần "thủ tục" (mã bên ngoài các lớp) trong mã của bạn

Không sử dụng Python trong vài năm, nhưng tôi sẽ nói rằng nó có liên quan nhiều hơn với nó là một ngôn ngữ được gõ động hơn bất kỳ thứ gì khác. Ví dụ đơn giản, trong Java, nếu tôi muốn kiểm tra một cái gì đó được viết theo tiêu chuẩn một cách phù hợp, tôi có thể sử dụng DI và chuyển vào bất kỳ PrintStream nào để chụp văn bản được viết và xác minh nó. Tuy nhiên, khi tôi làm việc trong Ruby, tôi có thể tự động thay thế phương thức 'đặt' trên STDOUT để xác minh, khiến DI hoàn toàn không có hình ảnh. Nếu lý do duy nhất tôi tạo ra một sự trừu tượng là để kiểm tra lớp đang sử dụng nó (nghĩ rằng hoạt động của hệ thống tệp hoặc đồng hồ trong Java) thì DI / IoC tạo ra sự phức tạp không cần thiết trong giải pháp.

Trên thực tế, khá dễ dàng để viết mã đủ sạch và gọn với DI (tôi tự hỏi, nó sẽ / ở lại pythonic , nhưng dù sao :)), ví dụ tôi thực sự quan tâm đến cách mã hóa này:

def polite(name_str):
    return "dear " + name_str

def rude(name_str):
    return name_str + ", you, moron"

def greet(name_str, call=polite):
    print "Hello, " + call(name_str) + "!"

_

>>greet("Peter")
Hello, dear Peter!
>>greet("Jack", rude)
Hello, Jack, you, moron!

Vâng, điều này có thể được xem như chỉ là một hình thức đơn giản của các hàm / lớp tham số hóa, nhưng nó thực hiện công việc của nó. Vì vậy, có lẽ pin bao gồm mặc định của Python cũng đủ ở đây.

PS Tôi cũng đã đăng một ví dụ lớn hơn về cách tiếp cận ngây thơ này tại Đánh giá động về logic boolean đơn giản trong Python .

IoC / DI là một khái niệm thiết kế, nhưng thật không may, nó thường được coi là một khái niệm áp dụng cho các ngôn ngữ nhất định (hoặc hệ thống gõ). Tôi muốn thấy các thùng chứa phụ thuộc trở nên phổ biến hơn nhiều trong Python. Có Spring, nhưng đó là một siêu khung và dường như là một cổng trực tiếp của các khái niệm Java mà không cần quan tâm nhiều đến "The Python Way".

Đưa ra chú thích trong Python 3, tôi quyết định có một vết nứt tại một thùng chứa tiêm phụ thuộc đầy đủ tính năng, nhưng đơn giản: https://github.com/zsims/dic . Nó dựa trên một số khái niệm từ một thùng chứa phụ thuộc .NET (IMO thật tuyệt vời nếu bạn từng chơi trong không gian đó), nhưng bị biến đổi với các khái niệm Python.

Tôi nghĩ do tính chất năng động của con trăn, người ta thường không thấy sự cần thiết phải có một khung năng động khác. Khi một lớp kế thừa từ 'đối tượng' kiểu mới, bạn có thể tự động tạo một biến mới ( https://wiki.python.org/moin/NewClassVsClassicClass ).

tức là trong trăn đồng bằng:

#application.py
class Application(object):
    def __init__(self):
        pass

#main.py
Application.postgres_connection = PostgresConnection()

#other.py
postgres_connection = Application.postgres_connection
db_data = postgres_connection.fetchone()

Tuy nhiên, hãy xem https://github.com/noodleflower/pyioc đây có thể là những gì bạn đang tìm kiếm.

tức là trong pyioc

from libs.service_locator import ServiceLocator

#main.py
ServiceLocator.register(PostgresConnection)

#other.py
postgres_connection = ServiceLocator.resolve(PostgresConnection)
db_data = postgres_connection.fetchone()

Tôi trả lời "Jorg W Mittag": "Việc triển khai DI / IoC của Python rất nhẹ đến nỗi nó hoàn toàn biến mất".

Để sao lưu tuyên bố này, hãy xem ví dụ nổi tiếng của Martin Fowler được chuyển từ Java sang Python: Python: Design_Potypes: Inversion_of_Control

Như bạn có thể thấy từ liên kết trên, một "Container" trong Python có thể được viết bằng 8 dòng mã:

class Container:
    def __init__(self, system_data):
        for component_name, component_class, component_args in system_data:
            if type(component_class) == types.ClassType:
                args = [self.__dict__[arg] for arg in component_args]
                self.__dict__[component_name] = component_class(*args)
            else:
                self.__dict__[component_name] = component_class

2cents của tôi là trong hầu hết các ứng dụng Python bạn không cần nó và thậm chí nếu bạn cần nó, rất có thể nhiều người ghét Java (và những người chơi trò chơi không đủ năng lực tin rằng họ là nhà phát triển) coi nó là một thứ gì đó tồi tệ, chỉ vì nó phổ biến trong Java .

Một hệ thống IoC thực sự hữu ích khi bạn có các mạng đối tượng phức tạp, trong đó mỗi đối tượng có thể là một phụ thuộc cho một số người khác và đến lượt mình, chính nó lại phụ thuộc vào các đối tượng khác. Trong trường hợp như vậy, bạn sẽ muốn xác định tất cả các đối tượng này một lần và có cơ chế tự động đặt chúng lại với nhau, dựa trên càng nhiều quy tắc ngầm càng tốt. Nếu người dùng / quản trị viên ứng dụng xác định cấu hình theo cách đơn giản, đó là một lý do bổ sung để mong muốn một hệ thống IoC có thể đọc các thành phần của nó từ một cái gì đó giống như một tệp XML đơn giản (sẽ là cấu hình).

Ứng dụng Python điển hình đơn giản hơn nhiều, chỉ là một loạt các tập lệnh, không có kiến ​​trúc phức tạp như vậy. Cá nhân tôi nhận thức được IoC thực sự là gì (trái với những người đã viết câu trả lời nhất định ở đây) và tôi chưa bao giờ cảm thấy cần nó trong trải nghiệm Python hạn chế của mình (tôi cũng không sử dụng Spring ở mọi nơi, không phải khi có lợi thế nó không cho phép chứng minh chi phí phát triển của nó).

Điều đó nói rằng, có những tình huống Python trong đó cách tiếp cận IoC thực sự hữu ích và trên thực tế, tôi đã đọc ở đây rằng Django sử dụng nó.

Lý do tương tự ở trên có thể được áp dụng cho Lập trình hướng theo khía cạnh trong thế giới Java, với sự khác biệt là số trường hợp AOP thực sự đáng giá thậm chí còn hạn chế hơn.

đồ đạc pytest tất cả dựa trên DI ( nguồn )

Tôi đồng ý với @Jorg ở điểm DI / IoC là có thể, dễ dàng hơn và thậm chí còn đẹp hơn trong Python. Điều còn thiếu là các khung hỗ trợ nó, nhưng có một vài ngoại lệ. Để chỉ ra một vài ví dụ xuất hiện trong đầu tôi:

• Nhận xét Django cho phép bạn kết nối lớp Nhận xét của riêng bạn với logic và biểu mẫu tùy chỉnh của bạn. [Thêm thông tin]

• Django cho phép bạn sử dụng một đối tượng Hồ sơ tùy chỉnh để đính kèm vào mô hình Người dùng của bạn. Đây không phải là hoàn toàn IoC nhưng là một cách tiếp cận tốt. Cá nhân tôi muốn thay thế mô hình Người dùng lỗ như khung nhận xét. [Thêm thông tin]

Theo tôi, những thứ như tiêm phụ thuộc là triệu chứng của một khuôn khổ cứng nhắc và quá phức tạp. Khi phần chính của mã trở nên quá nặng để dễ dàng thay đổi, bạn thấy mình phải chọn các phần nhỏ của nó, xác định giao diện cho chúng và sau đó cho phép mọi người thay đổi hành vi thông qua các đối tượng cắm vào các giao diện đó. Đó là tất cả tốt và tốt, nhưng tốt hơn hết là tránh sự phức tạp đó ngay từ đầu.

Đó cũng là triệu chứng của một ngôn ngữ gõ tĩnh. Khi công cụ duy nhất bạn phải thể hiện sự trừu tượng là sự kế thừa, thì đó là những gì bạn sử dụng ở mọi nơi. Phải nói rằng, C ++ khá giống nhau nhưng không bao giờ thu hút được niềm đam mê với Nhà xây dựng và Giao diện ở mọi nơi mà các nhà phát triển Java đã làm. Thật dễ dàng để trở nên quá phấn khích với giấc mơ trở nên linh hoạt và có thể mở rộng với chi phí viết quá nhiều mã chung chung với rất ít lợi ích thực sự . Tôi nghĩ đó là một điều văn hóa.

Thông thường tôi nghĩ rằng người Python thường chọn công cụ phù hợp cho công việc, đó là một tổng thể mạch lạc và đơn giản, thay vì Công cụ One True (Với hàng ngàn plugin có thể làm được) nhưng cung cấp một loạt các hoán vị cấu hình có thể gây hoang mang . Vẫn có những phần có thể hoán đổi cho nhau khi cần thiết, nhưng không cần sự hình thức lớn trong việc xác định giao diện cố định, do tính linh hoạt của việc gõ vịt và sự đơn giản tương đối của ngôn ngữ.

Không giống như bản chất gõ mạnh trong Java. Hành vi gõ vịt của Python giúp dễ dàng vượt qua các đối tượng xung quanh.

Các nhà phát triển Java đang tập trung vào việc xây dựng cấu trúc lớp và mối quan hệ giữa các đối tượng, trong khi giữ cho mọi thứ linh hoạt. IoC là cực kỳ quan trọng để đạt được điều này.

Các nhà phát triển Python đang tập trung vào việc hoàn thành công việc. Họ chỉ nối dây các lớp khi họ cần. Họ thậm chí không phải lo lắng về loại lớp học. Miễn là nó có thể quẫy, đó là một con vịt! Bản chất này không có chỗ cho IoC.