Trách nhiệm duy nhất trong smalltalk

Question

Nếu Single Responsibility Principle áp dụng cho OOP và smalltalk (& ruby) được coi là một trong những ngôn ngữ OO nhất tại sao lớp Object phản hồi lại quá nhiều thư?

Chỉ cần một vài từ Object methodDict explore:

• kiểm tra, khám phá, duyệt, in: trên:
• chấp nhận (? Mẫu người truy cập vào tất cả các đối tượng)
• sao chép, deepCopy, tham gia, joinTo, tại :, tại địa chỉ: sửa đổi:
• asString, asFunction, asOrderedCollection (tại sao không tài sản cũng?)
• biển người: asLink, asJson, asJavascript

Nó không phải là đối tượng của trách nhiệm (ví dụ mô hình miền sử dụng nên được quan tâm chỉ trong tin nhắn, thanh toán của nó, vv)

EDIT: một số trong số đó là có ý nghĩa (asString, asOrderedCollection, chấp nhận, thông báo) trong khi những người khác có vẻ khá kỳ lạ (ở :, asFunction, deepCopy, tham gia, joinTo)

Answer 1

Bạn phải xem xét các tính năng mô đun của Smalltalk. Cụ thể, các định nghĩa phương thức độc lập với các định nghĩa lớp, do đó, các phương thức trên Object có thể được đóng gói với ứng dụng mà chúng liên quan đến (ví dụ: Seaside). Các phương thức mở rộng không phải là một phần của hệ thống cơ sở, vì vậy chúng chỉ thêm trách nhiệm vào lớp của chúng từ quan điểm của gói mà chúng thuộc về. Nhiều phương pháp trong số này là các điểm công văn kép đơn giản: nếu anObject asFoo chỉ cần ủy quyền cho Foo fromObject: anObject, tôi sẽ không nói nó thêm nhiều trách nhiệm cho lớp học.

phương pháp phản quang như inspect, copy, deepCopy khái niệm có chỗ đứng của họ trên Object, nhưng tôi đồng ý rằng có kiến ​​trúc tốt hơn cho sự phản xạ (Mirrors).

Bây giờ, Smalltalk có thể là một lý tưởng với các nguyên tắc đẹp, nhưng bạn phải mất việc triển khai cụ thể với một hạt muối :)

hệ thống Smalltalk có xu hướng phát triển thành hệ thống nguyên khối lớn, bởi vì nó rất dễ dàng để thay đổi hệ thống cơ sở, và bởi vì nó hấp dẫn để sử dụng hình ảnh như một tạo phẩm phát triển, bỏ qua các thực hành tốt về tích hợp liên tục.Cuối cùng, rất nhiều trách nhiệm trong lớp học vui nhộn này là do lý do lịch sử/thực tiễn; điều này đặc biệt đúng với Squeak, vì nó chủ yếu được phát triển như một nền tảng cho thử nghiệm đa phương tiện nhanh, hơn là cho mục đích giáo dục kỹ thuật phần mềm hoặc công nghiệp (mà Pharo hướng đến).

Answer 2

Một vài lý do:

• Object và ProtoObject là cơ sở của mô hình đối tượng Smalltalk, vì vậy nó hoàn toàn bình thường mà họ có lớn responsibil ities, giống như chăm sóc sao chép, serialization, vv
• The law of Demeter có thể quan trọng hơn ở đây: ai sẽ chăm sóc các chức năng này, nếu không phải là chính Object?
• Rất nhiều chức năng này có sẵn cho mục đích gỡ lỗi và đại diện. Bạn có thể làm việc mà không cần duyệt, khám phá và kiểm tra (nhưng chúng thực sự hữu ích).

Về cơ bản, tất cả các thông điệp này đại diện cho mọi thứ mà một đối tượng có thể làm và có rất nhiều điều bạn có thể làm.

Answer 3

Bởi vì trong Smalltalk - mọi thứ là một đối tượng, và lớp Object gốc về cơ bản đã chi phối tất cả các hành vi hệ thống, bao gồm cả hệ thống phân cấp lớp (như tất cả các lớp học là những đối tượng) và hệ thống phân cấp metaclass.

Với sức mạnh to lớn, trách nhiệm lớn.

Trong các hệ thống khác, nơi các đối tượng chỉ đơn giản là tên miền phụ của toàn bộ hệ thống, đối tượng không phải thực hiện quá nhiều, do đó không cần phải có quá nhiều trách nhiệm được đặt tên.