Smalltalk và IoC

Question

Tôi thấy rất nhiều khung công tác IoC cho .Net và Java. Có ai biết tại sao không có khung tương đương cho Smalltalk. Đây là một câu hỏi triết học hơn bất cứ điều gì khác. Tôi tự hỏi nếu có một cái gì đó trong cách Smalltalk làm những điều mà ngăn cản sự cần thiết của việc có một khuôn khổ IoC.

Answer 1

MVC được phát minh trên Smalltalk và được cho là khung ban đầu Inversion of Control. Trong khi hơi nhẹ hơn so với các đối tác java của nó, nó có các khái niệm cơ bản của một mô hình đang nắm giữ dữ liệu, một khung nhìn hiển thị dữ liệu để đáp ứng với các sự kiện được điều khiển từ một bộ điều khiển.

Ít lúng túng hơn, Java thực sự cần rất nhiều hỗ trợ khung công tác để thực hiện một ứng dụng web mà không có quá nhiều mã mẫu soạn sẵn. Smalltalk hỗ trợ các thành ngữ lập trình như continuations, cho phép tác giả giả vờ rằng họ không thực sự viết mã hướng sự kiện. Seaside hoạt động như thế này, mang lại những lợi ích của IoC với một mô hình phát triển linh hoạt hơn.

EDIT: MVC là một khuôn khổ cho giao diện người dùng trong Smalltalk (cho là nó không thực sự là một khung như vậy, nhưng thư viện lớp đã được xây dựng trong hỗ trợ cho nó). Nó có đảo ngược thuộc tính điều khiển trong đó khung nhìn và mô hình phản hồi các sự kiện được điều khiển bởi bộ điều khiển - không gọi cho chúng tôi, chúng tôi sẽ gọi cho bạn thuộc tính. Inversion of Control là một mẫu thiết kế trong các khung công tác được sử dụng để giảm nhu cầu mở rộng bản mẫu trong các ứng dụng java. Trong một số định nghĩa của một khung ứng dụng, Inversion of Control là thuộc tính chính được xem như phân biệt một khung công tác từ một thư viện.

Answer 2

Chức năng là công dân hạng nhất trong smalltalk, do đó dễ dàng có IoC mà không có khung.

Answer 3

Tôi nghĩ rằng IOC hoặc mô hình Dependency Injection giải quyết một vấn đề không thực sự tồn tại trong môi trường Smalltalk. Smalltalk là một ngôn ngữ động không định dạng và sử dụng thông điệp truyền để giao tiếp. Điều này làm cho các đối tượng được liên kết lỏng lẻo với thiên nhiên ở cấp độ ngôn ngữ. Bất kỳ đối tượng nào cũng có thể gửi một tin nhắn đến một đối tượng khác mà không quan tâm đến loại miễn là nó có thể xử lý thông báo. Vì vậy, như bạn có thể đoán thay đổi phụ thuộc tại bất kỳ thời điểm nào là tương đối dễ dàng và tự nhiên. Chỉ cần phải quyết định ở đâu, khi nào, và làm thế nào bạn muốn thay đổi sự phụ thuộc.

Answer 4

Một vài lý do có thể cho việc này. Một là chúng tôi đã không bận tâm để sử dụng vòng loại "IoC", mà về cơ bản là dư thừa - kể từ khi gọi một cái gì đó một khuôn khổ ngụ ý sự đảo ngược của dòng điều khiển.

Một ngôn ngữ khác là ngôn ngữ Smalltalk cung cấp hỗ trợ trực tiếp cho luồng "IoC" - dưới hình thức đóng. Một kết quả của việc lập trình với các bao đóng là luồng điều khiển được tìm thấy trong các khung công tác không có vẻ quá khác biệt khi gợi lên một cảm giác bị "đảo ngược" từ một dòng chảy "bình thường"; thay vào đó, với các bao đóng, luồng điều khiển được lật qua lại giữa hai quan điểm này mọi lúc, mọi nơi. Ngay cả trong các câu lệnh đơn lẻ.

Lý do thứ ba, có lẽ là, ngay cả khi không đóng cửa, "đảo ngược kiểm soát" được mô tả không liên kết duy nhất với các khung công tác - các luồng giống nhau được tìm thấy trong hầu hết các dạng mã liên quan đến I/O.

Thứ tư, Smalltalkers có thể sử dụng các loại dòng này thậm chí nhiều hơn các loại khác, vì chúng ta dựa nhiều hơn vào khái niệm của các đối tượng và các thông điệp được gửi giữa chúng hơn các khái niệm về cấu trúc và gọi hàm thành viên. Trong sự vắng mặt của bao đóng, hai quan điểm này là tương đương, và có thể hoán đổi cho nhau, nhưng việc bổ sung các đóng cửa thay đổi kết quả - ý thức của luồng điều khiển được sử dụng là một trong những hiệu ứng.Cuối cùng, người ta thậm chí có thể nghĩ đến việc mô tả phong cách kiểm soát dòng chảy REPL như một "đơn giản", nhưng "đảo ngược" ý nghĩa của dòng chảy "bình thường", bình thường theo nghĩa là nó được sử dụng gần như ở mọi nơi khác.

Tóm lại, cùng một loại khung công tác tồn tại cho Smalltalk. Chúng tôi mô tả chúng hơi khác một chút. Sự khác biệt là, ít nhất là một phần, do sự hiện diện và sử dụng của các bao đóng trong Smalltalk, mà nhiều môi trường khác chưa cung cấp - - đáng chú ý là C++, C# và Java.

Answer 5

Trong Java một phụ thuộc được tạo ra khi bạn viết cái gì đó như

MyClass32 temp = this.theThing();

Bây giờ mã của bạn DEPENDS trên lớp MyClass32 đang ở gần. Mã của bạn sẽ không hoạt động mà không có mã. Bất kỳ thay đổi nào trong lớp đó có thể làm cho mã của bạn không thể hoàn tất, yêu cầu một số thay đổi thêm trong mã của bạn, trong đó có thể yêu cầu thay đổi mã khác trong lớp phụ thuộc vào bạn. Rất nhiều công việc phụ.

Trong Smalltalk, bạn sẽ viết temp: = self theThing;

Mã của bạn sẽ hoạt động không có vấn đề gì được trả về bởi #getTheThing. Mã của bạn không phụ thuộc trên lớp MyClass32 đang ở xung quanh. Phụ thuộc duy nhất của bạn là 'tạm thời' phải hiểu bất kỳ thông tin nào bạn gửi cho nó.

Vì vậy, theo ý nghĩa, mục đích của Dependency Injection Frameworks là tạo một ngôn ngữ được nhập tĩnh như Java hoạt động giống như một kiểu được nhập dy7namically.

Điều đó nói rằng, có một MẪU THIẾT KẾ Tôi thường xuyên theo sau trong Smalltalk: Tạo một phương thức lớp như MyClass trả về SOME class. Nó không cần phải có 'MyCLass' của NAME. Nó có thể là một trong một số lớp học , trở lại một lớp khác vào ban đêm. Mẫu này có trong Smalltalk MVC, trong đó Chế độ xem có phương thứC#defaultControllerClass, thường được định nghĩa lại bởi các lớp con.