Một chương trình hướng đối tượng có thể được xem như một máy trạng thái hữu hạn không?

Đây có thể là một câu hỏi triết học / cơ bản, nhưng tôi chỉ muốn làm rõ nó.

Theo hiểu biết của tôi, Máy trạng thái hữu hạn là một cách mô hình hóa một hệ thống trong đó đầu ra của hệ thống sẽ không chỉ phụ thuộc vào các đầu vào hiện tại mà còn cả trạng thái hiện tại của hệ thống. Ngoài ra, như tên cho thấy, một máy trạng thái hữu hạn có thể được phân đoạn theo số N trạng thái hữu hạn với trạng thái và hành vi tương ứng.

Nếu điều này là chính xác, không phải mọi đối tượng có dữ liệu và thành viên hàm sẽ là một trạng thái trong mô hình hướng đối tượng của chúng ta, làm cho bất kỳ thiết kế hướng đối tượng nào trở thành một máy trạng thái hữu hạn?

Nếu đó không phải là cách giải thích của một FSM trong thiết kế đối tượng, thì chính xác mọi người có ý nghĩa gì khi họ triển khai một FSM trong phần mềm? tui bỏ lỡ điều gì vậy?

Cảm ơn

Bất kỳ chương trình đơn luồng nào chạy trên máy có dung lượng lưu trữ hữu hạn đều có thể được mô hình hóa thành máy trạng thái hữu hạn. Một trạng thái cụ thể trong máy trạng thái hữu hạn sẽ biểu thị các giá trị cụ thể của tất cả các biến cục bộ lưu trữ có liên quan, biến toàn cục, lưu trữ heap, dữ liệu hiện được hoán đổi trong bộ nhớ ảo, thậm chí là nội dung của các tệp có liên quan. Nói cách khác, sẽ có rất nhiều trạng thái trong mô hình trạng thái hữu hạn đó, ngay cả đối với các chương trình khá tầm thường.

Ngay cả khi trạng thái duy nhất mà chương trình của bạn có là một biến toàn cục duy nhất của loại số nguyên 32 bit, hàm ý đó có ít nhất 2 ^ 32 (hơn 4 tỷ) trạng thái. Và điều đó thậm chí không tính đến bộ đếm chương trình và ngăn xếp cuộc gọi.

Một mô hình tự động đẩy xuống là thực tế hơn cho loại điều này. Nó giống như một máy tự động hữu hạn, nhưng có một khái niệm tích hợp về ngăn xếp. Tuy nhiên, đây không thực sự là một ngăn xếp cuộc gọi như trong hầu hết các ngôn ngữ lập trình.

Có một lời giải thích Wikipedia , nhưng đừng sa lầy vào phần định nghĩa chính thức.

Automata đẩy xuống được sử dụng để mô hình tính toán chung. Các máy Turing tương tự nhau , nhưng IIRC không giống nhau - mặc dù khả năng tính toán của chúng là tương đương .

Cảm ơn kevin cline vì đã chỉ ra lỗi ở trên - như Wikipedia cũng chỉ ra, automata đẩy xuống mạnh hơn máy trạng thái hữu hạn, nhưng kém mạnh hơn máy Turing.

Thực sự tôi không biết nơi rắm não này đến từ - Tôi làm biết rằng bối cảnh văn phạm tiếng nhạy cảm là mạnh mẽ hơn bối cảnh tự do, và đó là bối cảnh văn phạm tiếng nhạy cảm không thể được phân tích bằng máy tự động đẩy xuống đơn giản. Tôi thậm chí còn biết rằng mặc dù có thể phân tích bất kỳ ngữ pháp không ngữ cảnh rõ ràng nào trong thời gian tuyến tính, nhưng nó thường mất nhiều hơn một máy tự động đẩy xuống (xác định) để làm điều đó. Vì vậy, làm thế nào tôi có thể cuối cùng tin rằng một máy tự động đẩy xuống tương đương với một máy Turing là kỳ quái.

Có thể tôi đã nghĩ đến một máy tự động đẩy xuống với một số máy móc bổ sung được thêm vào, nhưng điều đó sẽ giống như đếm một máy tự động hữu hạn tương đương với máy tự động đẩy xuống (chỉ cần thêm và khai thác một ngăn xếp).

Automata đẩy xuống rất quan trọng trong phân tích cú pháp. Tôi đủ quen thuộc với chúng trong bối cảnh đó, nhưng tôi chưa bao giờ thực sự nghiên cứu chúng như các mô hình tính toán khoa học máy tính, vì vậy tôi không thể đưa ra nhiều chi tiết hơn những gì tôi đã có.

Có thể mô hình hóa một đối tượng OOP là máy trạng thái hữu hạn. Trạng thái của máy sẽ được xác định bởi trạng thái của tất cả các biến thành viên. Thông thường, bạn chỉ tính các trạng thái hợp lệ giữa các cuộc gọi phương thức (không trong thời gian). Một lần nữa, nhìn chung bạn sẽ có rất nhiều trạng thái lo lắng về việc đó là thứ gì đó bạn có thể sử dụng làm mô hình lý thuyết, nhưng bạn sẽ không muốn liệt kê tất cả các trạng thái đó, ngoại trừ trong trường hợp tầm thường.

Tuy nhiên, khá phổ biến để mô hình hóa một số khía cạnh về trạng thái của một đối tượng bằng cách sử dụng máy trạng thái hữu hạn. Một trường hợp phổ biến là AI cho các đối tượng trò chơi.

Đây cũng là những gì thường được thực hiện khi xác định trình phân tích cú pháp bằng mô hình tự động đẩy xuống. Mặc dù có một tập hợp các trạng thái hữu hạn trong một mô hình trạng thái, nhưng mô hình này chỉ là một phần trạng thái của trình phân tích cú pháp Thông tin bổ sung được lưu trữ trong các biến phụ cùng với trạng thái đó. Điều này giải quyết, ví dụ: vấn đề 4 tỷ trạng thái cho một số nguyên, không liệt kê tất cả các trạng thái đó, chỉ bao gồm biến số nguyên. Theo một nghĩa nào đó, nó vẫn là một phần của trạng thái tự động đẩy xuống, nhưng đó là một cách tiếp cận dễ quản lý hơn nhiều so với hiệu quả vẽ 4 tỷ bong bóng trạng thái trên sơ đồ.

Vấn đề không phải là một cái gì đó "là" hay "không" là một máy trạng thái hữu hạn. Một bộ máy trạng thái hữu hạn là một mô hình tinh thần có thể hữu ích để hiểu một cái gì đó nếu thứ đó có thể được coi là một.

Thông thường, mô hình máy trạng thái hữu hạn áp dụng cho những thứ có số lượng trạng thái nhỏ, chẳng hạn như ngữ pháp thông thường hoặc trình tự hướng dẫn của máy tính.

Để trả lời câu hỏi của bạn trực tiếp: gần như chắc chắn là không. Dường như không có một lý thuyết toán học chính thức nào cho OOP theo cách mà lambda tính toán và / hoặc Logic kết hợp lập trình dưới chức năng, hoặc Turing Machines theo chương trình mệnh lệnh cũ thông thường.

Xem câu hỏi stackoverflow này để biết thêm.

Tôi đoán là việc thiếu một lý thuyết toán học cơ bản là lý do tại sao mọi người đều biết "đối tượng" là gì khi họ nhìn thấy, nhưng không ai thấy "đối tượng" hoàn toàn giống với bất kỳ ai khác.

Không, dù sao cũng không thực tế. Một máy trạng thái hữu hạn thường chỉ ghi nhớ một phần dữ liệu: trạng thái hiện tại của nó.

Một ứng dụng điển hình của một FSM là lexing hoặc phân tích cú pháp. Ví dụ: khi chúng tôi thực hiện lexing, (thông thường) khá dễ dàng để mã hóa các hành động cho mọi đầu vào có thể theo trạng thái hiện tại và giá trị của đầu vào.

Ví dụ: chúng ta có thể có trạng thái SỐ trong đó chúng ta đang đọc các chữ số của một số. Nếu ký tự tiếp theo chúng ta đọc là một chữ số, chúng ta sẽ ở trạng thái SỐ. Nếu đó là dấu cách hoặc tab, chúng tôi sẽ trả về các chữ số và sau đó chuyển sang trạng thái WHITEinksACE hoặc thứ gì đó theo thứ tự đó.

Bây giờ, chắc chắn đúng là trong một FSM điển hình (đặc biệt là một phần mềm được triển khai trong phần mềm), chúng tôi kết thúc với các bit và phần mà về mặt kỹ thuật không hoàn toàn phù hợp với một FSM được trộn lẫn với chính FSM. Ví dụ: khi chúng ta đọc các chữ số của một số, bạn sẽ thường xuyên lưu vị trí của chữ số đầu tiên, vì vậy khi bạn đi đến cuối, bạn có thể dễ dàng tính giá trị của số đó.

Bản thân FSM, có một số hạn chế - nó không có cơ chế đếm. Ví dụ, hãy xem xét một ngôn ngữ sử dụng "/ " để bắt đầu nhận xét và " /" để kết thúc nhận xét. Từ vựng của nó có thể sẽ có trạng thái COMMENT mà nó đã nhập khi nhìn thấy mã thông báo ' / '. Tại thời điểm này, không có cách nào (thiếu thêm một trạng thái khác như COMMENT2) để phát hiện "/ " khác và nhận ra rằng nó đang xử lý một nhận xét lồng nhau. Thay vào đó, ở trạng thái bình luận, nó sẽ nhận ra */là bảo nó rời khỏi trạng thái bình luận và bất cứ điều gì khác để nó ở trạng thái bình luận.

Như đã đề cập, bạn chắc chắn có thể bao gồm trạng thái COMMENT2 cho một nhận xét lồng nhau - và trong đó, trạng thái COMMENT3, v.v. Tuy nhiên, tại một số điểm, bạn sẽ phát ốm khi thêm nhiều trạng thái và điều đó sẽ xác định độ sâu lồng tối đa mà bạn cho phép nhận xét. Với một số dạng trình phân tích cú pháp khác (nghĩa là không phải là một máy trạng thái thuần túy, nhưng một cái gì đó có bộ nhớ để cho phép đếm), bạn chỉ có thể theo dõi trực tiếp độ sâu lồng của mình, vì vậy bạn ở trong trạng thái COMMENT cho đến khi bạn đạt được mã thông báo gần đó cân bằng cái đầu tiên, vì vậy bộ đếm của bạn trở về 0 và bạn rời khỏi trạng thái COMMENT.

Như tôi đã nói, tuy nhiên, khi bạn thêm một bộ đếm như thế, những gì bạn có không còn thực sự là một FSM. Đồng thời, nó là thực sự khá gần - đặc biệt, đủ gần mà bạn có thể mô phỏng các truy cập bởi chỉ cần thêm các quốc gia hơn.

Tuy nhiên, trong một trường hợp điển hình, khi ai đó nói về việc triển khai một FSM trong phần mềm, họ sẽ giữ nó một cách hợp lý "thuần túy". Cụ thể, phần mềm sẽ phản ứng với đầu vào hiện tại chỉ dựa trên trạng thái hiện tại và giá trị của chính đầu vào đó. Nếu phản ứng phụ thuộc vào nhiều thứ khác, họ thường sẽ không gọi nó là máy trạng thái (ít nhất là nếu họ biết họ đang nói về cái gì).

Tôi không tin câu trả lời được chấp nhận là hoàn toàn chính xác.

Bạn không thể mô hình hóa một chương trình tùy ý được viết bằng ngôn ngữ Turing Complete, cho dù đó là hướng đối tượng hay không, như một Máy trạng thái hữu hạn. Hầu như tất cả các ngôn ngữ máy tính hiện đại, như Java, C ++ hoặc Smalltalk, đều là Turing Complete.

Chẳng hạn, bạn không thể tạo Máy trạng thái hữu hạn để nhận ra một chuỗi các đối tượng trong đó bạn có n phiên bản của một đối tượng theo sau là n phiên bản của đối tượng khác vì Máy trạng thái hữu hạn không có khả năng ghi n vào một biến. Họ chỉ có thể đọc đầu vào và chuyển sang trạng thái.