lớp trong ngôn ngữ OOP và loại

Trong lý thuyết ngôn ngữ lập trình, một loại là một tập hợp các giá trị. Ví dụ, kiểu "int" là tập hợp của tất cả các giá trị nguyên.

Trong các ngôn ngữ OOP, một lớp là một loại, phải không?

Khi một lớp được định nghĩa có nhiều thành viên, vd

class myclass{
    int a; 
    double b;
}

Khi chúng ta nói về một lớp học, chúng ta có nghĩa là

• " (a,b)trong đó alà một int và blà một đôi", hoặc
• "{ (x,y)| xlà bất kỳ int, ylà bất kỳ gấp đôi}"?

Một ví dụ myclasscó nghĩa là gì?

• " (a,b)trong đó alà một int và blà một đôi", hoặc
• một đối tượng chiếm một không gian bộ nhớ và có thể (không nhất thiết, có thể trống) (x,y), nơi xnào có int và ycó bất kỳ gấp đôi không?

Cũng không.

Tôi hỏi bạn đang hỏi liệu có cùng một loại trường trường có đủ để phân loại là cùng một lớp hay không hoặc chúng có phải được đặt tên giống hệt không. Câu trả lời là: "Thậm chí không có cùng loại và cùng tên là đủ!" Các lớp tương đương về cấu trúc không nhất thiết phải tương thích kiểu.

Ví dụ: nếu bạn có một CartesianCoordinatesvà một PolarCordinateslớp, cả hai có thể có hai số là các trường của chúng và thậm chí chúng có thể có cùng Numberloại và cùng tên, nhưng chúng vẫn không tương thích và một trường hợp PolarCoordinatessẽ không phải là một thể hiện của CartesianCoordinates. Khả năng phân tách các loại theo mục đích dự định của chúng và không phải là triển khai hiện tại của chúng là một phần rất hữu ích để viết mã an toàn hơn, dễ bảo trì hơn.

Các loại không phải là bộ.

Bạn thấy, lý thuyết tập hợp có một số tính năng đơn giản là không áp dụng cho các loại và ngược lại . Chẳng hạn, một đối tượng có một kiểu chính tắc duy nhất. Nó có thể là một thể hiện của một số loại khác nhau, nhưng chỉ một trong những loại đó được sử dụng để khởi tạo nó. Lý thuyết tập hợp không có khái niệm về tập hợp "chính tắc".

Lý thuyết tập hợp cho phép bạn tạo các tập hợp con một cách nhanh chóng , nếu bạn có một quy tắc mô tả những gì thuộc về tập hợp con. Lý thuyết loại thường không cho phép điều này. Mặc dù hầu hết các ngôn ngữ có một Numberloại hoặc một cái gì đó tương tự, chúng không có một EvenNumberloại, cũng không đơn giản để tạo ra một loại. Ý tôi là, nó đủ dễ để tự xác định loại, nhưng bất kỳ Numbers nào hiện có thậm chí sẽ không được chuyển đổi một cách kỳ diệu thành EvenNumbers.

Trên thực tế, việc nói rằng bạn có thể "tạo ra" các tập hợp con có phần không rõ ràng, bởi vì bộ là một loại động vật hoàn toàn khác. Trong lý thuyết tập hợp, những tập hợp con đó đã tồn tại , theo tất cả các cách vô hạn mà bạn có thể định nghĩa chúng. Trong lý thuyết loại, chúng ta thường mong đợi được xử lý một số loại hữu hạn (nếu lớn) tại bất kỳ thời điểm nào. Các loại duy nhất được cho là tồn tại là những loại chúng tôi thực sự đã xác định, không phải mọi loại chúng tôi có thể xác định.

Các bộ không được phép chứa trực tiếp hoặc gián tiếp . Một số ngôn ngữ, chẳng hạn như Python, cung cấp các loại có cấu trúc ít thông thường hơn (trong Python, typeloại chính tắc là typevà objectđược coi là một thể hiện của object). Mặt khác, hầu hết các ngôn ngữ không cho phép các loại do người dùng xác định tham gia vào loại mánh khóe này.

Các bộ thường được phép chồng lên nhau mà không được chứa trong nhau. Điều này không phổ biến trong lý thuyết loại, mặc dù một số ngôn ngữ hỗ trợ nó dưới dạng đa thừa kế. Các ngôn ngữ khác, chẳng hạn như Java, chỉ cho phép một hình thức hạn chế này hoặc không cho phép hoàn toàn.

Loại trống tồn tại (nó được gọi là loại dưới cùng ), nhưng hầu hết các ngôn ngữ không hỗ trợ nó, hoặc không coi nó là loại hạng nhất. "Loại chứa tất cả các loại khác" cũng tồn tại (nó được gọi là loại hàng đầu ) và được hỗ trợ rộng rãi, không giống như lý thuyết tập hợp.

Lưu ý : Như một số nhà bình luận trước đây đã chỉ ra (trước khi chủ đề được chuyển sang trò chuyện), có thể mô hình hóa các loại với lý thuyết tập hợp và các cấu trúc toán học tiêu chuẩn khác. Chẳng hạn, bạn có thể mô hình thành viên kiểu như một mối quan hệ thay vì mô hình hóa thành các tập hợp. Nhưng trong thực tế, điều này đơn giản hơn nhiều nếu bạn sử dụng lý thuyết thể loại thay vì lý thuyết tập hợp. Đây là cách Haskell mô hình lý thuyết loại của nó, ví dụ.

Khái niệm "phân nhóm" thực sự khá khác biệt với khái niệm "tập hợp con". Nếu Xlà một kiểu con của Ynó, điều đó có nghĩa là chúng ta có thể thay thế các thể hiện của Ycác trường hợp Xvà chương trình vẫn sẽ "hoạt động" theo một nghĩa nào đó. Đây là hành vi chứ không phải cấu trúc, mặc dù một số ngôn ngữ (ví dụ: Go, Rust, được cho là C) đã chọn ngôn ngữ sau vì lý do thuận tiện, cho người lập trình hoặc thực hiện ngôn ngữ.

Các loại dữ liệu đại số là cách để thảo luận về điều này.

Có ba cách cơ bản bạn có thể kết hợp các loại:

• Sản phẩm. Về cơ bản đó là những gì bạn nghĩ về:

  struct IntXDouble{
    int a; 
    double b;
  }
  

  là một loại sản phẩm; giá trị của nó là tất cả các kết hợp có thể (ví dụ: bộ dữ liệu) của một intvà một double. Nếu bạn coi các loại số là tập hợp, thì tính chính xác của loại sản phẩm trên thực tế là sản phẩm của các yếu tố chính của các trường.

• Tổng. Trong các ngôn ngữ thủ tục, điều này hơi khó để diễn đạt trực tiếp (theo cách cổ điển, nó được thực hiện với các hiệp hội được gắn thẻ ), vì vậy để hiểu rõ hơn, đây là một loại tổng trong Haskell:

  data IntOrDouble = AnInt Int
                   | ADouble Double
  

  các giá trị của loại này có dạng AnInt 345, hoặc ADouble 4.23, nhưng luôn chỉ có một số liên quan (không giống với loại sản phẩm, trong đó mỗi giá trị có hai số). Vì vậy, cardinality: trước tiên bạn liệt kê tất cả các Intgiá trị, mỗi giá trị phải được kết hợp với hàm AnInttạo. Cộng , tất cả các Doublegiá trị, mỗi giá trị kết hợp với ADouble. Do đó tổng loại .

• Lũy thừa ¹ . Tôi sẽ không thảo luận chi tiết về vấn đề này ở đây vì nó không có sự tương ứng rõ ràng nào cả.

Vậy còn lớp học thì sao? Tôi cố tình sử dụng từ khóa structchứ không phải classcho IntXDouble. Vấn đề là, một lớp dưới dạng không thực sự được đặc trưng bởi các trường của nó, chúng chỉ là các chi tiết triển khai. Yếu tố cốt yếu là, lớp có thể có những giá trị phân biệt nào.

Điều có liên quan là, giá trị của một lớp có thể là giá trị của bất kỳ lớp con nào của nó ! Vì vậy, một lớp thực sự là một loại tổng chứ không phải là một loại sản phẩm: nếu Avà Bcả hai đều có nguồn gốc từ myClass, về myClasscơ bản sẽ là tổng của Avà B. Bất kể thực hiện thực tế.

¹ _{Đây là hàm (theo nghĩa toán học! ); một loại hàm Int -> Doubleđược biểu diễn theo cấp số nhân Double^Int. Thật tệ nếu ngôn ngữ của bạn không có chức năng phù hợp ...}

Xin lỗi nhưng tôi không biết về lý thuyết "thô". Tôi chỉ có thể cung cấp một cách tiếp cận thực tế. Tôi hy vọng điều này được chấp nhận tại các lập trình viên. E; Tôi không quen thuộc với nghi thức ở đây.

Một chủ đề trung tâm của OOP là ẩn thông tin . Chính xác thì các thành viên dữ liệu của một lớp sẽ không được khách hàng quan tâm. Một khách hàng gửi tin nhắn đến (gọi các phương thức / hàm thành viên của) một thể hiện, có thể hoặc không thể sửa đổi trạng thái bên trong. Ý tưởng là các phần bên trong của một lớp có thể thay đổi, mà không có khách hàng bị ảnh hưởng bởi nó.

Một điều đáng mừng cho điều này là lớp có trách nhiệm đảm bảo rằng đại diện bên trong của nó vẫn "hợp lệ". Giả sử một lớp lưu trữ số điện thoại (đơn giản hóa) theo hai số nguyên:

    int areacode;
    int number;

Đây là những thành viên dữ liệu của lớp. Tuy nhiên, lớp có lẽ sẽ nhiều hơn so với chỉ các thành viên dữ liệu của nó, và nó chắc chắn là không thể xác định được là "tập hợp tất cả các giá trị có thể có của int x int". Bạn không nên truy cập trực tiếp vào các thành viên dữ liệu.

Xây dựng một thể hiện có thể từ chối bất kỳ số âm. Có lẽ việc xây dựng cũng sẽ bình thường hóa mã vùng theo một cách nào đó, hoặc thậm chí xác minh toàn bộ số. Do đó, bạn sẽ kết thúc gần hơn với bạn "(a,b) where a is an int and b is a double", bởi vì đó chắc chắn không phải là bất kỳ hai int nào được lưu trữ trong lớp đó.

Nhưng điều đó không thực sự quan trọng đối với lớp học. Nó không phải là kiểu của các thành viên dữ liệu, cũng không phải là phạm vi của các giá trị có thể có của chúng xác định lớp, đó là các phương thức được định nghĩa cho nó.

Miễn là các phương thức đó vẫn giữ nguyên, người triển khai có thể thay đổi các kiểu dữ liệu thành dấu phẩy động, BIGNUM, chuỗi, bất cứ điều gì và cho tất cả các mục đích thực tế, nó vẫn sẽ là cùng một lớp .

Có các patters thiết kế để đảm bảo rằng những thay đổi của biểu diễn bên trong có thể được thực hiện mà không cần khách hàng biết về nó (ví dụ: thành ngữ pimpl trong C ++, ẩn bất kỳ thành viên dữ liệu nào phía sau một con trỏ mờ ).

• Một loại là một mô tả về một loại / phạm vi của các giá trị, cấu trúc ghép hoặc những gì có bạn. OOPwise, nó giống như một "giao diện". (Trong ý nghĩa ngôn ngữ-agnostic. Ý nghĩa ngôn ngữ cụ thể, không quá nhiều. Trong Java, ví dụ, intlà một loại , nhưng không có liên quan đến một interface. Cộng / thông số kỹ thuật lĩnh vực bảo vệ, cũng như, không phải là một phần của một interface, nhưng là một phần của "giao diện" hoặc loại .)

  Điểm chính là, đó là một định nghĩa ngữ nghĩa nhiều hơn là một định nghĩa cụ thể. Cấu trúc chỉ các yếu tố trong inasmuch như các lĩnh vực / hành vi tiếp xúc và mục đích xác định của chúng phù hợp với nhau. Nếu bạn không có cả hai, bạn không có khả năng tương thích.

• Một lớp là sự hiện thực hóa của một loại. Đó là một mẫu thực sự xác định cấu trúc bên trong, hành vi đính kèm, v.v.