Trước OOP, các thành viên cấu trúc dữ liệu có bị bỏ mặc không?

Khi cấu trúc dữ liệu (ví dụ: hàng đợi) được triển khai bằng ngôn ngữ OOP, một số thành viên của cấu trúc dữ liệu cần phải ở chế độ riêng tư (ví dụ: số lượng mục trong hàng đợi).

Một hàng đợi cũng có thể được thực hiện bằng ngôn ngữ thủ tục bằng cách sử dụng structmột tập hợp các hàm hoạt động trên struct. Tuy nhiên, trong một ngôn ngữ thủ tục, bạn không thể làm cho các thành viên của một structtư nhân. Các thành viên của cấu trúc dữ liệu được triển khai theo ngôn ngữ thủ tục có được công khai không, hoặc có một số mẹo để đặt chúng ở chế độ riêng tư?

OOP không phát minh ra đóng gói và không đồng nghĩa với đóng gói. Nhiều ngôn ngữ OOP không có bộ sửa đổi truy cập kiểu C ++ / Java. Nhiều ngôn ngữ không phải OOP có các kỹ thuật khác nhau có sẵn để cung cấp đóng gói.

Một cách tiếp cận cổ điển để đóng gói là đóng cửa , như được sử dụng trong lập trình chức năng . Điều này cũ hơn đáng kể so với OOP nhưng theo cách tương đương. Ví dụ: trong JavaScript, chúng tôi có thể tạo một đối tượng như thế này:

function Adder(x) {
  this.add = function add(y) {
    return x + y;
  }
}

var plus2 = new Adder(2);
plus2.add(7);  //=> 9

plus2Đối tượng trên không có thành viên nào cho phép truy cập trực tiếp vào x- nó hoàn toàn được gói gọn. Các add()phương pháp là một đóng cửa so với xbiến.

Các C ngôn ngữ hỗ trợ một số loại đóng gói thông qua nó tập tin tiêu đề cơ chế, đặc biệt là con trỏ đục kỹ thuật. Trong C, có thể khai báo tên cấu trúc mà không xác định thành viên của nó. Tại thời điểm đó, không có biến nào của loại cấu trúc đó có thể được sử dụng, nhưng chúng ta có thể sử dụng các con trỏ tới cấu trúc đó một cách tự do (vì kích thước của một con trỏ cấu trúc được biết đến tại thời điểm biên dịch). Ví dụ: xem xét tệp tiêu đề này:

#ifndef ADDER_H
#define ADDER_H

typedef struct AdderImpl *Adder;

Adder Adder_new(int x);
void Adder_free(Adder self);
int Adder_add(Adder self, int y);

#endif

Bây giờ chúng ta có thể viết mã sử dụng giao diện Adder này mà không cần truy cập vào các trường của nó, ví dụ:

Adder plus2 = Adder_new(2);
if (!plus2) abort();
printf("%d\n", Adder_add(plus2, 7));  /* => 9 */
Adder_free(plus2);

Và đây sẽ là chi tiết thực hiện được gói gọn:

#include "adder.h"

struct AdderImpl { int x; };

Adder Adder_new(int x) {
  Adder self = malloc(sizeof *self);
  if (!self) return NULL;
  self->x = x;
  return self;
}

void Adder_free(Adder self) {
  free(self);
}

int Adder_add(Adder self, int y) {
  return self->x + y;
}

Ngoài ra còn có lớp ngôn ngữ lập trình mô-đun , tập trung vào các giao diện cấp mô-đun. Gia đình ngôn ngữ ML bao gồm. OCaml bao gồm một cách tiếp cận thú vị cho các mô-đun được gọi là functor . OOP bị lu mờ và phần lớn là lập trình mô-đun, nhưng nhiều lợi thế có chủ đích của OOP là về tính mô đun hơn là hướng đối tượng.

Ngoài ra còn có quan sát rằng các lớp trong các ngôn ngữ OOP như C ++ hoặc Java thường không được sử dụng cho các đối tượng (theo nghĩa các thực thể giải quyết các hoạt động thông qua liên kết động / công văn muộn) mà chỉ dành cho các loại dữ liệu trừu tượng (trong đó chúng tôi xác định giao diện chung ẩn chi tiết thực hiện nội bộ). Bài viết về Tìm hiểu trừu tượng dữ liệu, được xem xét lại (Cook, 2009) thảo luận về sự khác biệt này chi tiết hơn.

Nhưng có, nhiều ngôn ngữ không có cơ chế đóng gói nào. Trong các ngôn ngữ này, các thành viên cấu trúc được để lại công khai. Nhiều nhất, sẽ có một quy ước đặt tên không khuyến khích sử dụng. Ví dụ, tôi nghĩ Pascal không có cơ chế đóng gói hữu ích.

Đầu tiên, là thủ tục so với hướng đối tượng không liên quan gì đến công khai và riêng tư. Rất nhiều ngôn ngữ hướng đối tượng không có khái niệm về kiểm soát truy cập.

Thứ hai, trong "C" - mà hầu hết mọi người sẽ gọi là thủ tục và không hướng đối tượng, có rất nhiều thủ thuật bạn có thể sử dụng để làm cho mọi thứ trở nên riêng tư. Một cái rất phổ biến là sử dụng các con trỏ mờ (ví dụ void *). Hoặc - bạn có thể chuyển tiếp khai báo một đối tượng và chỉ không xác định nó trong tệp tiêu đề.

foo.h:

struct queue;
struct queue* makeQueue();
void add2Queue(struct queue* q, int value);
...

foo.c:

struct queue {
    int* head;
    int* head;
};
struct queue* makeQueue() { .... }
void add2Queue(struct queue* q, int value) { ... }

Nhìn vào SDK Windows! Nó sử dụng HANDLE và UINT_PTR và những thứ tương tự như là các thẻ điều khiển chung cho bộ nhớ được sử dụng trong API - làm cho việc triển khai ở chế độ riêng tư một cách hiệu quả.

"Các loại dữ liệu mờ" là một khái niệm nổi tiếng khi tôi học văn bằng máy tính 30 năm trước. Chúng tôi không bao gồm OOP vì nó không được sử dụng phổ biến vào thời điểm đó và "lập trình chức năng" được coi là chính xác hơn.

Modula-2 đã hỗ trợ trực tiếp cho họ, xem https://www.modula2.org/reference/modules.php .

Lewis Pringle đã giải thích về cách khai báo một cấu trúc có thể được sử dụng trong C. Không giống như Mô-đun 2, một chức năng của nhà máy phải được cung cấp để tạo đối tượng. ( Các phương thức ảo cũng dễ thực hiện trong C bằng cách có thành viên đầu tiên của một cấu trúc là một con trỏ tới một cấu trúc khác có chứa các con trỏ hàm cho các phương thức.)

Thông thường quy ước cũng được sử dụng. Ví dụ: không nên truy cập bất kỳ trường nào bắt đầu bằng miền _ _ bên ngoài tệp sở hữu dữ liệu. Điều này đã được thực thi dễ dàng bằng cách tạo ra các công cụ kiểm tra tùy chỉnh.

Mỗi dự án quy mô lớn mà tôi đã làm việc, (trước khi tôi chuyển sang C ++ thì C #) đã có một hệ thống để ngăn chặn dữ liệu "riêng tư" bị truy cập bởi mã sai. Nó chỉ là một chút ít tiêu chuẩn hơn bây giờ.

Lưu ý rằng có nhiều ngôn ngữ OO không có khả năng tích hợp để đánh dấu các thành viên riêng tư. Điều này có thể được thực hiện theo quy ước, mà không cần trình biên dịch để thực thi quyền riêng tư. Ví dụ, mọi người sẽ thường tiền tố các biến riêng tư với dấu gạch dưới.

Có các kỹ thuật để làm cho việc truy cập các biến "riêng tư" trở nên khó khăn hơn, phổ biến nhất là thành ngữ PIMPL . Điều này đặt các biến riêng tư của bạn trong một cấu trúc riêng biệt, chỉ với một con trỏ được phân bổ trong các tệp tiêu đề công khai của bạn. Điều này có nghĩa là một sự bổ sung thêm và một diễn viên để có được bất kỳ biến riêng tư nào, một cái gì đó giống như ((private_impl)(obj->private))->actual_value, gây khó chịu, vì vậy trong thực tế hiếm khi được sử dụng.

Cấu trúc dữ liệu không có "thành viên", chỉ có các trường dữ liệu (giả sử đó là loại bản ghi). Tầm nhìn thường được đặt cho toàn bộ loại. Tuy nhiên, điều đó có thể không giới hạn như bạn nghĩ, bởi vì các chức năng không phải là một phần của bản ghi.

Hãy quay lại và tìm hiểu một chút về lịch sử ở đây ...

Mô hình lập trình chi phối trước OOP được gọi là lập trình có cấu trúc . Mục tiêu chính ban đầu của việc này là để tránh sử dụng các câu lệnh nhảy không có cấu trúc ("goto" s). Đây là mô hình hướng dòng điều khiển (trong khi OOP thiên về dữ liệu hơn), nhưng nó vẫn là một phần mở rộng tự nhiên của nó để cố gắng giữ dữ liệu có cấu trúc logic giống như mã.

Một phần khác của lập trình có cấu trúc là ẩn thông tin , ý tưởng rằng việc triển khai cấu trúc của mã (có khả năng thay đổi khá thường xuyên) nên được tách biệt khỏi giao diện (lý tưởng là sẽ không thay đổi gần như nhiều). Bây giờ là giáo điều, nhưng vào thời xa xưa, nhiều người thực sự coi mọi nhà phát triển nên tìm hiểu chi tiết về toàn bộ hệ thống, vì vậy đây thực sự là một ý tưởng gây tranh cãi. Phiên bản gốc của Tháng huyền thoại của Brook thực sự lập luận chống lại việc che giấu thông tin.

Các ngôn ngữ lập trình sau này được thiết kế rõ ràng là ngôn ngữ lập trình có cấu trúc tốt (ví dụ Modula-2 và Ada) thường bao gồm thông tin ẩn như một khái niệm cơ bản, được xây dựng xung quanh một số loại khái niệm về một cơ sở gắn kết của các hàm (và bất kỳ loại, hằng, và đối tượng họ có thể yêu cầu). Trong Modula-2, chúng được gọi là "Mô-đun", trong "Gói" của Ada. Rất nhiều ngôn ngữ OOP hiện đại gọi cùng một khái niệm là "không gian tên". Các không gian tên này là nền tảng tổ chức phát triển trong các ngôn ngữ này và cho hầu hết các mục đích có thể được sử dụng tương tự như các lớp OOP (tất nhiên không có hỗ trợ thực sự cho việc thừa kế).

Vì vậy, trong Modula-2 và Ada (83), bạn có thể khai báo bất kỳ thường trình, loại, hằng hoặc đối tượng trong một không gian tên riêng tư hoặc công khai, nhưng nếu bạn có một loại bản ghi, không có cách nào (dễ dàng) để khai báo một số trường bản ghi công khai và những người khác riêng tư. Toàn bộ hồ sơ của bạn là công khai, hoặc không.

Trong C, bạn có thể chuyển các con trỏ tới các kiểu khai báo nhưng không xác định như những người khác đã nói, có hiệu lực hạn chế quyền truy cập vào tất cả các trường.

Bạn cũng có thể có các chức năng riêng tư và công khai trên cơ sở mô-đun. Các hàm được khai báo tĩnh trong tệp nguồn không hiển thị bên ngoài, ngay cả khi bạn cố đoán tên của chúng. Tương tự, bạn có thể có các biến toàn cục ở cấp độ tệp tĩnh, thường là thực tiễn xấu nhưng cho phép cách ly trên cơ sở mô-đun.

Có lẽ rất quan trọng để nhấn mạnh rằng hạn chế truy cập như một quy ước được tiêu chuẩn hóa tốt hơn là một cấu trúc được thi hành bằng ngôn ngữ hoạt động tốt (xem Python). Trên hết, việc hạn chế quyền truy cập vào các trường đối tượng sẽ chỉ bảo vệ lập trình viên khi có nhu cầu thay đổi giá trị của dữ liệu bên trong một đối tượng sau khi tạo. Mà đã là một mùi mã. Có thể cho rằng, consttừ khóa của C và đặc biệt là C ++ cho các phương thức và đối số hàm là một trợ giúp lớn hơn cho lập trình viên so với Java khá kém final.

Nếu định nghĩa về Công khai của bạn là khả năng truy cập triển khai và dữ liệu / thuộc tính thông qua mã của riêng bạn tại bất kỳ thời điểm nào, câu trả lời chỉ đơn giản là: Có . Tuy nhiên, nó được trừu tượng hóa bằng nhiều phương tiện khác nhau - tùy thuộc vào ngôn ngữ.

Tôi hy vọng điều này ngắn gọn trả lời câu hỏi của bạn.

Đây là một ví dụ phản biện rất đơn giản: trong Java, interfaces định nghĩa các đối tượng, nhưng classes thì không. A classđịnh nghĩa một Kiểu dữ liệu trừu tượng, không phải là một đối tượng.

Ergo, bất cứ khi nào bạn sử dụng privatetrong classJava, bạn có một ví dụ về cấu trúc dữ liệu với các thành viên riêng không hướng đối tượng.