Khám phá những ý tưởng chính của Alan Kay về Smalltalk và GUI sơ khai — và cách chúng định hình cách ta nhìn phần mềm như các hệ thống đối tượng tương tác ngày nay.
Alan Kay không chỉ là một cái tên trong lịch sử lập trình. Nhiều giả định hàng ngày về máy tính — một “cửa sổ” nghĩa là gì, tại sao phần mềm nên tương tác, làm thế nào chương trình có thể được ghép từ các phần hợp tác — đã bị định hình bởi những ý tưởng ông thúc đẩy (thường cùng các nhóm tại Xerox PARC).
Bài viết này nói về các khái niệm, không phải chuyện vặt. Bạn không cần biết lập trình để theo dõi, và bạn sẽ không thấy một chuyến tham quan chi tiết kỹ thuật khó hiểu. Thay vào đó, ta tập trung vào vài mô hình tư duy vẫn xuất hiện trong công cụ và sản phẩm: cách phần mềm có thể được hiểu, thay đổi, và học được.
Đầu tiên, Smalltalk: không chỉ là một ngôn ngữ, mà là một toàn bộ môi trường làm việc khuyến khích khám phá và học hỏi.
Thứ hai, GUI (giao diện người dùng đồ họa): cửa sổ, biểu tượng, menu — phần mềm tương tác như thứ bạn có thể thao tác trực tiếp, không chỉ hướng dẫn từ xa.
Thứ ba, tư duy hệ thống: xem phần mềm như một tập hợp các phần tương tác với vòng phản hồi, thay vì một đống file mã.
Nó sẽ không coi Kay là thiên tài đơn độc, và cũng không khẳng định một “mô hình đúng” chữa mọi thứ. Một vài ý tưởng hoạt động xuất sắc, một số bị hiểu sai, và một số không lan rộng như lẽ ra có thể.
Mục tiêu là thực dụng: đến cuối bài, bạn nên có thể nhìn vào ứng dụng hiện đại và codebase với cảm giác rõ ràng hơn về tại sao chúng lại như vậy — và những gì bạn có thể vay mượn cho dự án tiếp theo.
Alan Kay bước vào một văn hóa máy tính mạnh mẽ, đắt đỏ và phần lớn không quan tâm đến người thường. Máy tính được coi như hạ tầng chia sẻ: bạn đặt lịch, gửi công việc và chờ kết quả. Mô hình đó định hình mọi thứ — chương trình trông thế nào, ai được dùng, và “thành công” nghĩa là gì.
Với nhiều người, tính toán có nghĩa là giao công việc cho máy (thường bằng thẻ bài hoặc các terminal xếp hàng) và nhận đầu ra sau. Nếu có gì sai, bạn không “nghiền thử” để học — bạn gửi lại và đợi. Khám phá chậm chạp, và máy tính cảm giác như dịch vụ từ xa thay vì công cụ để suy nghĩ cùng.
Mục tiêu của Kay không chỉ là “máy nhỏ hơn.” Đó là một mối quan hệ khác: máy tính như một phương tiện cá nhân để học, viết, mô phỏng, vẽ và xây dựng ý tưởng — đặc biệt cho trẻ em và người không chuyên. Điều đó đòi hỏi sự tức thời. Bạn cần thấy hành động của mình làm gì, sửa nhanh và giữ trạng thái sáng tạo.
Để theo đuổi thay đổi đó, cần không gian thử nghiệm phần cứng, phần mềm và thiết kế tương tác cùng nhau. Phòng nghiên cứu như Xerox PARC dám đặt cược lâu dài: màn hình mới, thiết bị nhập mới, mô hình lập trình mới và cách đóng gói chúng thành trải nghiệm liền lạc. Mục tiêu không phải ra một tính năng — mà là phát minh một kiểu sử dụng máy tính mới.
Nếu máy tính sẽ là cỗ máy học và sáng tạo, khả năng sử dụng không thể là việc phó mặc. Giao diện phải hỗ trợ khám phá, phản hồi và hành động có thể hiểu được. Sự chú ý đó thúc đẩy Kay hướng tới các hệ thống nơi “cảm giác” tương tác — chuyện xảy ra khi bạn nhấp, chỉnh sửa hay khám phá — liên kết chặt chẽ với cấu trúc phần mềm.
Alan Kay không bắt đầu bằng “Làm sao để công việc văn phòng nhanh hơn?” Ông bắt đầu bằng câu hỏi khác: nếu một đứa trẻ có thể mang một máy tính cá nhân như cuốn sách, và dùng nó để khám phá ý tưởng, làm đồ, và học bằng cách làm thì sao? Ý tưởng đó trở thành Dynabook — không phải là một chỉ dẫn sản phẩm mà là ngôi sao phương Bắc cho điện toán cá nhân.
Dynabook được tưởng tượng là nhẹ, chạy pin, và luôn sẵn sàng. Nhưng từ quan trọng nhất không phải “di động.” Là “cá nhân.” Máy tính này sẽ thuộc về người dùng như một cuốn sổ hay nhạc cụ — thứ bạn định hình theo thời gian, không chỉ điều khiển.
Cũng quan trọng: nó phải dễ học. Mục tiêu của Kay không phải che giấu máy tính sau đống menu; mà để mọi người dần trở thành tác giả, không chỉ người tiêu thụ.
“Ứng dụng giết người” của Dynabook là đọc, viết, vẽ, soạn nhạc, mô phỏng thí nghiệm khoa học và xây dựng câu chuyện tương tác. Nó coi lập trình như một kỹ năng đọc‑viết — một cách biểu đạt ý tưởng — thay vì nghề chuyên môn dành cho chuyên gia.
Tập trung đó thay đổi cách định nghĩa “phần mềm tốt”. Công cụ học phải mời gọi thử nghiệm, cho phản hồi nhanh và làm cho việc thử lại trở nên an toàn.
Đây là nơi Smalltalk và GUI ban đầu liên kết. Nếu bạn muốn người ta tạo ra thứ gì đó, bạn cần thao tác trực tiếp, kết quả tức thì và môi trường mà thử nghiệm cảm thấy tự nhiên. Hệ thống sống, tương tác của Smalltalk và ẩn dụ trực quan của GUI hỗ trợ cùng mục tiêu: rút ngắn khoảng cách giữa ý tưởng và sản phẩm hoạt động.
Dynabook không phải là “dự đoán máy tính bảng.” Nó đề xuất một mối quan hệ mới với điện toán: một phương tiện tư duy và sáng tạo. Nhiều thiết bị có thể xấp xỉ điều đó, nhưng tầm nhìn là trao quyền cho người dùng — đặc biệt là người học — chứ không phải về kích thước màn hình hay thiết kế phần cứng cụ thể.
Khi người ta nghe “Smalltalk,” họ thường hình dung một ngôn ngữ lập trình. Nhóm của Kay coi nó là thứ lớn hơn: một hệ thống làm việc hoàn chỉnh, nơi ngôn ngữ, công cụ và trải nghiệm người dùng được thiết kế như một thể thống nhất.
Nói đơn giản, Smalltalk là hệ thống nơi mọi thứ đều là một đối tượng. Các cửa sổ trên màn hình, văn bản bạn gõ, nút bạn nhấn, con số bạn tính — mỗi thứ là một đối tượng bạn có thể yêu cầu thực hiện hành động.
Smalltalk được xây để học bằng cách làm. Thay vì viết mã, biên dịch và hy vọng chạy đúng, bạn có thể kiểm tra các đối tượng khi hệ thống đang chạy, thấy trạng thái hiện tại của chúng, thay đổi và thử ý mới ngay lập tức.
Sự sống động đó quan trọng vì nó biến lập trình thành khám phá. Bạn không chỉ tạo ra file; bạn đang định hình một thế giới đang chạy. Nó khuyến khích tò mò: “Cái này là gì?” “Nó chứa gì?” “Nếu tôi chỉnh nó thì chuyện gì xảy ra?”
Công cụ phát triển của Smalltalk không phải là phần bổ sung rời rạc. Trình duyệt lớp, trình kiểm tra, trình gỡ lỗi và trình soạn thảo là một phần của cùng vũ trụ đối tượng. Công cụ hiểu hệ thống từ bên trong vì chúng được xây bằng cùng môi trường.
Sự tích hợp chặt này thay đổi cảm nhận “làm việc với phần mềm”: ít giống quản lý mã nguồn ở xa, hơn là tương tác trực tiếp với hệ thống bạn đang xây.
Hãy nghĩ đến việc chỉnh sửa một tài liệu khi nó đang mở và phản hồi ngay — định dạng thay đổi tức thì, bạn có thể tìm, sắp xếp và hoàn tác mà không phải “xây lại” tài liệu. Smalltalk nhắm tới sự tức thời đó, nhưng cho chương trình: bạn sửa thứ đang chạy, thấy kết quả ngay và tiếp tục di chuyển.
Ý tưởng hữu ích nhất của Kay không phải là “lớp và kế thừa.” Là ý tưởng rằng một đối tượng là một chiếc máy tính nhỏ gọn: nó giữ trạng thái của riêng nó (những gì nó biết ngay bây giờ) và nó quyết định cách phản hồi khi bạn yêu cầu nó làm gì.
Hãy nghĩ mỗi đối tượng có:
Khung này hữu dụng vì nó dịch hướng chú ý của bạn từ “Dữ liệu được lưu ở đâu?” sang “Ai chịu trách nhiệm xử lý việc này?”
Một sự nhầm lẫn thường gặp là coi đối tượng như hồ sơ dữ liệu xịn: một bó trường với vài hàm trợ giúp. Ở góc nhìn đó, các phần khác của chương trình tự do nhìn vào và thao tác nội bộ.
Quan điểm của Kay gần với mô hình tác nhân. Bạn không chạm vào đối tượng để thay đổi ngăn kéo của nó. Bạn gửi yêu cầu và để nó quản lý trạng thái. Sự tách bạch này là điểm mấu chốt.
Gửi thông điệp đơn giản là yêu cầu/phản hồi.
Tưởng tượng một quán cà phê: bạn không vào bếp nấu chính mình. Bạn gọi món (“làm cho tôi một chiếc bánh mì”), và bạn nhận kết quả (“đây bánh mì” hoặc “hết bánh mì”). Quán quyết định cách hoàn thành yêu cầu.
Đối tượng phần mềm hoạt động tương tự: bạn gửi một thông điệp (“tính tổng”, “lưu”, “vẽ chính bạn”), và đối tượng phản hồi.
Khi các phần khác của hệ thống chỉ phụ thuộc vào thông điệp, bạn có thể thay đổi cách một đối tượng hoạt động bên trong — đổi thuật toán, thay lưu trữ, thêm cache — mà không buộc phải viết lại khắp nơi.
Đó là cách hệ thống phát triển mà không phá vỡ mọi thứ: thỏa thuận ổn định ở ranh giới, tự do bên trong thành phần.
Người ta thường hiểu “lập trình hướng đối tượng” như đồng nghĩa với “dùng lớp.” Điều đó dễ hiểu — hầu hết ngôn ngữ dạy OOP qua sơ đồ lớp và cây kế thừa. Nhưng sự nhấn mạnh ban đầu của Kay khác: hãy nghĩ theo các mảnh tương tác.
Một class là bản thiết kế: mô tả thứ gì đó biết gì và làm gì.
Một instance (đối tượng) là thực thể cụ thể làm từ bản thiết kế đó.
Một method là thao tác đối tượng thực hiện khi được yêu cầu.
State là dữ liệu hiện tại của đối tượng: những gì nó nhớ và có thể thay đổi theo thời gian.
Smalltalk phổ biến hóa mô hình đối tượng đồng nhất: mọi thứ là đối tượng, và bạn tương tác với đối tượng theo cách nhất quán. Nó cũng nhấn mạnh giao tiếp bằng thông điệp — bạn không chọc vào nội bộ đối tượng; bạn gửi thông điệp và để nó quyết định.
Phong cách đó gắn tự nhiên với ràng buộc muộn (late binding): chương trình có thể quyết định tại thời chạy phương thức nào xử lý thông điệp, dựa trên đối tượng nhận. Lợi ích thực dụng là linh hoạt: bạn có thể thay đổi hành vi mà không sửa người gọi.
Một mẹo hay: thiết kế xung quanh tương tác. Hỏi “Những thông điệp nào nên tồn tại?” và “Ai nên sở hữu trạng thái này?” Nếu các đối tượng hợp tác rõ ràng, cấu trúc lớp thường đơn giản hơn — và dễ thay đổi hơn — như một tác dụng phụ.
GUI thay đổi cảm nhận “sử dụng phần mềm.” Thay vì nhớ lệnh, bạn chỉ trỏ, di chuyển, mở và thấy kết quả ngay. Cửa sổ, menu, điều khiển và kéo‑thả làm máy tính giống việc xử lý vật thể — thao tác trực tiếp thay vì chỉ ra lệnh trừu tượng.
Cảm giác “vật‑thể” đó gắn tự nhiên với mô hình đối tượng. Trong GUI tốt, hầu như mọi thứ bạn nhìn và tương tác đều có thể được xử lý như đối tượng:
Đây không chỉ là tiện lợi lập trình; nó là cầu nối khái niệm. Người dùng nghĩ theo đối tượng (“di chuyển cửa sổ này”, “nhấn nút kia”), và phần mềm được xây từ các đối tượng thực sự làm được hành động đó.
Khi bạn nhấp, gõ hay kéo, hệ thống sinh ra một sự kiện. Trong góc nhìn hướng đối tượng, một sự kiện căn bản là thông điệp gửi đến một đối tượng:
Các đối tượng có thể chuyển tiếp thông điệp tới đối tượng khác (“bảo tài liệu lưu”, “bảo cửa sổ vẽ lại”), tạo nên chuỗi tương tác dễ hiểu.
Bởi vì UI được tạo từ các đối tượng tồn tại lâu với trạng thái hiển thị, nó cảm giác như vào một không gian làm việc hơn là chạy một lệnh một lần. Bạn có thể để cửa sổ mở, sắp xếp công cụ, trở lại tài liệu và tiếp tục. GUI trở thành môi trường liền lạc — nơi hành động là cuộc đối thoại giữa các đối tượng bạn có thể nhìn thấy.
Một trong những ý tưởng nổi bật nhất của Smalltalk không phải là cú pháp — mà là image. Thay vì nghĩ chương trình là “mã nguồn được biên dịch thành ứng dụng,” Smalltalk coi hệ thống như một thế giới đối tượng đang chạy. Khi lưu, bạn có thể lưu toàn bộ môi trường sống: các đối tượng trong bộ nhớ, công cụ mở, trạng thái UI và công việc hiện tại.
Hệ thống dựa trên image giống như tạm dừng một bộ phim và lưu không chỉ kịch bản, mà cả khung hình, bối cảnh và vị trí của mọi diễn viên. Khi tiếp tục, bạn trở lại nơi đã rời — công cụ vẫn mở, đối tượng vẫn còn đó, và thay đổi của bạn vẫn đang chạy.
Điều này hỗ trợ vòng phản hồi khít. Bạn có thể thay đổi hành vi, thử ngay, quan sát kết quả và tinh chỉnh — mà không phải bối rối với việc “xây lại, chạy lại, nạp dữ liệu, điều hướng về màn hình.”
Nguyên tắc tương tự xuất hiện trong các luồng làm việc “vibe-coding” hiện đại: khi bạn mô tả thay đổi bằng ngôn ngữ tự nhiên, thấy nó áp dụng ngay và lặp lại, bạn học hệ thống nhanh hơn và giữ được động lực. Những nền tảng như Koder.ai tận dụng điều này bằng cách biến việc xây app thành vòng lặp đối thoại — lập kế hoạch, điều chỉnh, xem trước — trong khi vẫn sinh mã thực để bạn xuất và bảo trì.
Bạn có thể thấy bóng dáng của ý tưởng image trong các tính năng được yêu thích hôm nay:
Chúng không giống hệt image của Smalltalk, nhưng cùng mục tiêu: rút ngắn khoảng cách giữa ý tưởng và kết quả.
Lưu cả thế giới đang chạy đặt ra câu hỏi khó. Khả năng tái tạo có thể giảm nếu “sự thật” sống trong trạng thái biến đổi thay vì quy trình build sạch. Triển khai phức tạp hơn: gửi một image có thể làm mờ ranh giới giữa app, dữ liệu và môi trường. Gỡ lỗi cũng phức tạp hơn khi lỗi phụ thuộc vào chuỗi tương tác và trạng thái tích tụ.
Phe Smalltalk cho rằng vòng lặp học nhanh và lặp nhanh đáng giá những khó khăn đó — và quan điểm đó vẫn ảnh hưởng đến nhiều đội nghĩ về trải nghiệm nhà phát triển.
Khi Alan Kay nói về phần mềm, ông thường xem nó ít như đống mã và hơn như một hệ thống: nhiều phần tương tác theo thời gian để tạo ra hành vi bạn quan tâm.
Một hệ thống không được định nghĩa bởi một thành phần. Nó được xác định bởi mối quan hệ — ai nói với ai, họ được phép yêu cầu gì, và chuyện gì xảy ra khi những cuộc đối thoại đó lặp lại.
Một vài thành phần đơn giản có thể tạo ra hành vi phức tạp khi có lặp lại và phản hồi. Một bộ đếm thời gian, một mô hình cập nhật trạng thái và một UI vẽ lại mỗi khi cần — từng thứ một có thể đơn giản. Ghép lại bạn có được hoạt ảnh, hoàn tác/làm lại, tự động lưu, cảnh báo và những khoảnh khắc “tại sao nó thay đổi vậy?”.
Đó là lý do tư duy hệ thống thực tế: nó thúc bạn tìm vòng lặp ("khi A thay đổi, B phản ứng, rồi C được kích hoạt…") và thời gian ("chuyện gì xảy ra sau 10 phút sử dụng?"), chứ không chỉ các cuộc gọi hàm đơn lẻ.
Trong một hệ thống, giao diện quan trọng hơn hiện thực. Nếu một phần chỉ tương tác với phần khác qua các thông điệp rõ ràng ("tăng đếm", "vẽ", "ghi sự kiện"), bạn có thể hoán đổi nội bộ mà không viết lại mọi thứ.
Điều này gần với nhấn mạnh của Kay về truyền thông điệp: bạn không điều khiển trực tiếp phần khác; bạn yêu cầu, họ phản hồi.
Hãy tưởng tượng ba đối tượng:
Dòng chảy theo thời gian:
clicked.increment đến CounterModel.changed(newValue).changed và vẽ lại.record("increment", newValue).Không thành phần nào cần nhìn vào nội bộ thành phần khác. Hành vi nổi lên từ cuộc hội thoại.
Alan Kay thúc một ý tưởng đơn giản nhưng vẫn cảm thấy cấp tiến: phần mềm nên dễ học, không chỉ mạnh mẽ. Thiết kế “tinh xảo” thường tối ưu cho sự thoả mãn của người tạo — lối tắt, mẹo ẩn, trừu tượng dày đặc — trong khi để người dùng bình thường phải nhớ lời thủ thuật.
Kay quan tâm tới sự đơn giản bởi vì nó mở rộng: một khái niệm người mới tiếp cận nhanh chóng nắm được sẽ là khái niệm mà đội ngũ có thể dạy, chia sẻ và xây dựng.
Nhiều phần mềm coi người dùng như người vận hành: nhấn đúng nút, nhận đầu ra. Mục tiêu của Kay gần hơn công cụ tư duy — thứ mời gọi khám phá, hỗ trợ thử sai và cho phép người ta xây dựng mô hình tinh thần.
Đó là lý do ông trân trọng hệ thống tương tác nơi bạn thấy điều gì đang xảy ra và điều chỉnh ngay. Khi hệ thống phản hồi tức thì và có ý nghĩa, việc học trở thành một phần của hành động sử dụng.
Kay thường lấy học làm mẫu thử bắt buộc cho tính rõ ràng. Nếu một khái niệm có thể thao tác trực tiếp, kiểm tra và giải thích mà không phải vòng vo, nó có khả năng hoạt động cho mọi người.
Không có nghĩa là “chỉ thiết kế cho trẻ em.” Là dùng khả năng dạy học làm tiêu chuẩn chất lượng: hệ thống có thể hiện logic của chính nó không?
Khả năng học là một tính năng sản phẩm. Bạn có thể thiết kế cho nó bằng cách:
Lợi ích không chỉ là người mới hài lòng. Là onboard nhanh hơn, ít phiền toái hỗ trợ hơn và sản phẩm mà người ta cảm thấy tự tin mở rộng — đúng kiểu “quyền tác giả người dùng” Kay mong muốn tăng cường.
Công trình của Kay không “phát minh mọi thứ chúng ta dùng hôm nay,” nhưng tác động lớn đến cách nhiều người nghĩ về xây dựng phần mềm — đặc biệt phần mềm dành cho con người.
Nhiều thực hành hiện đại phản ánh ý tưởng mà Smalltalk và văn hóa Xerox PARC làm cho cụ thể và phổ biến:
Một số phần của tầm nhìn ban đầu không truyền tải nguyên vẹn:
Nếu bạn tinh mắt, nhiều mẫu hiện nay ngân vang tư duy truyền thông điệp: UI thành phần (React/Vue), ứng dụng hướng sự kiện, và thậm chí microservices giao tiếp qua HTTP hoặc hàng đợi. Chúng không giống hệt nhưng cho thấy ý tưởng cốt lõi của Kay (hệ thống là các phần tương tác) tiếp tục được diễn giải dưới ràng buộc hiện đại.
Nếu muốn cầu nối thực tế từ lịch sử đến thực hành, phần cuối (Practical Takeaways) biến những ảnh hưởng này thành thói quen thiết kế bạn có thể dùng ngay.
Công trình của Kay nghe có vẻ triết lý, nhưng nó chuyển thành thói quen rất thực tế. Bạn không cần dùng Smalltalk — hoặc thậm chí “làm OOP” — để hưởng lợi. Mục tiêu là xây phần mềm giữ được tính hiểu được khi nó lớn lên.
Khi bắt đầu (hoặc refactor), thử mô tả hệ thống như các vai trò hợp tác:
Điều này giữ bạn tập trung vào trách nhiệm, không phải “phải tạo class vì cần class.”
Trước khi tranh luận về bảng cơ sở dữ liệu hay cây kế thừa, định nghĩa các thông điệp — một phần sẽ yêu cầu phần kia làm gì.
Một bài tập hữu dụng: viết một “cuộc hội thoại” ngắn cho một hành động người dùng:
Chỉ sau đó quyết định cách hiện thực các vai trò (class, module, service). Đây gần với nhấn mạnh của Kay về giao tiếp trước, cấu trúc sau.
Kay quan tâm tới hệ thống sống nơi bạn thấy hiệu ứng thay đổi nhanh. Trong đội hiện đại, điều đó thường nghĩa:
Nếu bạn không biết thứ gì đã thay đổi — hoặc có giúp không — bạn đang làm việc trong bóng tối.
Nếu bạn xây với luồng tương tác theo chat (ví dụ với Koder.ai), lời khuyên vẫn áp dụng: coi prompt và mã sinh như cách lặp nhanh, nhưng giữ ranh giới rõ ràng, và dùng snapshot/rollback cùng xuất mã nguồn để hệ thống dễ hiểu về lâu dài.
Nếu phần này hợp bạn, hãy khám phá:
Những chủ đề này không phải hoài niệm mà là cách phát triển thẩm mỹ: xây phần mềm dễ học, dễ thích nghi và có kết cấu rõ ràng như một hệ thống.
Alan Kay đề xuất một mối quan hệ khác với máy tính: không phải công việc theo lô có hàng đợi, mà là một phương tiện cá nhân, tương tác dành cho việc học và sáng tạo.
Tư duy đó đã định hình những kỳ vọng mà chúng ta coi là bình thường ngày nay — phản hồi ngay lập tức, giao diện có thể thao tác, và phần mềm có thể được khám phá và sửa đổi trong lúc bạn làm việc.
Dynabook là tầm nhìn về một máy tính cá nhân di động, thiết kế chủ yếu cho học tập và sáng tạo (đọc, viết, vẽ, mô phỏng).
Nó không đơn thuần là “dự đoán tablet” mà là xác định cảm nhận về một máy tính trao quyền cho người dùng: người dùng là tác giả, chứ không chỉ là người vận hành.
Trong Smalltalk, ngôn ngữ, công cụ và giao diện là một môi trường liền mạch.
Thực tế là bạn có thể kiểm tra các đối tượng đang chạy, thay đổi hành vi, gỡ lỗi tương tác và tiếp tục làm việc mà không cần liên tục biên dịch và khởi động lại — rút ngắn khoảng cách giữa ý tưởng và sản phẩm.
Ý tưởng cốt lõi của Kay không phải “lớp và kế thừa.” Đó là đối tượng như tác nhân độc lập giao tiếp bằng cách gửi và nhận thông điệp.
Về thiết kế, điều này thúc đẩy bạn xác định ranh giới rõ ràng: người gọi phụ thuộc vào những thông điệp một đối tượng chấp nhận, chứ không phải vào cách tổ chức dữ liệu nội bộ của nó.
Một sai lầm phổ biến là coi OOP chỉ là phân loại kiểu: nhiều lớp, kế thừa sâu, và dữ liệu thay đổi được chia sẻ.
Quy tắc hữu ích theo tư duy của Kay:
GUI làm cho phần mềm giống như thứ bạn thao tác trực tiếp (cửa sổ, nút, biểu tượng). Điều đó phù hợp với mô hình đối tượng: mỗi phần tử UI có trạng thái và hành vi.
Tác động của người dùng (nhấp, kéo, gõ) trở thành các sự kiện, về bản chất là thông điệp gửi đến đối tượng, và các đối tượng có thể chuyển tiếp tiếp tục trong hệ thống.
Một hệ thống sống Smalltalk (image) lưu toàn bộ thế giới đang chạy: các đối tượng trong bộ nhớ, công cụ mở, trạng thái UI và công việc hiện tại.
Ưu điểm:
Nhược điểm:
Tư duy hệ thống chuyển hướng chú ý sang hành vi theo thời gian: vòng phản hồi, phản ứng dây chuyền, và ai đang giao tiếp với ai.
Trong thực tế, nó dẫn đến thiết kế với giao diện rõ ràng (thông điệp) và ít phụ thuộc ẩn, vì bạn coi ứng dụng như các phần tương tác — không chỉ các hàm rời rạc.
Dùng thiết kế theo thông điệp cho một luồng công việc:
getTotal, isAvailable, authorize).Chỉ sau đó chọn cách hiện thực (lớp, module, dịch vụ). Phần kiểm tra thực hành (Practical Takeaways) ở cuối bài là một điểm bắt đầu tốt.
Các công cụ hiện đại thường vang vọng mục tiêu của Kay dù thực hiện khác:
Chúng không giống image của Smalltalk, nhưng cùng theo đuổi kết quả thực dụng: làm cho thay đổi và học hỏi rẻ hơn.