До ООП члени структури даних залишалися загальнодоступними?

Коли структура даних (наприклад, черга) реалізована за допомогою мови OOP, деякі члени структури даних повинні бути приватними (наприклад, кількість елементів у черзі).

Черга також може бути реалізована процедурною мовою, використовуючи a structі набір функцій, які працюють на struct. Однак, процедурною мовою ви не можете зробити членів structприватними. Чи члени структури даних, реалізованої процедурною мовою, залишилися загальнодоступними, чи був якийсь трюк, щоб зробити їх приватними?

OOP не винайшов інкапсуляцію і не є синонімом інкапсуляції. Багато мов OOP не мають модифікаторів доступу в стилі C ++ / Java. У багатьох мовах, що не входять в ООП, доступні різні методики для пропонування капсуляції.

Класичним підходом до інкапсуляції є закриття , яке використовується у функціональному програмуванні . Це значно старше, ніж ООП, але є в чомусь еквівалентом. Наприклад, у JavaScript ми можемо створити такий об’єкт:

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

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

Наведений вище plus2об'єкт не має члена, який би дозволяв прямий доступ до xнього - він повністю інкапсульований. add()Метод являє собою замикання по xзмінної.

Мова C підтримує деякі види інкапсуляції через механізм файлів заголовків , зокрема, непрозору техніку вказівника . В C можна оголосити назву структури без визначення її членів. На той момент жодна змінна типу цієї структури не може бути використана, але ми можемо вільно використовувати покажчики на цю структуру (оскільки розмір структурного вказівника відомий під час компіляції). Наприклад, розглянемо цей заголовок:

#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

Тепер ми можемо записувати код, який використовує цей інтерфейс Adder, не маючи доступу до його полів, наприклад:

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

А ось детально вкладені деталі реалізації:

#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;
}

Існує також клас модульних мов програмування , який фокусується на інтерфейсах рівня модулів. Мовна сім'я ML в т.ч. OCaml включає цікавий підхід до модулів, званих функторами . OOP затьмарює і значною мірою поширюється на модульне програмування, але багато нібито переваги OOP більше стосуються модульності, ніж орієнтації на об'єкти.

Існує також зауваження, що класи на мовах OOP, такі як C ++ або Java, часто не використовуються для об'єктів (у розумінні об'єктів, які вирішують операції за допомогою пізнього прив'язування / динамічної диспетчеризації), а лише для абстрактних типів даних (де ми визначаємо публічний інтерфейс, який ховається внутрішні деталі реалізації). У статті " Розуміння абстрагування даних", Revisited (Cook, 2009) більш детально розглядається ця різниця.

Але так, багато мов не мають механізму інкапсуляції. Цими мовами члени структури залишаються загальнодоступними. У крайньому випадку, це буде конвенцією про іменування, яка не перешкоджає використанню. Наприклад, я думаю, що Паскаль не мав корисного механізму інкапсуляції.

По-перше, те, що орієнтується на процедуру та об'єкт, не має нічого спільного з публічним та приватним. Безліч об'єктно-орієнтованих мов не мають поняття контролю доступу.

По-друге, у "С" - який більшість людей називали б процедурним, а не об'єктно-орієнтованим, існує безліч хитрощів, якими можна скористатися, щоб ефективно зробити речі приватними. Дуже поширеним є використання непрозорих (наприклад, пустоти *) покажчиків. Або - ви можете переслати об’єкт, а просто не визначити його у файлі заголовка.

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) { ... }

Подивіться на Windows SDK! Він використовує HANDLE та UINT_PTR, а такі речі є загальними ручками для пам’яті, що використовується в API - це ефективно робить реалізації приватними.

"Непрозорі типи даних" були добре відомою концепцією, коли я закінчував ступінь інформатики 30 років тому. Ми не висвітлювали OOP, оскільки в той час воно не було загальноприйнятим, а "функціональне програмування" вважалося більш правильним.

Модула-2 мала для них пряму підтримку, див. Https://www.modula2.org/reference/modules.php .

Льюїс Прінгл вже пояснив, як вперед декларувати структуру можна використовувати в C. На відміну від Модуля-2, для створення об'єкта потрібно було забезпечити заводську функцію. ( Віртуальних методів також було легко реалізувати в C , коли перший член структури був вказівником на іншу структуру, яка містила вказівники функції на методи.)

Часто використовувались і умовні умови. Наприклад, будь-яке поле, що починається з "_", не має доступу до файлу, який належить даним. Це легко забезпечити створення спеціальних інструментів перевірки.

У кожному масштабному проекті, над яким я працював, (до того, як я перейшов на C ++, тоді C #), була створена система, яка запобігала доступу до "приватних" даних неправильним кодом. Це було трохи менше стандартизовано, ніж зараз.

Зауважте, існує багато мов OO без вбудованої можливості позначати членів приватними. Це можна зробити за умовами, без необхідності компілятора застосовувати конфіденційність. Наприклад, люди часто префіксують приватні змінні з підкресленням.

Існують методи, що ускладнюють доступ до "приватних" змінних, найбільш поширеною є ідіома PIMPL . Це ставить ваші приватні змінні в окрему структуру, з лише покажчиком, виділеним у ваших загальнодоступних файлах заголовків. Це означає додатковий заниження та подання для отримання будь-яких приватних змінних, таких як ((private_impl)(obj->private))->actual_value, що дратує, тому на практиці використовується рідко.

У структурах даних не було "членів", а лише поля даних (припускаючи, що це тип запису). Видимість зазвичай встановлювалася для всього типу. Однак це може бути не таким обмежуючим, як ви думаєте, оскільки функції не були частиною запису.

Давайте відкинемося назад і трохи пізнаємо історію тут ...

Домінуюча парадигма програмування перед ООП називалася структурованим програмуванням . Початковою основною метою цього було уникнути використання неструктурованих вискакувань ("goto" s). Це парадигма, орієнтована на контрольний потік (в той час як OOP більш орієнтована на дані), але все ж це було природним розширенням її для спроби зберегти дані логічно структурованими так само, як код.

Іншим наслідком структурованого програмування було приховування інформації , ідея про те, що реалізація структури коду (яка, швидше за все, змінюється досить часто) повинна триматися окремо від інтерфейсу (який в ідеалі не зміниться майже так само сильно). Зараз це догма, але за старих часів багато людей насправді вважали за краще, щоб кожен розробник ознайомився з деталями всієї системи, тож це було свого часу насправді суперечливою ідеєю. Оригінальне видання " Міфічного чоловіка місяця" Брука фактично заперечувало проти приховування інформації.

Пізніші мови програмування, явно розроблені як хороші Структуровані мови програмування (наприклад, Modula-2 і Ada), як правило, включали інформацію, що приховується як основну концепцію, побудовану навколо якогось поняття згуртованої функції функцій (і будь-яких типів, констант і об'єкти, які вони можуть знадобитися). У Модулі-2 вони називалися "Модулі", в Ада - "Пакети". Багато сучасних мов OOP називають те саме поняття "просторами імен". Ці простори імен були організаційною основою розвитку цих мов, і для більшості цілей можна було використовувати аналогічно класам OOP (без реальної підтримки успадкування, звичайно).

Отже, в Modula-2 та Ada (83) ви могли оголосити будь-яку рутину, тип, константу чи об'єкт у просторі імен приватним чи загальнодоступним, але якщо у вас був тип запису, не було (простий) спосіб оголосити деякі поля запису загальнодоступними та інші приватні. Або весь ваш запис є загальнодоступним, або його немає.

У C ви вже можете переходити навколо покажчиків на оголошені, але невизначені типи, як говорили інші, фактично обмежуючи доступ до всіх полів.

Ви також можете мати приватні та загальнодоступні функції на основі модулів до модулів. Функції, оголошені статичними у вихідному файлі, не видимі зовні, навіть якщо ви намагаєтесь відгадати їх ім'я. Так само ви можете мати статичні глобальні змінні на рівні файлів, що, як правило, є поганою практикою, але дозволяє ізолювати на основі модуля.

Напевно, важливо підкреслити, що обмеження доступу як добре стандартизована конвенція, а не мовна конструкція працює чудово (див. Python). Крім того, обмеження доступу до об'єктних полів захищає програміста лише тоді, коли після створення необхідності змінюється значення даних усередині об'єкта. Який уже кодовий запах. Можливо, constключове слово C та, зокрема, C ++ для методів та аргументів функцій набагато більше допомагають програмісту, ніж досить бідні Java final.

Якщо ваше визначення Public - це можливість отримати доступ до реалізації та даних / властивостей за допомогою власного коду в будь-який момент, відповідь проста: Так . Однак її абстрагували різними способами - залежно від мови.

Я сподіваюся, що це лаконічно відповіло на ваше запитання.

Ось дуже простий зустрічний приклад: у Java interfaces визначають об'єкти, а classes - ні. A classвизначає абстрактний тип даних, а не об'єкт.

Ergo, щоразу, коли ви використовуєте privateв classJava, ви маєте приклад структури даних з приватними членами, яка не орієнтована на об'єкти.