2010-03-01 29 views
5

Trong vòng kết nối thiết kế ngôn ngữ, có một cuộc tranh luận kéo dài về việc liệu ngôn ngữ có nên sử dụng structural equivalence hoặc name equivalence hay không. Các ngôn ngữ như ALGOL hoặc ML hoặc Modula-3 sử dụng tương đương cấu trúc trong khi ... tốt, hầu hết các ngôn ngữ lập trình sử dụng tên tương đương (bao gồm Modula-2).Các đối số nào cho và chống lại cả hai tên tương đương và tương đương cấu trúc?

Các đối số tiêu biểu có lợi cho tương đương cấu trúc là gì? Các đối số tiêu biểu đối lập với nó là gì? Các đối số điển hình có lợi cho tương đương tên là gì? Các đối số tiêu biểu đối lập với nó là gì?

+0

Liên kết Wikipedia: http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Nominative_type_system –

+0

Điều này cho tôi biết chúng là gì. Tôi đã biết điều này, là một người sử dụng, tốt, rất nhiều ngôn ngữ sử dụng các biến thể của cả hai loại. Những trang đó không cho tôi biết những gì các đối số được sử dụng để hỗ trợ mỗi bên và xé xuống phía bên kia. –

+0

Vâng, tôi chỉ cung cấp liên kết vì lợi ích của những người đọc không biết câu hỏi là gì. Có lẽ tôi nên thay đổi câu hỏi. –

Trả lời

6

Tôi nghĩ rằng lợi thế của các hệ thống kiểu cấu trúc là chúng khuyến khích bạn tạo các giao diện chi tiết theo hướng mà người dùng giao diện cần, thay vì những gì người triển khai cung cấp.

Trong hệ thống kiểu đề cử, bạn cần một sự phụ thuộc chung trên giao diện. Trong một hệ thống kiểu cấu trúc mà yêu cầu được loại bỏ: bạn có thể xây dựng một hệ thống ghép đôi lỏng lẻo mà không cần phải tạo ra thư viện chung mà bạn đặt tất cả các giao diện. Mỗi khách hàng có thể độc lập khai báo giao diện mà nó mong đợi từ một cộng tác viên.

Điểm bất lợi của hệ thống kiểu cấu trúc là chúng khớp với các lớp để giao diện có thể không thực sự thực hiện đúng hợp đồng. Ví dụ: nếu bạn có giao diện này:

public interface IBananaProvider 
{ 
    /// Returns a banana, never null. 
    Banana GetBanana(); 
} 

thì lớp sau sẽ được xem xét để triển khai IBananaProvider trong hệ thống kiểu cấu trúc. Tuy nhiên, lớp vi phạm điều kiện bài đăng mà chuối đã trả lại không bao giờ là rỗng:

public class SomeBananaProvider 
{ 
    // returns a banana or null if we're all out 
    public Banana GetBanana() 
    { 
     if (bananas.Count > 0) 
     { 
      return bananas.RemoveLast(); 
     } 
     else 
     { 
      return null; 
     } 
    } 
} 

Điều này có thể được khắc phục nếu hợp đồng được quy định một cách chính thức và được coi là một phần của cấu trúc kiểu. Tôi nghĩ mọi thứ đang chuyển động theo hướng đó, ví dụ: System.Diagnostics.Contracts trong .NET 4.0.

+0

Chỉ vì mục đích làm rõ: lợi thế tương đương về cấu trúc tương tự như lợi thế gõ của vịt, nhưng yêu cầu giao diện đầy đủ phải được thực hiện nên ít linh hoạt hơn, nhưng có nhiều khả năng được gõ đúng cách? –

+1

Tôi không hiểu ý của bạn bằng cách "yêu cầu giao diện đầy đủ để được triển khai nên ít linh hoạt hơn". Kết cấu gõ cho phép bạn xác định giao diện tối thiểu tuyệt đối cho mỗi cộng tác viên, mà không cần người thực hiện cần biết tất cả các giao diện tối thiểu đó. Vì vậy, tôi muốn nói ngược lại: gõ cấu trúc loại bỏ sự cần thiết phải thực hiện các thành viên giao diện vô ích, bởi vì mỗi thành viên cần thiết là một trong đó là thực sự được sử dụng bởi khách hàng. –

+1

Trong kiểu gõ vịt nếu tôi có một "giao diện" với các phần tử A và B và tôi biết rằng một người dùng nhất định của nó chỉ truy cập AI có thể vượt qua trong "người triển khai" của giao diện đó chỉ cung cấp A (một đối tượng giả để thử nghiệm, nói) - "loại" chỉ được kiểm tra tại điểm sử dụng và chỉ cho phần tử cụ thể được sử dụng. Trong Modula-3 (một ngôn ngữ tương đương cấu trúc) tôi không thể làm điều đó. Trình biên dịch kiểm tra tĩnh cấu trúc tương đương vì vậy tôi không thể chuyển vào một cái gì đó cung cấp một tập con của chức năng ngay cả khi tôi biết rằng một ứng dụng cụ thể (hoặc một phần của nó) chỉ sử dụng tập hợp con đó. –

3

Một đối số thích hợp với tên tương đương nghiêm ngặt (như có sẵn trong Ada chẳng hạn) là nó làm cho trình biên dịch có thể từ chối mã vô tình trộn các đơn vị khác nhau, ví dụ như cm và inch, hoặc c và f .

Trong một ngôn ngữ với tên nghiêm ngặt tương đương bạn có thể có hai loại

type celsius based on float; 
type fahrenheit based on float; 

var c : celsius; var f : fahrenheit; 

c := f; /* compile time error: incompatible types */ 

Trong khi, bằng một ngôn ngữ với tên mất tương đương và trong một với tính tương đương về cấu trúc ...

type celsius is float; 
type fahrenheit is float; 

c := f; /* no error and no warning here */ 

.. bạn sẽ kết thúc với một tính toán sai lầm sẽ dẫn đến hành vi không thể đoán trước, tùy thuộc vào loại ứng dụng và hệ thống này có thể dẫn đến mất mát tài chính nghiêm trọng hoặc thậm chí tử vong. Một lỗi logic như vậy cũng rất khó để theo dõi mà không có tên tương đương nghiêm ngặt tại chỗ.

+2

Vì vậy, bạn đang nói NASA sẽ thích tương đương tên nghiêm ngặt? ;) –

+0

Đối với NASA, có phải là trường hợp của một sứ mệnh để Venus nơi tàu vũ trụ đã mất vì km và dặm nơi lẫn lộn. Nếu phần mềm đó được viết bằng một ngôn ngữ có tên tương đương nghiêm ngặt, thì đúng vậy, lỗi này sẽ bị bắt vào thời gian biên dịch. – trijezdci

Các vấn đề liên quan