Nhược điểm của việc sử dụng Dependency Injection là gì? [đóng cửa]

Tôi đang cố gắng giới thiệu DI như một mô hình tại nơi làm việc và một trong những nhà phát triển chính của chúng tôi muốn biết: Điều gì - nếu có - là nhược điểm của việc sử dụng mô hình Dependency Injection?

Lưu ý Tôi đang tìm kiếm một danh sách đầy đủ - nếu có thể - không phải là một cuộc thảo luận chủ quan về chủ đề này.

Làm rõ : Tôi đang nói về mẫu Tiêm phụ thuộc (xem bài viết này của Martin Fowler), không phải là một khung cụ thể, cho dù dựa trên XML (như Spring) hay dựa trên mã (như Guice) hoặc "tự cuộn" .

Chỉnh sửa : Một số cuộc thảo luận / tán gẫu / tranh luận tuyệt vời đang diễn ra / r / lập trình ở đây.

Một vài điểm:

• DI tăng độ phức tạp, thường bằng cách tăng số lượng lớp vì các trách nhiệm được phân tách nhiều hơn, điều này không phải lúc nào cũng có lợi
• Mã của bạn sẽ được (phần nào) kết hợp với khung tiêm phụ thuộc mà bạn sử dụng (hoặc nói chung hơn là cách bạn quyết định triển khai mẫu DI)
• Các thùng chứa DI hoặc các phương pháp thực hiện giải quyết loại thường phải chịu một hình phạt thời gian chạy nhẹ (rất không đáng kể, nhưng nó ở đó)

Nói chung, lợi ích của việc tách rời làm cho mỗi tác vụ đơn giản hơn để đọc và hiểu, nhưng làm tăng sự phức tạp của việc sắp xếp các nhiệm vụ phức tạp hơn.

Vấn đề cơ bản tương tự bạn thường gặp phải với lập trình hướng đối tượng, quy tắc phong cách và mọi thứ khác. Trên thực tế, điều đó là có thể - rất phổ biến - thực hiện quá nhiều sự trừu tượng hóa và thêm quá nhiều sự gián tiếp, và nói chung là áp dụng các kỹ thuật tốt quá mức và ở những vị trí sai.

Mỗi mô hình hoặc cấu trúc khác mà bạn áp dụng đều mang lại sự phức tạp. Trừu tượng và phân tán thông tin phân tán xung quanh, đôi khi di chuyển chi tiết không liên quan ra khỏi đường đi, nhưng đôi khi cũng làm cho khó hiểu chính xác những gì đang xảy ra. Mỗi quy tắc bạn áp dụng đều mang lại sự không linh hoạt, loại trừ các tùy chọn có thể là phương pháp tốt nhất.

Vấn đề là viết mã thực hiện công việc và mạnh mẽ, dễ đọc và duy trì. Bạn là một nhà phát triển phần mềm - không phải là người xây dựng tháp ngà.

Liên kết có liên quan

http://thed Dailywtf.com/Articles/The_Inner-Plevelop_Effect.aspx

http://www.joelonsoftware.com/articles/fog0000000018.html

Có lẽ hình thức tiêm phụ thuộc đơn giản nhất (không cười) là một tham số. Mã phụ thuộc phụ thuộc vào dữ liệu và dữ liệu đó được đưa vào bằng phương tiện truyền tham số.

Vâng, thật ngớ ngẩn và nó không đề cập đến điểm tiêm phụ thuộc hướng đối tượng, nhưng một lập trình viên chức năng sẽ cho bạn biết rằng (nếu bạn có chức năng hạng nhất) thì đây là loại tiêm phụ thuộc duy nhất bạn cần. Vấn đề ở đây là lấy một ví dụ tầm thường, và chỉ ra những vấn đề tiềm ẩn.

Hãy thực hiện chức năng truyền thống đơn giản này - cú pháp C ++ không có ý nghĩa ở đây, nhưng tôi phải đánh vần nó bằng cách nào đó ...

void Say_Hello_World ()
{
  std::cout << "Hello World" << std::endl;
}

Tôi có một phụ thuộc mà tôi muốn trích xuất và tiêm - văn bản "Hello World". Vừa đủ dễ...

void Say_Something (const char *p_text)
{
  std::cout << p_text << std::endl;
}

Làm thế nào là không linh hoạt hơn so với bản gốc? Chà, nếu tôi quyết định rằng đầu ra sẽ là unicode. Tôi có lẽ muốn chuyển từ std :: cout sang std :: wcout. Nhưng điều đó có nghĩa là các chuỗi của tôi sau đó phải là của wchar_t, không phải của char. Mỗi người gọi phải được thay đổi, hoặc (hợp lý hơn), việc triển khai cũ được thay thế bằng một bộ chuyển đổi dịch chuỗi và gọi thực hiện mới.

Đó là công việc bảo trì ngay tại đó sẽ không cần thiết nếu chúng ta giữ nguyên bản gốc.

Và nếu nó có vẻ tầm thường, hãy xem chức năng trong thế giới thực này từ API Win32 ...

http://msdn.microsoft.com/en-us/l Library / ms632680% 28v = vs85% 29.aspx

Đó là 12 "sự phụ thuộc" để giải quyết. Ví dụ: nếu độ phân giải màn hình thực sự lớn, có thể chúng ta sẽ cần các giá trị phối hợp 64 bit - và một phiên bản khác của CreatWindowEx. Và đúng vậy, đã có một phiên bản cũ hơn vẫn còn tồn tại, có lẽ được ánh xạ tới phiên bản mới hơn đằng sau hậu trường ...

http://msdn.microsoft.com/en-us/l Library / ms632679% 28v = vs85% 29.aspx

Những "phụ thuộc" đó không chỉ là vấn đề đối với nhà phát triển ban đầu - mọi người sử dụng giao diện đó phải tìm kiếm các phụ thuộc là gì, chúng được chỉ định như thế nào và ý nghĩa của chúng và tìm ra cách làm cho ứng dụng của chúng. Đây là nơi mà các từ "mặc định hợp lý" có thể làm cho cuộc sống đơn giản hơn nhiều.

Nguyên tắc tiêm phụ thuộc hướng đối tượng là không khác nhau về nguyên tắc. Viết một lớp là một chi phí chung, cả về văn bản mã nguồn và thời gian của nhà phát triển và nếu lớp đó được viết để cung cấp các phụ thuộc theo một số đặc tả của đối tượng phụ thuộc, thì đối tượng phụ thuộc sẽ bị khóa để hỗ trợ giao diện đó, ngay cả khi có nhu cầu để thay thế việc thực hiện đối tượng đó.

Không ai trong số này nên được đọc là tuyên bố rằng tiêm phụ thuộc là xấu - xa nó. Nhưng bất kỳ kỹ thuật tốt có thể được áp dụng quá mức và sai chỗ. Giống như không phải mọi chuỗi cần được trích xuất và biến thành một tham số, không phải mọi hành vi cấp thấp đều cần được trích xuất từ ​​các đối tượng cấp cao và biến thành một phụ thuộc có thể tiêm được.

Đây là phản ứng ban đầu của riêng tôi: Về cơ bản các nhược điểm của bất kỳ mẫu nào.

• nó cần có thời gian để học
• Nếu hiểu lầm nó có thể dẫn đến nhiều tác hại hơn là tốt
• nếu được đưa đến một thái cực, nó có thể là công việc nhiều hơn là sẽ biện minh cho lợi ích

"Nhược điểm" lớn nhất đối với Inversion of Control (không hoàn toàn DI, nhưng đủ gần) là nó có xu hướng loại bỏ việc có một điểm duy nhất để xem xét tổng quan về thuật toán. Về cơ bản, điều đó xảy ra khi bạn đã tách mã, tuy nhiên - khả năng tìm kiếm ở một nơi là một tạo tác của khớp nối chặt chẽ.

Tôi không nghĩ rằng một danh sách như vậy tồn tại, tuy nhiên hãy cố gắng đọc những bài viết đó:

• DI có thể che khuất mã (nếu bạn không làm việc với một IDE tốt)

• Việc lạm dụng IoC có thể dẫn đến mã xấu theo chú Bob.

• Cần phải xem xét kỹ thuật quá mức và tạo ra tính linh hoạt không cần thiết.

Tôi đã sử dụng Guice (Java DI framework) rộng rãi trong 6 tháng qua. Mặc dù về tổng thể tôi nghĩ nó là tuyệt vời (đặc biệt là từ góc độ thử nghiệm), có những nhược điểm nhất định. Đáng chú ý nhất:

• Mã có thể trở nên khó hiểu hơn. Tiêm phụ thuộc có thể được sử dụng theo những cách rất ... sáng tạo. Ví dụ: tôi vừa bắt gặp một số mã sử dụng chú thích tùy chỉnh để tiêm một IOStream nhất định (ví dụ: @ Server1Stream, @ Server2Stream). Mặc dù điều này không hiệu quả và tôi thừa nhận có một sự tao nhã nhất định, nhưng điều đó làm cho việc hiểu về tiêm Guice là điều kiện tiên quyết để hiểu mã.
• Đường cong học tập cao hơn khi học dự án. Điều này có liên quan đến điểm 1. Để hiểu cách một dự án sử dụng phép tiêm phụ thuộc hoạt động, bạn cần hiểu cả mẫu tiêm phụ thuộc và khung cụ thể. Khi tôi bắt đầu với công việc hiện tại, tôi đã dành khá nhiều giờ bối rối để tìm hiểu xem Guice đang làm gì ở hậu trường.
• Nhà xây dựng trở nên lớn. Mặc dù điều này có thể được giải quyết phần lớn với một nhà xây dựng mặc định hoặc một nhà máy.
• Lỗi có thể bị xáo trộn. Ví dụ gần đây nhất của tôi về điều này là tôi đã va chạm vào 2 tên cờ. Guice nuốt lỗi một cách im lặng và một trong những lá cờ của tôi không được khởi tạo.
• Lỗi được đẩy đến thời gian chạy. Nếu bạn định cấu hình mô-đun Guice của mình không chính xác (tham chiếu vòng tròn, ràng buộc xấu, ...), hầu hết các lỗi không được phát hiện trong thời gian biên dịch. Thay vào đó, các lỗi được phơi bày khi chương trình thực sự chạy.

Bây giờ tôi đã phàn nàn. Hãy để tôi nói rằng tôi sẽ tiếp tục (sẵn sàng) sử dụng Guice trong dự án hiện tại của tôi và rất có thể là kế tiếp của tôi. Phụ thuộc tiêm là một mô hình tuyệt vời và vô cùng mạnh mẽ. Nhưng nó chắc chắn có thể gây nhầm lẫn và bạn gần như chắc chắn sẽ dành thời gian chửi rủa bất cứ khuôn khổ tiêm phụ thuộc nào bạn chọn.

Ngoài ra, tôi đồng ý với các áp phích khác rằng tiêm phụ thuộc có thể được sử dụng quá mức.

Mã không có bất kỳ DI nào có nguy cơ bị vướng vào mã Spaghetti nổi tiếng - một số triệu chứng là các lớp và phương thức quá lớn, làm quá nhiều và không thể dễ dàng thay đổi, phá vỡ, tái cấu trúc hoặc kiểm tra.

Mã với DI được sử dụng rất nhiều có thể là mã Ravioli trong đó mỗi lớp nhỏ giống như một ravioli riêng lẻ - nó thực hiện một điều nhỏ và nguyên tắc trách nhiệm duy nhất được tuân thủ, điều này là tốt. Nhưng nhìn vào các lớp học, thật khó để biết toàn bộ hệ thống làm gì, vì điều này phụ thuộc vào việc tất cả những phần nhỏ này khớp với nhau như thế nào, rất khó để nhìn thấy. Nó chỉ trông giống như một đống lớn những thứ nhỏ.

Bằng cách tránh sự phức tạp spaghetti của các bit lớn của mã được ghép trong một lớp lớn, bạn sẽ gặp rủi ro về một loại phức tạp khác, nơi có rất nhiều lớp nhỏ đơn giản và sự tương tác giữa chúng rất phức tạp.

Tôi không nghĩ rằng đây là một nhược điểm chết người - DI vẫn còn rất đáng giá. Một số mức độ của phong cách ravioli với các lớp học nhỏ chỉ làm một điều có lẽ là tốt. Thậm chí vượt quá, tôi không nghĩ rằng nó là xấu như mã spaghetti. Nhưng nhận thức được rằng nó có thể được đưa đi quá xa là bước đầu tiên để tránh nó. Thực hiện theo các liên kết để thảo luận về cách tránh nó.

Nếu bạn có một giải pháp trồng tại nhà, các phụ thuộc sẽ ở ngay trên khuôn mặt của bạn trong hàm tạo. Hoặc có thể là các tham số phương thức mà một lần nữa không quá khó để phát hiện ra. Mặc dù các phụ thuộc được quản lý khung, nếu được đưa đến các thái cực, có thể bắt đầu xuất hiện như ma thuật.

Tuy nhiên, có quá nhiều phụ thuộc trong quá nhiều lớp là một dấu hiệu rõ ràng cho thấy cấu trúc lớp của bạn bị sai lệch. Vì vậy, theo cách tiêm phụ thuộc (trồng tại nhà hoặc quản lý khung) có thể giúp đưa các vấn đề thiết kế rõ ràng ra ngoài mà có thể ẩn giấu trong bóng tối.

Để minh họa điểm thứ hai tốt hơn, đây là một đoạn trích từ bài viết này ( nguồn gốc ) mà tôi hoàn toàn tin tưởng là vấn đề cơ bản trong việc xây dựng bất kỳ hệ thống nào, không chỉ hệ thống máy tính.

Giả sử bạn muốn thiết kế một khuôn viên trường đại học. Bạn phải ủy thác một số thiết kế cho sinh viên và giáo sư, nếu không, tòa nhà Vật lý sẽ không hoạt động tốt cho người vật lý. Không có kiến ​​trúc sư nào biết đủ về những gì con người vật lý cần để tự làm tất cả. Nhưng bạn không thể ủy thác thiết kế của mọi phòng cho người ở trong đó, vì sau đó bạn sẽ nhận được một đống gạch vụn khổng lồ.

Làm thế nào bạn có thể phân phối trách nhiệm cho thiết kế thông qua tất cả các cấp của một hệ thống phân cấp lớn, trong khi vẫn duy trì tính nhất quán và hài hòa của thiết kế tổng thể? Đây là vấn đề thiết kế kiến ​​trúc mà Alexander đang cố gắng giải quyết, nhưng đây cũng là vấn đề cơ bản của phát triển hệ thống máy tính.

DI có giải quyết được vấn đề này không? Không . Nhưng nó giúp bạn thấy rõ nếu bạn đang cố gắng giao trách nhiệm thiết kế mọi phòng cho người ở trong đó.

Một điều khiến tôi vặn vẹo một chút với DI là giả định rằng tất cả các đối tượng được tiêm đều rẻ để khởi tạo và không gây ra tác dụng phụ - HOẶC - sự phụ thuộc được sử dụng thường xuyên đến mức vượt xa mọi chi phí tức thời liên quan.

Trường hợp này có thể có ý nghĩa là khi một phụ thuộc không được sử dụng thường xuyên trong một lớp tiêu thụ; chẳng hạn như một cái gì đó như một IExceptionLogHandlerService. Rõ ràng, một dịch vụ như thế này được gọi (hy vọng :)) hiếm khi trong lớp - có lẽ chỉ trong các trường hợp ngoại lệ cần phải được ghi lại; nhưng mô hình tiêm xây dựng chính tắc ...

Public Class MyClass
    Private ReadOnly mExLogHandlerService As IExceptionLogHandlerService

    Public Sub New(exLogHandlerService As IExceptionLogHandlerService)
        Me.mExLogHandlerService = exLogHandlerService
    End Sub

     ...
End Class

... Yêu cầu phải cung cấp một phiên bản "trực tiếp" của dịch vụ này, làm giảm chi phí / tác dụng phụ cần thiết để có được dịch vụ đó. Không phải là nó có khả năng, nhưng điều gì sẽ xảy ra nếu việc xây dựng trường hợp phụ thuộc này liên quan đến một lần truy cập dịch vụ / cơ sở dữ liệu hoặc tra cứu tệp cấu hình hoặc khóa tài nguyên cho đến khi xử lý? Nếu dịch vụ này thay vào đó được xây dựng khi cần thiết, đặt dịch vụ hoặc do nhà máy tạo ra (tất cả đều có vấn đề của riêng họ), thì bạn sẽ chỉ mất chi phí xây dựng khi cần thiết.

Bây giờ, một nguyên tắc thiết kế phần mềm được chấp nhận chung là việc xây dựng một đối tượng là rẻ và không tạo ra tác dụng phụ. Và trong khi đó là một khái niệm tốt đẹp, nó không phải luôn luôn như vậy. Tuy nhiên, sử dụng phương thức tiêm xây dựng điển hình đòi hỏi cơ bản là trường hợp này. Có nghĩa là khi bạn tạo ra một triển khai của một phụ thuộc, bạn phải thiết kế nó với DI trong tâm trí. Có thể bạn sẽ khiến việc xây dựng đối tượng tốn kém hơn để thu được lợi ích ở nơi khác, nhưng nếu việc triển khai này sẽ được thực hiện, nó có thể sẽ buộc bạn phải xem xét lại thiết kế đó.

Nhân tiện, một số kỹ thuật nhất định có thể giảm thiểu vấn đề chính xác này bằng cách cho phép tải nhanh các phụ thuộc được tiêm, ví dụ như cung cấp một thể hiện của lớp Lazy<IService>làm phụ thuộc. Điều này sẽ thay đổi các hàm tạo của các đối tượng phụ thuộc của bạn và sau đó nhận thức rõ hơn về các chi tiết triển khai, chẳng hạn như chi phí xây dựng đối tượng, điều được cho là không mong muốn.

Ảo tưởng rằng bạn đã tách mã của mình chỉ bằng cách thực hiện tiêm phụ thuộc mà không THỰC SỰ tách mã. Tôi nghĩ đó là điều nguy hiểm nhất về DI.

Đây là nhiều hơn một nitpick. Nhưng một trong những nhược điểm của việc tiêm phụ thuộc là nó làm cho các công cụ phát triển khó khăn hơn một chút để lý giải và điều hướng mã.

Cụ thể, nếu bạn Control-Click / Command-Click vào một lời gọi phương thức trong mã, nó sẽ đưa bạn đến phần khai báo phương thức trên một giao diện thay vì triển khai cụ thể.

Đây thực sự là một nhược điểm của mã được ghép lỏng lẻo (mã được thiết kế bởi giao diện) và áp dụng ngay cả khi bạn không sử dụng phép tiêm phụ thuộc (nghĩa là ngay cả khi bạn chỉ sử dụng các nhà máy). Nhưng sự ra đời của tiêm phụ thuộc là những gì thực sự khuyến khích mã ghép lỏng lẻo với công chúng, vì vậy tôi nghĩ tôi đã đề cập đến nó.

Ngoài ra, lợi ích của mã được ghép lỏng lẻo vượt xa điều này, do đó tôi gọi nó là một nitlog. Mặc dù tôi đã làm việc đủ lâu để biết rằng đây là loại đẩy lùi mà bạn có thể nhận được nếu bạn cố gắng giới thiệu tiêm phụ thuộc.

Trên thực tế, tôi mạo hiểm đoán rằng với mỗi "nhược điểm" bạn có thể tìm thấy khi tiêm phụ thuộc, bạn sẽ tìm thấy nhiều mặt tích cực vượt xa nó.

Tiêm phụ thuộc dựa trên trình xây dựng (không có sự trợ giúp của "khung" ma thuật) là một cách rõ ràng và có lợi để cấu trúc mã OO. Trong các bộ mã tốt nhất tôi từng thấy, qua nhiều năm dành cho các đồng nghiệp cũ khác của Martin Fowler, tôi bắt đầu nhận thấy rằng hầu hết các lớp tốt được viết theo cách này đều có một doSomethingphương pháp duy nhất .

Do đó, nhược điểm lớn là một khi bạn nhận ra tất cả chỉ là cách viết OO tay dài, kín đáo như các lớp học để có được lợi ích của lập trình chức năng, động lực của bạn để viết mã OO có thể nhanh chóng bay hơi.

Tôi thấy rằng tiêm constructor có thể dẫn đến các constructor xấu xí lớn, (và tôi sử dụng nó trong suốt cơ sở mã của mình - có lẽ các đối tượng của tôi quá chi tiết?). Ngoài ra, đôi khi với tiêm constructor tôi kết thúc với các phụ thuộc vòng tròn khủng khiếp (mặc dù điều này rất hiếm), vì vậy bạn có thể thấy mình phải có một số loại vòng đời trạng thái sẵn sàng với một vài vòng tiêm phụ thuộc trong một hệ thống phức tạp hơn.

Tuy nhiên, tôi thích tiêm construtor hơn tiêm setter vì một khi đối tượng của tôi được xây dựng, thì tôi không nghi ngờ gì về trạng thái của nó, cho dù đó là trong môi trường thử nghiệm đơn vị hoặc được tải lên trong một thùng chứa IOC. Mà, theo cách vòng vo, đang nói những gì tôi cảm thấy là nhược điểm chính với tiêm setter.

(với tư cách là một sidenote, tôi thấy toàn bộ chủ đề khá "tôn giáo", nhưng số dặm của bạn sẽ thay đổi theo mức độ nhiệt tình kỹ thuật trong nhóm nhà phát triển của bạn!)

Nếu bạn đang sử dụng DI mà không có bộ chứa IOC, nhược điểm lớn nhất là bạn nhanh chóng thấy có bao nhiêu phụ thuộc mà mã của bạn thực sự có và mọi thứ thực sự kết hợp chặt chẽ như thế nào. ("Nhưng tôi nghĩ rằng đó là một thiết kế tốt!") Tiến trình tự nhiên là hướng tới một thùng chứa IOC có thể mất một chút thời gian để tìm hiểu và thực hiện (gần như không tệ như đường cong học tập WPF, nhưng nó không miễn phí hoặc). Nhược điểm cuối cùng là một số nhà phát triển sẽ bắt đầu viết trung thực các bài kiểm tra đơn vị lòng tốt và họ sẽ mất thời gian để tìm ra nó. Những con quỷ trước đây có thể tạo ra thứ gì đó trong nửa ngày sẽ đột nhiên mất hai ngày để cố gắng tìm ra cách chế giễu tất cả sự phụ thuộc của chúng.

Tương tự như câu trả lời của Mark Seemann, điểm mấu chốt là bạn dành thời gian để trở thành một nhà phát triển tốt hơn thay vì hack các đoạn mã cùng nhau và tung nó ra khỏi cửa / đưa vào sản xuất. Mà doanh nghiệp của bạn sẽ có? Chỉ có bạn mới có thể trả lời điều đó.

DI là một kỹ thuật hoặc một mô hình và không liên quan đến bất kỳ khuôn khổ nào. Bạn có thể nối dây phụ thuộc của bạn bằng tay. DI giúp bạn với SR (Trách nhiệm đơn lẻ) và SoC (tách mối quan tâm). DI dẫn đến một thiết kế tốt hơn. Từ quan điểm và kinh nghiệm của tôi không có nhược điểm . Giống như với bất kỳ mẫu nào khác, bạn có thể hiểu sai hoặc sử dụng sai (nhưng trong trường hợp DI khá khó khăn).

Nếu bạn giới thiệu DI là nguyên tắc cho một ứng dụng cũ, sử dụng khung - lỗi lớn nhất bạn có thể làm là sử dụng sai mục đích đó là Công cụ định vị dịch vụ. DI + Framework chính nó là tuyệt vời và chỉ làm cho mọi thứ tốt hơn ở mọi nơi tôi thấy nó! Từ quan điểm tổ chức, có những vấn đề chung với mọi quy trình, kỹ thuật, mô hình mới, ...:

• Bạn phải đào tạo đội ngũ của bạn
• Bạn phải thay đổi ứng dụng của mình (bao gồm rủi ro)

Nói chung, bạn phải đầu tư thời gian và tiền bạc , bên cạnh đó, không có nhược điểm, thực sự!

Mã dễ đọc. Bạn sẽ không thể dễ dàng tìm ra luồng mã do các phụ thuộc được ẩn trong các tệp XML.

Hai điều:

• Họ yêu cầu hỗ trợ công cụ bổ sung để kiểm tra xem cấu hình có hợp lệ không.

Ví dụ: IntelliJ (phiên bản thương mại) có hỗ trợ kiểm tra tính hợp lệ của cấu hình Spring và sẽ gắn cờ các lỗi như vi phạm loại trong cấu hình. Nếu không có loại hỗ trợ công cụ đó, bạn không thể kiểm tra xem cấu hình có hợp lệ hay không trước khi chạy thử nghiệm.

Đây là một lý do tại sao mẫu 'bánh' (như cộng đồng Scala biết đến) là một ý tưởng hay: hệ thống dây giữa các thành phần có thể được kiểm tra bởi trình kiểm tra loại. Bạn không có lợi ích đó với các chú thích hoặc XML.

• Nó làm cho phân tích tĩnh toàn cầu của các chương trình rất khó khăn.

Các khung như Spring hoặc Guice gây khó khăn cho việc xác định tĩnh xem biểu đồ đối tượng được tạo bởi container sẽ trông như thế nào. Mặc dù họ tạo một biểu đồ đối tượng khi khởi động bộ chứa, nhưng họ không cung cấp các API hữu ích mô tả biểu đồ đối tượng sẽ / sẽ được tạo.

Có vẻ như những lợi ích được cho là của một ngôn ngữ gõ tĩnh giảm đáng kể khi bạn liên tục sử dụng các kỹ thuật để làm việc xung quanh việc gõ tĩnh. Một cửa hàng Java lớn mà tôi vừa phỏng vấn là đã vạch ra các phụ thuộc xây dựng của họ bằng phân tích mã tĩnh ... phải phân tích tất cả các tệp Spring để có hiệu quả.

Nó có thể tăng thời gian khởi động ứng dụng vì bộ chứa IoC sẽ giải quyết các phụ thuộc theo cách thích hợp và đôi khi nó yêu cầu thực hiện một số lần lặp.