Định nghĩa chính thức cho thuật ngữ ngôn ngữ OO thuần túy

Tôi không thể nghĩ ra một nơi tốt hơn trong số các anh chị em SO để đặt ra một câu hỏi như vậy. Ban đầu tôi muốn hỏi "Con trăn có phải là ngôn ngữ OO thuần túy không?" nhưng xem xét những rắc rối và một số loại khó chịu mà mọi người gặp phải trong khi cố gắng xác định thuật ngữ tôi quyết định bắt đầu với việc có được một định nghĩa rõ ràng cho chính thuật ngữ đó.

Sẽ khá công bằng khi bắt đầu với sự tương ứng của Tiến sĩ Alan Kay, người đã đặt ra thuật ngữ này (lưu ý nguồn cảm hứng trong tương tự sinh học với các tế bào hoặc các vật thể sống khác).

Có các cách sau để tiếp cận nhiệm vụ:

1. Đưa ra một phân tích so sánh bằng cách liệt kê các ngôn ngữ lập trình có thể thể hiện (hoặc không làm như vậy) một số thuộc tính duy nhất và đủ để xác định thuật ngữ (mặc dù Smalltalk, Scala, Java , v.v. - là những ví dụ khả thi nhưng IMO theo cách này dường như không thực sự hoàn chỉnh cũng không có kết quả )
2. Đưa ra một định nghĩa chính thức (hoặc gần với nó, ví dụ như trong phong cách học thuật hoặc toán học hơn).
3. Đưa ra một định nghĩa triết học hoàn toàn dựa vào bối cảnh ngữ nghĩa của ngôn ngữ cụ thể hoặc kinh nghiệm lập trình tiên nghiệm (phải có một số cơ hội giải thích thành công bởi cộng đồng).

Phiên bản hiện tại của tôi: "Nếu một ngôn ngữ lập trình ( chính thức ) nhất định có thể ( về mặt ngữ pháp ) phân biệt giữa các hoạt động và toán hạng cũng như suy luận về loại của mỗi toán hạng cho dù loại này có phải là một đối tượng (theo nghĩa của OOP) hay không thì chúng ta gọi ngôn ngữ đó là ngôn ngữ OO miễn là có ít nhất một loại trong ngôn ngữ này là đối tượng. Cuối cùng, nếu tất cả các loại ngôn ngữ cũng là đối tượng, chúng tôi xác định ngôn ngữ đó là ngôn ngữ OO thuần túy (mạnh). "

Sẽ đánh giá cao bất kỳ cải thiện có thể của nó. Như bạn có thể thấy tôi chỉ đưa ra định nghĩa phụ thuộc vào thuật ngữ "đối tượng" (thường được tham chiếu đầy đủ dưới dạng lớp đối tượng).

[BIÊN TẬP]

Ngoài ra, tôi sử dụng khái niệm (rất may là hiểu rõ) về một loại như trong các ngôn ngữ đánh máy. Lập trình kiểu dữ liệu hoặc lập trình hướng loại không chỉ là một cách hiểu cú pháp (của văn bản chương trình, tức là làm thế nào để xử lý một số giá trị nhất định của các biến và dữ liệu - một thứ phát triển thành an toàn kiểu) mà có thể được quy cho ngữ pháp ngôn ngữ và được nghiên cứu theo cách chính thức (sử dụng logic toán học) như được gọi là hệ thống loại . Lưu ý rằng việc yêu cầu hệ thống loại cụ thể phải có loại gọi là phổ quát là một trong những cách xác định độ tinh khiết của ngôn ngữ OO (có nhiều cách để mở rộng ngữ nghĩa này).

Lưu ý

cách trả lời :

• nó giúp nếu bạn chỉ định một cuốn sách hoặc một tài liệu tham khảo hỗ trợ / giải thích sự hiểu biết của bạn về thuật ngữ và khái niệm (thường là một định nghĩa tốt bao gồm hoặc tham chiếu tất cả các khái niệm phụ thuộc ngoại trừ cơ bản).
• nếu có thể chỉ ra một loại thụt lề của câu trả lời / định nghĩa của bạn nếu nó không rõ ràng (xem ở trên: 1 - bằng ví dụ ngôn ngữ, 2 - logic toán học, 3 - mô tả kỹ thuật và triết lý lập trình)
• phân loại rất quan trọng (và cũng vì thuật ngữ OO thuần túy được bao gồm trong thuật ngữ OO) trong khi trả lời cố gắng trộn các phần tử của mô hình OO từ các phương pháp nổi tiếng khác (và không có nghĩa là nhầm lẫn / chồng chéo chúng, ví dụ như các yếu tố của lập trình mô đun có thể được đề cập / hiện thân với lập trình OO): cố gắng phân biệt OOP với (bao gồm hoặc là một phần của) Lập trình chức năng, lập trình logic (đặc biệt mạnh), Kiểu dữ liệu Abstarct (ADT), Modular, Metaprogramming (khái quát và thời gian mở rộng vĩ mô của LISP), Hợp đồng (ví dụ Eiffel), định hướng theo khía cạnh (AO), (sự khác biệt giữa phân loại khai báo và chức năng cũng như các định nghĩa lịch sử về cấu trúc của Dijkstra là rõ ràng)

về khó khăn trong việc đưa ra một định nghĩa chính thức : thật đáng ngạc nhiên, rất dễ dàng để đưa ra một mô tả toán học về OOP dưới dạng một hệ thống logic (chính thức) nhất định (rất có thể dựa trên loại) và xác định khái niệm này theo khái niệm khác. Người ta thậm chí có thể cố gắng làm một cái gì đó thực tế hơn bằng cách áp dụng chủ nghĩa hình thức đó để kiểm tra an toàn hoặc các khía cạnh thiết kế ngôn ngữ mới thay vì chỉ giải trí hoặc tập thể dụctrừu tượng(cũng là công thức tra cứu OOP trong Lý thuyết loại trực giác , các loại phụ thuộc , độc lập, trong hình thức FOL như tính toán lambda và chỉ bằng cách sử dụng lý thuyết thể loại). Một điểm chính ở đây là không ngạc nhiênCác công thức như vậy IMO bị thiên vị mạnh mẽ (thiếu sót) bởi sự hiểu biết ban đầu không đầy đủ về OOP (trong kỹ thuật máy tính) và cuối cùng gần như không thể truy cập được (do đó hầu như không đóng góp ngược vào thế giới lập trình - có thể ngoại trừ một số phần trăm tìm thấy các ứng dụng từ thế giới chính thức tích hợp vào các ngôn ngữ phổ biến ).

Vì vậy, có, rất khó để đưa ra một định nghĩa "tốt", không chỉ là định nghĩa. Nhưng tôi tích cực khi hỏi điều này ở đây vì kinh nghiệm và sự tham gia trực tiếp của bạn, các bạn.

OO, theo Alan Kay là tất cả về thông điệp truyền qua, và đó là nó. Bạn sẽ thấy rằng những phẩm chất như đa hình và đóng gói thực sự bắt nguồn từ việc truyền thông điệp.

Bây giờ lập trường đó thực tế là rất cực đoan, bởi vì về cơ bản, điều đó có nghĩa là chỉ có Smalltalk và các ngôn ngữ giống nhau mới đủ điều kiện.

Tôi nghĩ rằng bạn có thể định nghĩa OO là xây dựng hệ thống của mình trên các thực thể, đóng gói hoàn toàn trạng thái của chúng và được hiển thị có thể trao đổi do các phẩm chất đa hình vốn có của chúng. Do đó, người ta có thể tranh luận một ngôn ngữ OO thuần túy đảm bảo hai phẩm chất cốt lõi này luôn được đáp ứng. Điều làm cho các ngôn ngữ OO "không trong sạch" sẽ là các cơ chế cho phép tạo ra các cấu trúc không đáp ứng các tiêu chí này, chẳng hạn như các khả năng:

• khai báo các lĩnh vực công cộng
• khai báo các biến chỉ có thể chứa các thể hiện của một lớp cụ thể và các lớp con của nó (tức là các biến nên được gõ vào các giao diện, đó là những gì các đối tượng sinh học giao tiếp trong anology của Kay), được kết xuất thậm chí hẹp hơn nếu lớp trong câu hỏi là cuối cùng, như mà thậm chí còn ít chỗ cho đa hình
• khai báo nguyên thủy

Sau đó, một lần nữa, độ tinh khiết ngôn ngữ IMHO là một điểm yếu hơn là một điểm mạnh. OO không phải là viên đạn bạc. Không có mô hình duy nhất là.

Tôi sẽ tiếp cận điều này bằng cách định nghĩa nó là ngôn ngữ sử dụng các cấu trúc OOP và không có gì khác (giống như cách mà ngôn ngữ FP thuần túy sử dụng các hàm thuần túy với dữ liệu bất biến và không có gì khác).

Đặc biệt:

• Mỗi thực thể mà chương trình của bạn hoạt động là một Đối tượng hạng nhất - tức là không có nguyên hàm, không có con trỏ, không có mảng, v.v.
• Điều duy nhất bạn có thể làm với một đối tượng là gọi một phương thức (có khả năng đa hình) trên nó (== gửi tin nhắn). Không có hoạt động khác tồn tại.
• Tất cả dữ liệu được gói gọn - tức là không có quyền truy cập trường công cộng, bạn phải thông qua các phương thức trên một đối tượng
• Nếu bạn có các hàm hạng nhất thì chúng cũng phải là các đối tượng - vì vậy bạn sẽ cần phải làm một cái gì đó nhưfunctionObject.call(param1,param2)
• Không có biến toàn cục - nếu bạn muốn một cái gì đó như thế này, bạn sẽ cần sử dụng một đối tượng để thể hiện môi trường toàn cầu hiện tại, ví dụ environment.getValue("myThing")hoặc đặt biến trong một đối tượng lớp

Lưu ý rằng điều này vẫn còn khá nhiều tùy chọn mở:

• Các mô hình đối tượng dựa trên lớp so với nguyên mẫu
• Kế thừa được thực hiện như thế nào (nếu có)
• Cho dù bạn có một hoặc nhiều công văn trên các phương thức
• Cho dù các đối tượng của bạn được gõ tĩnh hay động
• Cú pháp chính xác được sử dụng cho các cuộc gọi phương thức (ví dụ: bạn có thể có một số đường cú pháp cho getters / setters, v.v.)

Các cuộc thảo luận về cái gọi là ngôn ngữ OO luôn luôn có một chút về phía não bộ. I E:

"Ai đó đã nói với tôi rằng ngôn ngữ X là OO, do đó, ngôn ngữ X bằng OO, mọi ngôn ngữ thiếu các tính năng của ngôn ngữ X không thể là OO. Và vì tôi đang viết mã của mình bằng ngôn ngữ X, mọi thứ tôi làm là OO. "

Thuật ngữ thiết kế hướng đối tượng có đến 3 điều:

1. Thiết kế mô-đun với các đối tượng tự trị không biết thông tin không cần thiết về phần còn lại của chương trình, còn gọi là khớp nối càng lỏng càng tốt.
2. Đóng gói dữ liệu bên trong các đối tượng để ngăn chặn truy cập bên ngoài, cả cố ý và vô tình.
3. Rõ ràng phụ thuộc quy định giữa các đối tượng. Để đạt được khớp nối lỏng lẻo, nhưng cũng để làm cho chương trình dễ dàng hơn để duy trì và mở rộng.

1) là thiết kế chương trình thuần túy, nó có thể đạt được trong bất kỳ ngôn ngữ lập trình nào. Tuy nhiên, một số ngôn ngữ có các tính năng hữu ích như lớp / struct và từ khóa riêng.

2) chủ yếu là thiết kế chương trình, mặc dù không thể đạt được hoàn toàn nếu không có hỗ trợ ngôn ngữ, vì bạn cần các cơ chế ngôn ngữ như private / static để bảo vệ chống lại việc sử dụng ngẫu nhiên.

3) chủ yếu là thiết kế chương trình. Thông thường có ba phụ thuộc khác nhau: "đối tượng X chứa đối tượng Y", "đối tượng X là một loại Y" và "đối tượng X tương tác với đối tượng Y". Có rất nhiều tính năng ngôn ngữ để trợ giúp với các phụ thuộc này: kế thừa / đa hình, các lớp cơ sở trừu tượng, v.v.

Bây giờ, nếu chúng ta nhìn vào phần trên, chúng ta có thể thấy rằng bạn hầu như không cần bất kỳ tính năng ngôn ngữ nào để viết chương trình OO. Các tính năng chỉ làm cho nó dễ dàng hơn nhiều.

Các mục tiêu trên không thể đạt được bằng cách sử dụng một số logic ngược bùn: chỉ vì bạn sử dụng từ khóa lớp, chương trình của bạn không tự động có được một thiết kế mô-đun. Chỉ vì bạn sử dụng tính kế thừa, nó không tự động có nghĩa là các phụ thuộc đối tượng của bạn có ý nghĩa. Một ngôn ngữ có các tính năng OO vẫn sẽ cho phép những thứ như class TheWholeBloodyProgramhoặc "Động vật được thừa hưởng Cat".

Đáng buồn thay, chủ đề thiết kế chương trình hướng đối tượng tốt hiếm khi được đề cập trong các loại thảo luận này. Các lập trình viên bị tẩy não chỉ nhìn vào cú pháp và yap những thứ như ví dụ "C ++ có các kiểu dữ liệu nguyên thủy để chương trình C ++ của bạn không phải là OO", sau đó họ rời đi để viết một chương trình khủng khiếp hết sức bằng ngôn ngữ yêu thích của họ, mà không sử dụng bất kỳ gợi ý nào về chương trình thiết kế những gì đã từng có.

Để trả lời câu hỏi: rất ít, nếu có bất kỳ ngôn ngữ nào có hỗ trợ cho thiết kế chương trình OO thích hợp. Để tìm ra ngôn ngữ nào có các tính năng liên quan đến OO nhất định là không liên quan miễn là lập trình viên không biết thiết kế hướng đối tượng có nghĩa là gì. Một lập trình viên tuyên bố rằng một số ngôn ngữ nhất định hướng đối tượng hầu như không nắm bắt được khái niệm OO nói chung. Hỏi người lập trình OO sẽ làm thế nào họ thiết kế chương trình OO. Nếu điều đầu tiên họ làm là bắt đầu la hét các từ khóa ngôn ngữ, thì bạn có thể cho rằng họ không biết thiết kế OO một cách an toàn.

Có lẽ tồn tại một số công cụ UML-ish mức cao lạ mắt vượt xa mã nguồn thô, điều này buộc người lập trình chỉ viết các chương trình có thiết kế hướng đối tượng tốt, nhưng tôi nghi ngờ điều đó. Các công cụ thiết kế tốt nhất để lập trình OO rất có thể vẫn là bộ não con người và lẽ thường.

Không, không có định nghĩa chính thức hoặc thậm chí hữu ích, và sẽ không bao giờ có. Đối với một số người, OOP có nghĩa là "Lớp cơ sở phổ quát" và "Phải sử dụng ngữ nghĩa tham chiếu, tốt nhất với trình thu gom rác" - và bạn thậm chí có thể hiểu được cú pháp về cú pháp, một trong những điều ít liên quan nhất từng được phát minh.

Cuối cùng, trước tiên, bạn phải trả lời câu hỏi "Vật thể là gì?". Những người có đầu óc hẹp hòi hơn sẽ khăng khăng kế thừa từ một số lớp cơ sở phổ quát vô nghĩa và không cần thiết phải được phân bổ vào một công cụ thu gom rác để đủ điều kiện. Nhưng tôi thích một định nghĩa hữu ích hơn nhiều. Mục đích của OOP là có một số dữ liệu và một số chức năng bạn có thể gọi trên dữ liệu đó. Vì thế

• Một đối tượng giữ một số trạng thái và cung cấp một số chức năng trên trạng thái đó.

Trong trường hợp này, thậm chí intđủ điều kiện. Xét cho cùng, khi bạn viết mã mẫu trong C ++ có thể chấp nhận cả nguyên thủy hoặc đối tượng, thì sẽ khó có thể tranh luận rằng các nguyên thủy khác nhau theo bất kỳ cách đáng kể nào. Không có gì khác biệt về ý nghĩa Vector v1, v2; v1 + v2;thay vì int v1, v2; v1 + v2;(ngoại trừ ngữ nghĩa khởi tạo nhảm nhí, người ta phải thừa nhận). Ngoài ra, điều này cho phép lambdas và những thứ như vậy trở thành đối tượng, khi chúng giữ trạng thái - bắt giữ chúng - và cung cấp một chức năng trên trạng thái đó, để gọi lambda.

May mắn thay, chúng ta cũng có thể phân loại các con trỏ tới các hàm miễn phí dưới dạng các đối tượng, vì cả hai đều giữ trạng thái (một địa chỉ) và một hàm trên trạng thái đó (để gọi nó). Vì vậy, một chức năng miễn phí nên được cho phép - ngay cả khi bạn muốn nói rằng tất cả các chức năng miễn phí trên thực tế là con trỏ hàm toàn cầu.

Bạn có thể nghĩ về nó bằng ví dụ tiêu cực. Java không phải là ngôn ngữ hướng đối tượng thuần túy vì cũng có những kiểu nguyên thủy không phải là đối tượng. Đây là số nguyên, đôi, mảng và như vậy. Trong một ngôn ngữ đối tượng thuần túy, ngữ nghĩa của các đối tượng có sẵn cho tất cả mọi thứ.

Ngoài ra còn có câu hỏi bao nhiêu ngôn ngữ được đóng lại để sửa đổi, ngay cả trong khung đối tượng. Trong java, bạn không thể định nghĩa các lớp con mới cho một số lớp, chẳng hạn như Chuỗi hoặc Lớp.

Những ngôn ngữ là tinh khiết? Ứng cử viên duy nhất nảy ra trong đầu là smalltalk.