Alan Kay có ý nghĩa gì khi giao nhiệm vụ trực tiếp trong Lịch sử ban đầu của Smalltalk?

Tôi đã đọc cuốn Lịch sử ban đầu của Smalltalk và có một vài đề cập đến "sự phân công" khiến tôi đặt câu hỏi về sự hiểu biết của tôi về ý nghĩa của nó:

Mặc dù OOP đến từ nhiều động lực, hai là trung tâm. Quy mô lớn là tìm ra sơ đồ mô-đun tốt hơn cho các hệ thống phức tạp liên quan đến việc ẩn chi tiết, và quy mô nhỏ là tìm phiên bản phân công linh hoạt hơn, và sau đó cố gắng loại bỏ hoàn toàn.

(từ 1960-66 - OOP sớm và các ý tưởng hình thành khác của những năm sáu mươi , Phần I)

Những gì tôi nhận được từ Simula là bây giờ bạn có thể thay thế các ràng buộc và chuyển nhượng bằng các mục tiêu . Điều cuối cùng bạn muốn bất kỳ lập trình viên nào làm là gây rối với trạng thái bên trong ngay cả khi được trình bày theo nghĩa bóng. Thay vào đó, các đối tượng nên được trình bày dưới dạng trang web của các hành vi cấp cao hơn phù hợp hơn để sử dụng làm thành phần động . (...) Thật không may là phần lớn những gì được gọi là "lập trình hướng đối tượng" ngày nay chỉ đơn giản là lập trình kiểu cũ với các cấu trúc fancier. Nhiều chương trình được tải với các hoạt động "kiểu gán" hiện được thực hiện bằng các thủ tục đính kèm đắt tiền hơn.

(từ Phong cách "Hướng đối tượng" , Phần IV)

Tôi có đúng không khi diễn giải ý định rằng các đối tượng có nghĩa là mặt tiền và bất kỳ phương thức nào (hoặc "thông điệp") có mục đích là đặt một biến đối tượng trên một đối tượng (tức là "gán") đang đánh bại mục đích? Giải thích này dường như được hỗ trợ bởi hai tuyên bố sau trong Phần IV:

Bốn kỹ thuật được sử dụng cùng nhau - trạng thái bền bỉ, đa hình, khởi tạo và phương pháp theo mục tiêu cho đối tượng - chiếm phần lớn sức mạnh. Không ai trong số này yêu cầu "ngôn ngữ hướng đối tượng" được sử dụng - ALGOL 68 gần như có thể được chuyển sang phong cách này - và OOPL chỉ tập trung tâm trí của người thiết kế theo một hướng hiệu quả cụ thể. Tuy nhiên, thực hiện quyền đóng gói là một cam kết không chỉ trừu tượng hóa trạng thái, mà còn loại bỏ các ẩn dụ định hướng nhà nước khỏi lập trình.

... và:

Các câu lệnh chuyển nhượng - ngay cả những câu trừu tượng - thể hiện các mục tiêu ở mức độ rất thấp và sẽ cần nhiều hơn nữa để hoàn thành mọi việc. Nói chung, chúng tôi không muốn lập trình viên bị rối tung với trạng thái, cho dù có mô phỏng hay không.

Sẽ công bằng khi nói rằng những trường hợp mờ đục, bất biến đang được khuyến khích ở đây? Hay chỉ đơn giản là những thay đổi trạng thái trực tiếp được khuyến khích? Ví dụ, nếu tôi có một BankAccountlớp, nó OK để có GetBalance, Depositvà Withdrawphương pháp dụ / tin nhắn; chỉ cần chắc chắn rằng không có một SetBalancephương thức / thông báo cá thể?

Ý tưởng cơ bản (chịu ảnh hưởng của Sketchpad) là hầu hết các biến / giá trị nằm trong mối quan hệ động - với nhau (được duy trì bởi phần bên trong của đối tượng), do đó, có thể đặt lại trực tiếp giá trị từ bên ngoài là nguy hiểm. Bởi vì (trong Smalltalk dù sao) có ít nhất một phương thức setter cần thiết, điều này cho phép khả năng một hành động thiết lập bên ngoài được trung gian bởi phương thức bên trong để duy trì mối quan hệ tương quan mong muốn. Nhưng hầu hết những người sử dụng setters chỉ đơn giản là sử dụng chúng để mô phỏng các bài tập trực tiếp cho các biến nội tâm, và điều này vi phạm tinh thần và ý định của OOP thực sự.

Nhưng các đối tượng có "đường thế giới" thay đổi theo thời gian. Điều này có thể được coi là một -history- của các phiên bản của đối tượng trong đó các mối quan hệ - là phù hợp. Không có điều kiện chủng tộc trong sơ đồ này ... một đối tượng chỉ hiển thị khi nó ổn định và không còn tính toán. Điều này giống như một đồng hồ hai pha trong CTNH. (Ý tưởng từ Strachey, và khác với McCarthy, và chịu ảnh hưởng của Lucid.)

Lời chúc tốt nhất,

Alan Kay

Tôi nhận ra Alan đã trả lời câu hỏi này, và vì vậy có vẻ như thật vô nghĩa khi trả lời thêm. Tuy nhiên, Alan không trả lời mọi câu hỏi của bạn.

Đặc biệt:

Sẽ công bằng khi nói rằng những trường hợp mờ đục, bất biến đang được khuyến khích ở đây? Hay chỉ đơn giản là những thay đổi trạng thái trực tiếp được khuyến khích? Ví dụ: nếu tôi có lớp BankAccount, bạn có thể sử dụng các phương thức / tin nhắn cá nhân GetBalance, Deposit và rút tiền; chỉ cần đảm bảo rằng không có phương thức / thông báo cá thể SetBalance?

Câu trả lời ở đây là bạn không sử dụng hành vi bậc cao để cấu trúc chương trình của mình. Các hệ thống dịch vụ tài chính trong thế giới thực không nên có phương thức Gửi tiền trên lớp BankAccount, vì đó không phải là cách các ngân hàng làm việc trước khi phát minh ra máy tính! Khi ATM được phát minh, họ phải tự động hóa theo nghĩa đen những gì một Giao dịch viên đã làm tại ngân hàng. Vai trò của Giao dịch viên sẽ là thông báo cho khách hàng về trạng thái tài khoản của họ. Để thực hiện việc này, khách hàng chỉ được phép tương tác với Giao dịch viên theo một số cách, chẳng hạn như chuyển Phiếu gửi tiền cho Giao dịch viên.

Bằng cách trực tiếp thống nhất các đối tượng này - Giao dịch viên, Gửi tiền, v.v. - miền vấn đề được cấu trúc theo các thông báo được truyền bởi các thực thể trong hệ thống.

Bản thân một Tài khoản đóng vai trò - ý tưởng về Tài khoản có nghĩa đen là một tài khoản của dòng vốn và dòng chảy tài chính liên quan đến Tài sản, Trách nhiệm, Thu nhập hoặc Chi phí. Một hệ thống Kế toán, hoặc Kế toán, ghi lại, lưu giữ và tái tạo các luồng này và cho bạn biết tình hình tài chính của tài khoản tại một thời điểm. Báo cáo gần đây nhất của Người giao dịch có thể được coi là "ngay bây giờ", nhưng không thực sự: Đó thực sự là tình hình tài chính theo mô tả của Kế toán tại một thời điểm. Nó chỉ có ảo tưởng là "ngay bây giờ" khi bạn đến ngân hàng, bởi vì nhìn chung bạn là người duy nhất được phép thanh toán. Điều này đặc biệt đúng 100 năm trước, nhưng ngày nay nhiều người có thanh toán tự động,

Tại sao nó lại quan trọng? Vâng, hãy tự hỏi những gì cần phải được thực hiện để ghi lại một giao dịch:

Khách hàng có nhật ký kiểm toán nội bộ của riêng họ về mọi thứ họ đã làm, bao gồm cả biên lai từ Ngân hàng. Tương tự như vậy, Ngân hàng giữ nhật ký kiểm toán nội bộ của riêng họ về mọi thứ họ đã làm. Ngân hàng luôn thực hiện kế toán kép , nghĩa là họ ghi lại các giao dịch vào Sổ cái và Bảng cân đối kế toán . Điều này cho phép Ngân hàng thực hiện hòa giảivà đảm bảo rằng không có mục giả nào khi họ đóng sách trong một khoảng thời gian tài chính nhất định (hàng ngày, hàng tuần, hàng tháng, hàng quý, hàng năm, hai năm một lần, bất cứ điều gì). Điều này cũng cho thấy rằng hồ sơ cho những gì được ghi lại nên là bình thường. Có nghĩa là, nếu chúng tôi viết một chương trình để liệt kê tất cả các giao dịch duy nhất, chúng tôi có thể làm như vậy ngay cả khi các bản sao giả trong nhật ký kiểm toán nội bộ của chúng tôi, bởi vì chúng tôi đã nhúng các định danh giao dịch tạm thời vào các thông điệp đăng nhập.

Với khả năng thanh toán tự động để ghi nợ và ghi có vào tài khoản của bạn, có vẻ như ý nghĩa là Kế toán cũng có thể dự báo cho bạn. Đây là nhận thức về tác động mà máy tính có thể có đối với hệ thống kế toán. Theo đó, ai đó đã phát minh ra một sơ đồ hệ thống kế toán có tên là Tài nguyên-Sự kiện-Đại lý phù hợp hơn với việc không chỉ nhìn về quá khứ mà còn nhìn vào tương lai và ước tính dòng tiền ở mức độ chi tiết tốt hơn trước. Về cơ bản, REA chỉ là siêu dữ liệu nhiều hơn các hệ thống kế toán cổ điển đã có, cho phép báo cáo và phân tích kinh doanh tốt hơn. Ví dụ, phân tích "chuỗi giá trị" và phân tích "chuỗi cung ứng" không phải là điều dễ thực hiện với kế toán cổ điển.

Tương tự như vậy, Điện toán Agoric hoặc Hợp đồng thông minh mang ý tưởng từ cơ chế thị trường đến điện toán. Điều quan trọng là khi bạn cung cấp Phiếu gửi tiền, bạn cũng cung cấp Séc hoặc Ví để gửi tiền. Vì có thời gian chính giữa việc nhận Séc và nó thực sự xâm nhập vào Tài khoản của bạn, bạn cần một cách an toàn để quản lý tiền tệ. Hóa ra, các khả năng của đối tượng là một cách tự nhiên để đạt được tiền tệ an toàn phân tán. Chúng có thể được sử dụng để đảm bảo rằng Alice không lừa đảo Bob bằng cách rút tất cả tiền của cô ấy sau khi cô ấy viết Bob kiểm tra.