Những lợi ích an toàn của một hệ thống loại là gì?

Trong JavaScript: The Good Parts của Douglas Crockford, ông đề cập đến trong chương thừa kế của mình,

Lợi ích khác của kế thừa cổ điển là nó bao gồm đặc điểm kỹ thuật của một hệ thống các loại. Điều này chủ yếu giải phóng lập trình viên khỏi phải viết các hoạt động đúc rõ ràng, đây là một điều rất tốt bởi vì khi truyền, các lợi ích an toàn của một hệ thống loại bị mất.

Vì vậy, trước hết, những gì thực sự là an toàn? bảo vệ chống tham nhũng dữ liệu, hoặc tin tặc, hoặc trục trặc hệ thống, vv?

Những lợi ích an toàn của một hệ thống loại là gì? Điều gì làm cho một hệ thống loại khác nhau cho phép nó cung cấp những lợi ích an toàn này?

Loại hệ thống ngăn ngừa lỗi

Loại hệ thống loại bỏ các chương trình bất hợp pháp. Hãy xem xét mã Python sau đây.

 a = 'foo'
 b = True
 c = a / b

Trong Python, chương trình này thất bại; nó ném một ngoại lệ Trong một ngôn ngữ như Java, C #, Haskell , bất cứ điều gì, đây thậm chí không phải là một chương trình hợp pháp. Bạn hoàn toàn tránh được các lỗi này vì đơn giản là chúng không thể có trong bộ chương trình đầu vào.

Tương tự, một loại hệ thống tốt hơn quy định nhiều lỗi hơn. Nếu chúng ta nhảy lên các hệ thống loại siêu tiên tiến, chúng ta có thể nói những điều như thế này:

 Definition divide x (y : {x : integer | x /= 0}) = x / y

Bây giờ hệ thống loại đảm bảo rằng không có bất kỳ lỗi chia 0 nào.

Những loại lỗi

Dưới đây là danh sách ngắn gọn về những lỗi hệ thống có thể ngăn chặn

1. Lỗi ngoài phạm vi
2. Tiêm SQL
3. Tổng quát hóa 2, nhiều vấn đề an toàn ( kiểm tra không rõ ràng trong Perl )
4. Lỗi ngoài chuỗi (quên gọi init)
5. Buộc một tập hợp con các giá trị được sử dụng (ví dụ: chỉ các số nguyên lớn hơn 0)
6. Mèo con bất chính (Vâng, đó là một trò đùa)
7. Lỗi mất độ chính xác
8. Lỗi bộ nhớ giao dịch phần mềm (STM) (điều này cần độ tinh khiết, cũng yêu cầu các loại)
9. Tổng quát hóa 8, kiểm soát tác dụng phụ
10. Bất biến trên cấu trúc dữ liệu (cây nhị phân có cân bằng không?)
11. Quên một ngoại lệ hoặc ném sai

Và hãy nhớ rằng, đây cũng là lúc biên dịch . Không cần phải viết các bài kiểm tra với độ bao phủ mã 100% để chỉ cần kiểm tra lỗi loại, trình biên dịch chỉ làm điều đó cho bạn :)

Nghiên cứu điển hình: Đánh máy tính toán lambda

Được rồi, chúng ta hãy kiểm tra đơn giản nhất trong tất cả các hệ thống loại, chỉ cần gõ tính toán lambda .

Về cơ bản có hai loại,

Type = Unit | Type -> Type

Và tất cả các thuật ngữ là biến, lambdas hoặc ứng dụng. Dựa trên điều này, chúng tôi có thể chứng minh rằng bất kỳ chương trình đánh máy tốt nào cũng chấm dứt. Không bao giờ có tình huống chương trình sẽ bị kẹt hoặc lặp mãi mãi. Điều này không thể chứng minh được trong phép tính lambda bình thường bởi vì, điều đó không đúng.

Hãy suy nghĩ về điều này, chúng ta có thể sử dụng các hệ thống loại để đảm bảo rằng chương trình của chúng ta không lặp lại mãi mãi, khá tuyệt phải không?

Đường vòng thành các loại động

Các hệ thống kiểu động có thể cung cấp các đảm bảo giống hệt như các hệ thống kiểu tĩnh, nhưng trong thời gian chạy thay vì thời gian biên dịch. Trên thực tế, vì nó là thời gian chạy, bạn thực sự có thể cung cấp thêm thông tin. Tuy nhiên, bạn mất một số đảm bảo, đặc biệt là về các thuộc tính tĩnh như chấm dứt.

Vì vậy, các loại động không loại trừ các chương trình nhất định, mà thay vào đó định tuyến các chương trình không đúng định dạng đến các hành động được xác định rõ, như ném ngoại lệ.

TLD

Vì vậy, dài và ngắn của nó, là loại hệ thống loại trừ các chương trình nhất định. Nhiều chương trình bị hỏng theo một cách nào đó, do đó, với các hệ thống loại, chúng tôi tránh các chương trình bị hỏng này.

Thực tế là chính nó được gõ. Bạn không thể thêm chiều dài cho trọng lượng. Và trong khi bạn có thể thêm feets vào mét (cả hai đều là đơn vị độ dài), bạn nên chia tỷ lệ ít nhất một trong hai. Không làm như vậy có thể làm hỏng nhiệm vụ sao Hỏa của bạn, hoàn toàn theo nghĩa đen.

Trong một hệ thống an toàn kiểu, việc thêm hai độ dài được biểu thị bằng các đơn vị khác nhau sẽ là một lỗi hoặc sẽ gây ra tự động đúc.

Một hệ thống loại giúp bạn tránh các lỗi mã hóa đơn giản, hay nói đúng hơn là cho phép trình biên dịch bắt những lỗi đó cho bạn.

Ví dụ: trong JavaScript và Python, vấn đề sau thường sẽ chỉ được bắt gặp khi chạy - và tùy thuộc vào chất lượng kiểm tra / độ hiếm của điều kiện có thể thực sự đưa nó vào sản xuất:

if (someRareCondition)
     a = 1
else
     a = {1, 2, 3}

// 10 lines below
k = a.length

Mặc dù ngôn ngữ được gõ mạnh sẽ buộc bạn phải nêu rõ đó alà một mảng và sẽ không cho phép bạn gán một số nguyên. Bằng cách này, không có bất kỳ cơ hội asẽ không có length- ngay cả trong những trường hợp hiếm nhất.

Càng sớm trong chu trình phát triển phần mềm, bạn có thể gặp lỗi, càng ít tốn kém để sửa chữa. Xem xét một lỗi khiến khách hàng lớn nhất của bạn hoặc tất cả khách hàng của bạn bị mất dữ liệu. Một lỗi như vậy có thể là kết thúc của công ty bạn nếu nó chỉ bị bắt sau khi khách hàng thực sự bị mất dữ liệu! Rõ ràng là ít tốn kém hơn để tìm và sửa lỗi này trước khi chuyển nó sang sản xuất.

Ngay cả đối với các lỗi ít tốn kém hơn, vẫn dành nhiều thời gian và năng lượng hơn nếu người kiểm tra có liên quan hơn là nếu lập trình viên có thể tìm và sửa nó. Nó rẻ hơn nếu nó không được kiểm tra trong kiểm soát nguồn nơi các lập trình viên khác có thể xây dựng phần mềm dựa trên nó. Loại an toàn ngăn chặn một số loại lỗi nhất định ngay cả khi biên dịch, do đó loại bỏ gần như toàn bộ chi phí tiềm năng của các lỗi đó.

Nhưng đó không phải là toàn bộ câu chuyện. Như bất cứ ai lập trình bằng một ngôn ngữ động sẽ nói với bạn, đôi khi thật tuyệt nếu chương trình của bạn chỉ biên dịch để bạn có thể thử một phần của nó mà không cần phải làm từng chi tiết nhỏ. Có một sự đánh đổi giữa an toàn và thuận tiện. Các bài kiểm tra đơn vị có thể giảm thiểu một số rủi ro khi sử dụng ngôn ngữ động, nhưng viết và duy trì các bài kiểm tra đơn vị tốt có chi phí riêng có thể cao hơn so với sử dụng ngôn ngữ an toàn loại.

Nếu bạn đang thử nghiệm, nếu mã của bạn sẽ chỉ được sử dụng một lần (chẳng hạn như báo cáo một lần), nếu bạn đang ở trong tình huống bạn không muốn viết bài kiểm tra đơn vị, thì ngôn ngữ động có lẽ là hoàn hảo cho bạn. Nếu bạn có một ứng dụng lớn và muốn thay đổi một phần mà không phá vỡ phần còn lại của nó, thì loại an toàn là một trình bảo vệ cuộc sống. Các loại lỗi bắt an toàn loại chính xác là loại lỗi mà con người có xu hướng bỏ qua hoặc nhận sai khi tái cấu trúc.

Giới thiệu

An toàn loại có thể đạt được bằng các ngôn ngữ được gõ tĩnh (biên dịch, kiểm tra kiểu tĩnh) và / hoặc thời gian chạy (đánh giá, kiểm tra loại động). Theo Wikipedia , '... hệ thống loại mạnh được mô tả là một hệ thống trong đó không có khả năng xảy ra lỗi loại thời gian chạy không được kiểm tra (ed Luca Cardelli). Nói cách khác, sự vắng mặt của các lỗi thời gian chạy không được kiểm soát được gọi là an toàn hoặc loại an toàn ... '

An toàn - Kiểm tra loại tĩnh

Về mặt kinh điển, loại an toàn đã đồng nghĩa với gõ tĩnh, trong các ngôn ngữ như C, C ++ và Haskell, được thiết kế để phát hiện các loại khớp sai khi chúng được biên dịch. Điều này có lợi ích là tránh các điều kiện có khả năng không xác định hoặc dễ bị lỗi khi chương trình được thực thi. Điều này có thể là vô giá khi có nguy cơ các loại con trỏ có thể bị khớp sai, ví dụ, một tình huống có thể dẫn đến hậu quả thảm khốc nếu không được phát hiện. Theo nghĩa này, gõ tĩnh được coi là đồng nghĩa với an toàn bộ nhớ.

Gõ tĩnh không hoàn toàn an toàn nhưng tăng cường an toàn , tuy nhiên. Ngay cả các hệ thống gõ tĩnh có thể có hậu quả thảm khốc. Nhiều chuyên gia cho rằng việc gõ tĩnh có thể được sử dụng để viết các hệ thống mạnh hơn và ít bị lỗi hơn (nhiệm vụ quan trọng).

Các ngôn ngữ được nhập tĩnh có thể giúp giảm nguy cơ mất dữ liệu hoặc mất độ chính xác trong công việc số, có thể xảy ra do kết hợp sai hoặc cắt đôi đối với các kiểu tích phân và dấu phẩy khớp sai.

Có một lợi thế trong việc sử dụng các ngôn ngữ gõ tĩnh cho hiệu quả và tốc độ thực hiện. Thời gian chạy có lợi từ việc không phải xác định các loại trong khi thực hiện.

An toàn - Kiểm tra loại thời gian chạy

Erlang, ví dụ, là một loại ngôn ngữ được kiểm tra kiểu động, được kiểm tra động chạy trên một máy ảo. Mã Erlang có thể được biên dịch byte. Erlang có thể được coi là ngôn ngữ quan trọng nhất, có khả năng chịu lỗi, và được báo cáo rằng Erlang có độ tin cậy là 9 9 (99.9999999% hoặc không quá 31,5 ms mỗi năm).

Một số ngôn ngữ, chẳng hạn như Lisp thông thường, không được gõ tĩnh nhưng các loại có thể được khai báo nếu muốn có thể giúp cải thiện tốc độ và hiệu quả. Cũng cần lưu ý rằng nhiều ngôn ngữ được sử dụng rộng rãi hơn, chẳng hạn như Python, bên dưới vòng đánh giá, được viết bằng các ngôn ngữ được nhập tĩnh như C hoặc C ++. Cả Commom Lisp và Python đều được coi là loại an toàn theo định nghĩa trên.

những lợi ích an toàn của một hệ thống loại bị mất.

Vì vậy, trước hết, những gì thực sự là an toàn? bảo vệ chống tham nhũng dữ liệu, hoặc tin tặc, hoặc trục trặc hệ thống, vv?

Những lợi ích an toàn của một hệ thống loại là gì? Điều gì làm cho một hệ thống loại khác nhau cho phép nó cung cấp những lợi ích an toàn này?

Tôi cảm thấy như các hệ thống loại có một cái nhìn tiêu cực như vậy. Một hệ thống loại là về việc đảm bảo hơn là chứng minh sự vắng mặt của lỗi. Cái sau là hệ quả của hệ thống loại. Một hệ thống loại cho ngôn ngữ lập trình là một cách để tạo ra, tại thời điểm biên dịch, một bằng chứng cho thấy một chương trình đáp ứng một số loại đặc tả.

Loại đặc tả mà người ta có thể mã hóa thành một loại phụ thuộc vào ngôn ngữ, hoặc trực tiếp hơn, vào sức mạnh của hệ thống loại ngôn ngữ.

Loại đặc tả cơ bản nhất là sự đảm bảo về hành vi đầu vào / đầu ra của các hàm và tính hợp lệ của bên trong thân hàm. Xem xét một tiêu đề chức năng

f : (Int,Int) -> String

Một hệ thống loại tốt sẽ đảm bảo rằng f chỉ được áp dụng cho các đối tượng sẽ tạo ra một cặp Int khi đánh giá và đảm bảo rằng f sẽ luôn tạo ra một chuỗi.

Một số câu lệnh trong một ngôn ngữ, như khối if-then, không có hành vi đầu vào / đầu ra; ở đây hệ thống loại đảm bảo rằng mỗi tuyên bố hoặc tuyên bố trong khối là hợp lệ; đó là áp dụng các hoạt động cho các đối tượng của loại chính xác. Những đảm bảo này là composable.

Ngoài ra, điều này không cung cấp một loại điều kiện an toàn bộ nhớ. Các trích dẫn bạn đang đối phó là về đúc. Trong một số trường hợp, truyền là tốt, như truyền Int 32 bit sang Int 64 bit. Tuy nhiên, nói chung, nó không sụp đổ hệ thống loại.

Xem xét

Foo x = new Foo(3,4,5,6);
f((Int)x,(Int)x);

Do truyền, x được chuyển thành Int, vì vậy về mặt kỹ thuật, phần trên không kiểm tra kiểu; tuy nhiên, nó thực sự đánh bại mục đích đánh máy.

Một điều có thể tạo ra một hệ thống loại khác và tốt hơn là không cho phép các phôi (A) x trong đó x trước trường hợp là loại B, trừ khi B là một kiểu con (hoặc tiểu dự án) của A. Các ý tưởng về lý thuyết phân nhóm đã được sử dụng trong bảo mật để loại bỏ khả năng các cuộc tấn công tràn / tràn số nguyên.

Tóm lược

Một hệ thống loại là một cách để chứng minh một chương trình đáp ứng một số loại đặc tả. Những lợi ích mà một hệ thống loại có thể cung cấp tùy thuộc vào độ mạnh của hệ thống loại được sử dụng.

Một lợi thế chưa được đề cập cho một hệ thống loại xoay quanh thực tế là nhiều chương trình được đọc nhiều hơn chúng được viết và trong nhiều trường hợp, một hệ thống loại có thể cho phép nhiều thông tin được chỉ định theo cách ngắn gọn và có thể dễ dàng tiêu hóa bởi ai đó đọc mã. Mặc dù các loại tham số không thay thế các nhận xét mô tả, hầu hết mọi người sẽ thấy nó nhanh hơn để đọc: "int Khoảng cách;" hoặc làDistance As Int32hơn là đọc "Khoảng cách phải là một số nguyên +/- 2147483647"; chuyển các phân số có thể mang lại kết quả không nhất quán. "Hơn nữa, các loại tham số có thể giúp giảm khoảng cách giữa việc triển khai API cụ thể xảy ra, so với những gì người gọi có quyền dựa vào. Ví dụ: nếu việc triển khai API cụ thể của API sử dụng các thông số của nó theo một cách mà sẽ ép buộc bất kỳ chuỗi mẫu số, nó có thể là chưa rõ liệu người gọi được phép dựa vào hành vi như vậy, hoặc nếu hiện thực khác của sự cố API sức nếu được chuỗi. có một phương pháp có tham số được quy định như DoubleWould làm rõ rằng bất kỳ giá trị chuỗi nào phải được người gọi ép buộc trước khi được thông qua, có một phương thức với tình trạng quá tải chấp nhận Doublevà một phương thức khác chấp nhậnString sẽ làm cho phần nào rõ ràng hơn rằng người gọi giữ chuỗi sẽ được phép vượt qua họ như vậy.

Vì vậy, trước hết, những gì thực sự là an toàn? Bảo vệ chống tham nhũng dữ liệu, hoặc tin tặc, hoặc trục trặc hệ thống, vv?

Tất cả các câu trả lời khác và nhiều hơn nữa. Nói chung, "an toàn kiểu" đơn giản có nghĩa là không có chương trình nào trình biên dịch biên dịch thành công sẽ có lỗi loại.

Bây giờ, một lỗi loại là gì? Về nguyên tắc, bạn có thể chỉ định bất kỳ thuộc tính không mong muốn nào là lỗi loại và một số hệ thống loại sẽ có thể đảm bảo tĩnh không có chương trình nào có lỗi như vậy.

Theo "thuộc tính" ở trên, tôi có nghĩa là một số loại đề xuất logic áp dụng cho chương trình của bạn, ví dụ: "tất cả các chỉ số đều nằm trong giới hạn mảng". Các loại thuộc tính khác bao gồm, "tất cả các con trỏ được bảo vệ là hợp lệ", "chương trình này không thực hiện bất kỳ I / O nào" hoặc "chương trình này chỉ thực hiện I / O cho / dev / null", v.v. thuộc tính có thể được chỉ định và loại được kiểm tra theo cách này, tùy thuộc vào tính biểu cảm của hệ thống loại của bạn.

Các hệ thống loại phụ thuộc là một trong những hệ thống chung nhất, thông qua đó bạn có thể thực thi khá nhiều bất kỳ tài sản nào bạn muốn. Mặc dù vậy, không nhất thiết phải dễ dàng như vậy, vì các thuộc tính tinh vi phải tuân theo phép lịch sự không hoàn hảo của Gôdel .