Hoàn toàn bất biến và lập trình hướng đối tượng

Trong hầu hết các ngôn ngữ OOP, các đối tượng thường có thể thay đổi với một tập hợp ngoại lệ giới hạn (ví dụ: bộ dữ liệu và chuỗi trong python). Trong hầu hết các ngôn ngữ chức năng, dữ liệu là bất biến.

Cả hai đối tượng có thể thay đổi và bất biến đều mang lại một danh sách toàn bộ ưu điểm và nhược điểm của riêng chúng.

Có những ngôn ngữ cố gắng kết hôn với cả hai khái niệm như ví dụ scala nơi bạn có (được tuyên bố rõ ràng) dữ liệu có thể thay đổi và không thay đổi (vui lòng sửa cho tôi nếu tôi sai, kiến ​​thức về scala của tôi bị hạn chế nhiều hơn).

Câu hỏi của tôi là: Liệu hoàn chỉnh (! Sic) không thay đổi -ie không có đối tượng có thể đột biến khi nó đã được created- thực hiện bất kỳ ý nghĩa trong bối cảnh OOP?

Có thiết kế hoặc thực hiện của một mô hình như vậy?

Về cơ bản, là (hoàn toàn) bất biến và OOP đối lập hay trực giao?

Động lực: Trong OOP bạn thường hoạt động trên dữ liệu, thay đổi (biến đổi) thông tin cơ bản, giữ các tham chiếu giữa các đối tượng đó. Ví dụ, một đối tượng của lớp Personvới một thành viên fathertham chiếu đến một Personđối tượng khác . Nếu bạn thay đổi tên của người cha, điều này sẽ hiển thị ngay lập tức cho đối tượng con mà không cần cập nhật. Không thay đổi, bạn sẽ cần phải xây dựng các đối tượng mới cho cả cha và con. Nhưng bạn sẽ có ít kerfuffle hơn với các đối tượng được chia sẻ, đa luồng, GIL, v.v.

OOP và bất biến gần như hoàn toàn trực giao với nhau. Tuy nhiên, lập trình bắt buộc và bất biến là không.

OOP có thể được tóm tắt bởi hai tính năng cốt lõi:

• Đóng gói : Tôi sẽ không truy cập trực tiếp vào nội dung của các đối tượng mà thay vào đó giao tiếp thông qua một giao diện cụ thể (các phương thức trực tuyến) với đối tượng này. Giao diện này có thể ẩn dữ liệu nội bộ từ tôi. Về mặt kỹ thuật, điều này đặc trưng cho lập trình mô-đun chứ không phải OOP. Truy cập dữ liệu qua giao diện được xác định gần tương đương với loại dữ liệu trừu tượng.

• Công văn động : Khi tôi gọi một phương thức trên một đối tượng, phương thức được thực thi sẽ được giải quyết trong thời gian chạy. (Ví dụ, trong OOP dựa trên lớp, tôi có thể gọi một sizephương thức trên một IListthể hiện, nhưng cuộc gọi có thể được giải quyết thành một triển khai trong một LinkedListlớp). Công văn động là một cách để cho phép hành vi đa hình.

Đóng gói có ý nghĩa ít hơn mà không có tính đột biến (không có trạng thái bên trong có thể bị hỏng bởi sự can thiệp bên ngoài), nhưng nó vẫn có xu hướng làm cho sự trừu tượng dễ dàng hơn ngay cả khi mọi thứ đều bất biến.

Một chương trình bắt buộc bao gồm các câu lệnh được thực hiện tuần tự. Một tuyên bố có tác dụng phụ như thay đổi trạng thái của chương trình. Với sự bất biến, trạng thái không thể thay đổi (tất nhiên, một trạng thái mới có thể được tạo ra). Do đó, lập trình mệnh lệnh về cơ bản là không tương thích với tính bất biến.

Bây giờ xảy ra rằng OOP trong lịch sử luôn được kết nối với lập trình mệnh lệnh (Simula dựa trên Algol) và tất cả các ngôn ngữ OOP chính thống đều có nguồn gốc bắt buộc (C ++, Java, C #, đấm đều bắt nguồn từ C). Điều này không ngụ ý rằng bản thân OOP sẽ là bắt buộc hoặc có thể thay đổi, điều này chỉ có nghĩa là việc triển khai OOP bằng các ngôn ngữ này cho phép khả năng biến đổi.

Lưu ý, có một văn hóa giữa các lập trình viên hướng đối tượng, nơi mọi người cho rằng nếu bạn đang thực hiện OOP rằng hầu hết các đối tượng của bạn sẽ có thể thay đổi, nhưng đó là một vấn đề riêng biệt với việc liệu OOP có yêu cầu khả năng biến đổi hay không. Ngoài ra, văn hóa đó dường như đang dần thay đổi theo hướng bất biến hơn, do sự tiếp xúc của mọi người với lập trình chức năng.

Scala là một minh họa thực sự tốt rằng tính đột biến không cần thiết cho hướng đối tượng. Trong khi Scala hỗ trợ khả năng biến đổi, việc sử dụng nó không được khuyến khích. Thành ngữ Scala là rất nhiều đối tượng hướng và cũng gần như hoàn toàn bất biến. Nó chủ yếu cho phép khả năng tương thích với Java và vì trong một số trường hợp, các đối tượng bất biến không hiệu quả hoặc không ổn định để làm việc với.

Ví dụ, so sánh danh sách Scala và danh sách Java . Danh sách bất biến của Scala chứa tất cả các phương thức đối tượng giống như danh sách có thể thay đổi của Java. Thực tế, vì Java sử dụng các hàm tĩnh cho các hoạt động như sắp xếp và Scala thêm các phương thức kiểu chức năng như map. Tất cả các đặc điểm của đóng gói, kế thừa và đa hình OOP có sẵn ở dạng quen thuộc với các lập trình viên hướng đối tượng và được sử dụng một cách thích hợp.

Sự khác biệt duy nhất bạn sẽ thấy là khi bạn thay đổi danh sách, bạn sẽ nhận được một đối tượng mới. Điều đó thường yêu cầu bạn sử dụng các mẫu thiết kế khác với các đối tượng có thể thay đổi, nhưng nó không yêu cầu bạn phải từ bỏ OOP hoàn toàn.

Tính không thay đổi có thể được mô phỏng bằng ngôn ngữ OOP, bằng cách chỉ hiển thị các điểm truy cập đối tượng dưới dạng phương thức hoặc thuộc tính chỉ đọc không làm thay đổi dữ liệu. Tính không thay đổi hoạt động giống nhau trong các ngôn ngữ OOP giống như trong bất kỳ ngôn ngữ chức năng nào, ngoại trừ việc bạn có thể thiếu một số tính năng ngôn ngữ chức năng.

Giả định của bạn dường như là tính đột biến là một tính năng cốt lõi của hướng đối tượng. Nhưng khả năng biến đổi chỉ đơn giản là một thuộc tính của các đối tượng hoặc giá trị. Hướng đối tượng bao gồm một số khái niệm nội tại (đóng gói, đa hình, kế thừa, v.v.) có ít hoặc không liên quan gì đến đột biến, và bạn vẫn sẽ nhận được lợi ích của các tính năng đó, ngay cả khi bạn biến mọi thứ thành bất biến.

Không phải tất cả các ngôn ngữ chức năng đều yêu cầu sự bất biến. Clojure có một chú thích cụ thể cho phép các loại có thể thay đổi và hầu hết các ngôn ngữ chức năng "thực tế" có một cách để chỉ định các loại có thể thay đổi.

Một câu hỏi tốt hơn để hỏi có thể là "Liệu sự bất biến hoàn toàn có ý nghĩa trong lập trình mệnh lệnh ?" Tôi muốn nói câu trả lời rõ ràng cho câu hỏi đó là không. Để đạt được sự bất biến hoàn toàn trong lập trình mệnh lệnh, bạn sẽ phải từ bỏ những thứ như forvòng lặp (vì bạn sẽ phải thay đổi một biến vòng lặp) để ủng hộ đệ quy, và bây giờ dù sao bạn cũng lập trình theo cách chức năng.

Việc phân loại các đối tượng là đóng gói các giá trị hoặc thực thể thường rất hữu ích, với điểm khác biệt là nếu một thứ gì đó là một giá trị, mã giữ tham chiếu đến nó sẽ không bao giờ thấy thay đổi trạng thái của nó theo bất kỳ kiểu nào mà bản thân mã không khởi tạo. Ngược lại, mã chứa tham chiếu đến một thực thể có thể mong đợi nó thay đổi theo những cách nằm ngoài sự kiểm soát của chủ sở hữu tham chiếu.

Mặc dù có thể sử dụng giá trị đóng gói bằng cách sử dụng các đối tượng thuộc loại có thể thay đổi hoặc không thay đổi, một đối tượng chỉ có thể hoạt động như một giá trị nếu áp dụng ít nhất một trong các điều kiện sau:

1. Không có tài liệu tham khảo nào về đối tượng sẽ được tiếp xúc với bất cứ điều gì có thể thay đổi trạng thái được gói gọn trong đó.

2. Người giữ ít nhất một trong số các tham chiếu đến đối tượng biết tất cả các cách sử dụng mà bất kỳ tham chiếu còn lại nào có thể được đặt.

Vì tất cả các trường hợp của các loại bất biến tự động đáp ứng yêu cầu đầu tiên, sử dụng chúng làm giá trị là dễ dàng. Đảm bảo rằng một trong hai yêu cầu được đáp ứng khi sử dụng các loại có thể thay đổi, ngược lại, khó khăn hơn nhiều. Trong khi các tham chiếu đến các loại bất biến có thể được tự do chuyển qua như một phương tiện đóng gói trạng thái được gói gọn trong đó, chuyển qua trạng thái được lưu trữ trong các loại có thể thay đổi đòi hỏi phải xây dựng các đối tượng bao bọc bất biến, hoặc sao chép trạng thái được đóng gói bởi các đối tượng riêng tư vào các đối tượng khác hoặc được cung cấp bởi hoặc được xây dựng cho người nhận dữ liệu.

Các loại không thay đổi hoạt động rất tốt để truyền các giá trị và thường ít nhất có thể sử dụng được để thao túng chúng. Họ không tốt lắm, tuy nhiên, trong việc xử lý các thực thể. Điều gần nhất mà người ta có thể có đối với một thực thể trong một hệ thống với các kiểu hoàn toàn bất biến là một hàm, với trạng thái của hệ thống, sẽ báo cáo các thuộc tính của một phần nào đó hoặc tạo ra một thể hiện trạng thái hệ thống mới giống như một cung cấp một ngoại trừ một số phần cụ thể sẽ khác nhau trong một số thời trang có thể lựa chọn. Hơn nữa, nếu mục đích của một thực thể là giao diện một số mã với một cái gì đó tồn tại trong thế giới thực, thì thực thể đó có thể tránh việc phơi bày trạng thái có thể thay đổi.

Ví dụ: nếu một người nhận được một số dữ liệu qua kết nối TCP, người ta có thể tạo ra một đối tượng "trạng thái của thế giới" mới bao gồm dữ liệu đó trong bộ đệm của mình mà không ảnh hưởng đến bất kỳ tham chiếu nào đến "trạng thái cũ" của thế giới, nhưng các bản sao cũ của trạng thái thế giới không bao gồm lô dữ liệu cuối cùng sẽ bị lỗi và không nên được sử dụng vì chúng sẽ không còn phù hợp với trạng thái của ổ cắm TCP trong thế giới thực.

Trong c # một số loại là bất biến như chuỗi.

Điều này dường như hơn nữa cho thấy rằng sự lựa chọn đã được xem xét mạnh mẽ.

Để chắc chắn rằng hiệu suất thực sự đòi hỏi phải sử dụng các loại không thay đổi nếu bạn phải sửa đổi loại đó hàng trăm ngàn lần. Đó là lý do tại sao nó được đề xuất sử dụng StringBuilderlớp thay vì stringlớp trong trường hợp này.

Tôi đã thực hiện một thử nghiệm với trình lược tả và sử dụng loại không thay đổi thực sự đòi hỏi nhiều CPU và RAM hơn.

Nó cũng trực quan nếu bạn xem xét rằng để sửa đổi chỉ một chữ cái trong chuỗi 4000 ký tự, bạn phải sao chép mọi ký tự trong một khu vực khác của RAM.

Hoàn toàn bất biến của mọi thứ không có ý nghĩa nhiều trong OOP, hoặc hầu hết các mô hình khác cho vấn đề đó, vì một lý do rất lớn:

Mỗi chương trình hữu ích đều có tác dụng phụ.

Một chương trình không gây ra bất cứ điều gì để thay đổi, là vô giá trị. Bạn cũng có thể không chạy nó, vì hiệu ứng sẽ giống hệt nhau.

Ngay cả khi bạn nghĩ rằng bạn không thay đổi bất cứ điều gì và chỉ đơn giản là tóm tắt một danh sách các số bạn nhận được bằng cách nào đó, hãy xem xét rằng bạn cần phải làm gì đó với kết quả - cho dù bạn in nó ra đầu ra tiêu chuẩn, hãy ghi nó vào một tệp, hoặc bất cứ nơi nào. Và điều đó liên quan đến việc đột biến một bộ đệm và thay đổi trạng thái của hệ thống.

Nó có thể có nhiều ý nghĩa để hạn chế khả năng biến đổi đối với các bộ phận cần có thể thay đổi. Nhưng nếu hoàn toàn không có gì cần thay đổi, thì bạn không làm gì đáng làm cả.

Tôi nghĩ nó phụ thuộc vào việc định nghĩa OOP của bạn có phải là nó sử dụng kiểu truyền tin nhắn hay không.

Các hàm thuần túy không phải biến đổi bất cứ thứ gì vì chúng trả về các giá trị mà bạn có thể lưu trữ trong các biến mới.

var brandNewVariable = pureFunction(foo);

Với kiểu truyền tin nhắn, bạn bảo một đối tượng lưu trữ dữ liệu mới thay vì hỏi nó dữ liệu mới nào bạn nên lưu trữ trong một biến mới.

sameOldObject.changeMe(foo);

Có thể có các đối tượng và không làm biến đổi chúng, bằng cách làm cho các phương thức của nó các hàm thuần túy xảy ra để sống bên trong đối tượng thay vì bên ngoài.

var brandNewVariable = nonMutatingObject.askMe(foo);

Nhưng không thể trộn lẫn phong cách truyền thông điệp và các đối tượng bất biến.