Czy przed OOP członkowie struktury danych byli publicznie dostępni?

Gdy struktura danych (na przykład kolejka) jest implementowana przy użyciu języka OOP, niektórzy członkowie struktury danych muszą być prywatni (na przykład liczba elementów w kolejce).

Kolejka może być również zaimplementowana w języku proceduralnym przy użyciu structzestawu funkcji działających w systemie struct. Jednak w języku proceduralnym nie można uczynić członków structprywatnymi. Czy członkowie struktury danych zaimplementowani w języku proceduralnym pozostali publiczni, czy też istnieje jakiś sposób na uczynienie ich prywatnymi?

OOP nie wynalazł enkapsulacji i nie jest synonimem enkapsulacji. Wiele języków OOP nie ma modyfikatorów dostępu w stylu C ++ / Java. Wiele języków innych niż OOP oferuje różne techniki oferujące enkapsulację.

Klasycznym podejściem do enkapsulacji są zamknięcia , stosowane w programowaniu funkcjonalnym . Jest to znacznie starsze niż OOP, ale jest w pewnym sensie równoważne. Np. W JavaScript możemy stworzyć taki obiekt:

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

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

Powyższy plus2obiekt nie ma elementu, który umożliwiałby bezpośredni dostęp do x- jest całkowicie zamknięty. add()Metoda jest zamknięcie na xzmiennej.

Język C obsługuje pewne rodzaje enkapsulacji za pomocą mechanizmu pliku nagłówkowego , w szczególności technikę nieprzezroczystego wskaźnika . W C można zadeklarować nazwę struktury bez definiowania jej członków. W tym momencie nie można użyć żadnej zmiennej typu tej struktury, ale możemy swobodnie używać wskaźników do tej struktury (ponieważ rozmiar wskaźnika struktury jest znany w czasie kompilacji). Weźmy na przykład ten plik nagłówkowy:

#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

Możemy teraz napisać kod korzystający z tego interfejsu Addera, bez dostępu do jego pól, np .:

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

I oto byłyby całkowicie zamknięte szczegóły implementacji:

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

Istnieje również klasa modułowych języków programowania , która koncentruje się na interfejsach na poziomie modułu. Rodzina języków ML włącznie OCaml zawiera ciekawe podejście do modułów zwanych funktorami . OOP przyćmiło i w dużej mierze przysłoniło programowanie modułowe, ale wiele rzekomych zalet OOP dotyczy bardziej modułowości niż orientacji obiektowej.

Istnieje również spostrzeżenie, że klasy w językach OOP, takich jak C ++ lub Java, często nie są używane dla obiektów (w sensie podmiotów, które rozwiązują operacje poprzez późne wiązanie / dynamiczne wysyłanie), a jedynie do abstrakcyjnych typów danych (w których definiujemy publiczny interfejs, który ukrywa wewnętrzne szczegóły wdrożenia). Artykuł „ Understanding Data Abstraction, Revisited” (Cook, 2009) omawia tę różnicę bardziej szczegółowo.

Ale tak, wiele języków nie ma żadnego mechanizmu enkapsulacji. W tych językach członkowie struktury są publicznie dostępni. Co najwyżej istniałaby konwencja nazewnictwa zniechęcająca do użycia. Np. Myślę, że Pascal nie miał użytecznego mechanizmu enkapsulacji.

Po pierwsze, podejście proceduralne kontra obiektowe nie ma nic wspólnego z publicznym czy prywatnym. Wiele języków obiektowych nie ma pojęcia o kontroli dostępu.

Po drugie, w „C” - które większość ludzi nazwałaby proceduralnymi, a nie obiektowymi, istnieje wiele sztuczek, których można użyć, aby skutecznie uczynić rzeczy prywatnymi. Bardzo często stosuje się nieprzezroczyste wskaźniki (np. Void *). Lub - możesz przekazać deklarację obiektu i po prostu nie definiować go w pliku nagłówkowym.

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

Spójrz na Windows SDK! Wykorzystuje HANDLE i UINT_PTR, a takie rzeczy są ogólnymi uchwytami pamięci używanej w interfejsach API - skutecznie czyniąc implementacje prywatnymi.

„Nieprzezroczyste typy danych” były dobrze znaną koncepcją, gdy 30 lat temu uzyskałem stopień informatyki. Nie obejmowaliśmy OOP, ponieważ nie było to wtedy w powszechnym użyciu, a „programowanie funkcjonalne” uznano za bardziej poprawne.

Modula-2 miała dla nich bezpośrednie wsparcie, patrz https://www.modula2.org/reference/modules.php .

Lewis Pringle już wyjaśnił, w jaki sposób można deklarować strukturę w C w przód. W przeciwieństwie do Module-2, do utworzenia obiektu trzeba było zapewnić funkcję fabryki. ( Metody wirtualne były również łatwe do wdrożenia w C , ponieważ pierwszy element struktury był wskaźnikiem innej struktury zawierającej wskaźniki funkcji do metod).

Często stosowano także konwencję. Na przykład żadne pole zaczynające się od „_” nie powinno być dostępne poza plikiem, który był właścicielem danych. Łatwo to wymusić dzięki stworzeniu niestandardowych narzędzi sprawdzających.

Każdy projekt na dużą skalę, nad którym pracowałem (zanim przeszedłem do C ++, a następnie C #) posiadał system zapobiegający dostępowi do „prywatnych” danych przez niewłaściwy kod. To było tylko trochę mniej znormalizowane niż obecnie.

Uwaga: istnieje wiele języków OO bez wbudowanej możliwości oznaczania członków jako prywatnych. Można to zrobić umownie, bez potrzeby kompilatora do egzekwowania prywatności. Na przykład ludzie często poprzedzają prywatne zmienne znakiem podkreślenia.

Istnieją techniki utrudniające dostęp do zmiennych „prywatnych”, z których najczęstszym jest idiom PIMPL . To umieszcza twoje prywatne zmienne w osobnej strukturze, z tylko wskaźnikiem przydzielonym w twoich publicznych plikach nagłówkowych. Oznacza to dodatkowe dereferencje i obsadę, aby uzyskać dowolne zmienne prywatne, coś takiego ((private_impl)(obj->private))->actual_value, co staje się denerwujące, więc w praktyce jest rzadko używane.

Struktury danych nie miały „elementów”, tylko pola danych (zakładając, że był to typ rekordu). Widoczność była zwykle ustawiana dla całego typu. Jednak może to nie być tak ograniczające, jak myślisz, ponieważ funkcje nie były częścią rekordu.

Cofnijmy się i zdobądźmy trochę historii tutaj ...

Dominujący paradygmat programowania przed OOP nazwano programowaniem strukturalnym . Początkowym głównym celem tego było uniknięcie stosowania nieustrukturyzowanych instrukcji skoku („goto”). Jest to paradygmat zorientowany na przepływ sterowania (podczas gdy OOP jest bardziej zorientowany na dane), ale nadal było naturalnym rozszerzeniem jego próby logicznej struktury danych, tak jak kod.

Kolejnym odgałęzieniem programowania strukturalnego było ukrywanie informacji , pomysł, że implementacje struktury kodu (które prawdopodobnie będą się zmieniać dość często) powinny być oddzielone od interfejsu (co idealnie nie zmieni się prawie tak bardzo). Teraz jest to dogmat, ale w dawnych czasach wiele osób uważało, że lepiej jest, aby każdy programista poznał szczegóły całego systemu, więc był to kiedyś kontrowersyjny pomysł. Oryginalna edycja Miesiąca Mitycznego Człowieka Brook'a faktycznie sprzeciwiła się ukrywaniu informacji.

Późniejsze języki programowania zaprojektowane wyraźnie jako dobre Języki programowania strukturalnego (na przykład Modula-2 i Ada) generalnie zawierały ukrywanie informacji jako podstawową koncepcję, zbudowaną wokół pewnego rodzaju koncepcji spójnego ułatwienia funkcji (i wszelkich typów, stałych i obiekty, których mogą potrzebować). W Modula-2 były one nazywane „modułami”, w Adzie „pakietami”. Wiele współczesnych języków OOP nazywa tę samą koncepcję „przestrzeniami nazw”. Te przestrzenie nazw były organizacyjną podstawą rozwoju w tych językach i dla większości celów mogą być używane podobnie jak klasy OOP (oczywiście bez rzeczywistego wsparcia dla dziedziczenia).

Tak więc w Modula-2 i Adzie (83) możesz zadeklarować dowolną procedurę, typ, stałą lub obiekt w przestrzeni nazw prywatnej lub publicznej, ale jeśli masz typ rekordu, nie ma (łatwego) sposobu na zadeklarowanie niektórych pól rekordów jako publicznych i inne prywatne. Albo cała twoja płyta jest publiczna, albo nie.

W C można już przekazywać wskaźniki do zadeklarowanych, ale niezdefiniowanych typów, jak powiedzieli inni, w efekcie ograniczając dostęp do wszystkich pól.

Możesz także mieć funkcje prywatne i publiczne na zasadzie moduł-moduł. Funkcje zadeklarowane jako statyczne w pliku źródłowym nie są widoczne na zewnątrz, nawet jeśli spróbujesz odgadnąć ich nazwę. Podobnie, możesz mieć statyczne zmienne globalne na poziomie pliku, co jest ogólnie złą praktyką, ale pozwala na izolację na poziomie modułu.

Prawdopodobnie ważne jest podkreślenie, że ograniczenie dostępu jako dobrze znormalizowana konwencja, a nie konstrukcja wymuszona językiem, działa dobrze (patrz Python). Co więcej, ograniczenie dostępu do pól obiektowych zawsze chroni programistę tylko wtedy, gdy istnieje potrzeba zmiany wartości danych wewnątrz obiektu po utworzeniu. Który już jest zapachem kodu. Prawdopodobnie constsłowo kluczowe C, a w szczególności C ++ dla metod i argumentów funkcyjnych, jest znacznie większą pomocą dla programisty niż raczej słaba Java final.

Jeśli twoja definicja Public to możliwość dostępu do implementacji i danych / właściwości za pomocą własnego kodu w dowolnym momencie, odpowiedź brzmi: Tak . Został jednak wyodrębniony na różne sposoby - w zależności od języka.

Mam nadzieję, że zwięźle odpowiedziała na twoje pytanie.

Oto bardzo prosty kontrprzykład: w Javie interfacedefiniują obiekty, ale classnie. A classdefiniuje abstrakcyjny typ danych, a nie obiekt.

Ergo, za każdym razem, gdy używasz privatew classJavie, masz przykład struktury danych z elementami prywatnymi, która nie jest zorientowana obiektowo.