OOP'tan önce veri yapısı üyeleri herkese açık mı kaldı?

Bir OOP dili kullanılarak bir veri yapısı (örneğin, bir sıra) uygulandığında, veri yapısının bazı üyelerinin özel olması gerekir (örneğin, sıradaki öğe sayısı).

Bir sıra, işlemsel bir dilde structve üzerinde çalışan bir dizi işlevi kullanarak da uygulanabilir struct. Ancak, usule ilişkin bir dilde üyelerin structözel üyeliğini yapamazsınız . Bir veri yapısının üyeleri bir prosedür dilinde kamuya açık bırakılmış mıydı, yoksa onları özel kılacak hileler var mıydı?

OOP kapsülleme icat etmedi ve kapsülleme ile eşanlamlı değildi. Çoğu OOP dilinde C ++ / Java stili erişim değiştiricileri yoktur. Birçok OOP dışı dil, kapsülleme sunmak için çeşitli tekniklere sahiptir.

Kapsülleme için klasik bir yaklaşım , fonksiyonel programlamada kullanılan kapaklardır . Bu, OOP'dan önemli ölçüde daha eskidir ancak bir şekilde eşdeğerdir. Örneğin, JavaScript'te şöyle bir nesne yaratabiliriz:

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

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

Yukarıdaki plus2nesnenin doğrudan erişime izin verecek bir üyesi yoktur x- tamamen kapsüllenmiştir. add()Yöntem, üzerinde bir kapaktır xdeğişken.

Cı dili, içinden kapsülleme birtakım destekler başlık dosyası mekanizması, özel olarak , opak işaretçi tekniği. C de üyelerini tanımlamadan bir yapı ismi tanımlamak mümkündür. Bu noktada, o yapının türünün hiçbir değişkeni kullanılamaz, ancak o yapı için işaretçileri serbestçe kullanabiliriz (çünkü bir yapı göstergesinin boyutu derleme zamanında bilinir). Örneğin, bu başlık dosyasını düşünün:

#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

Artık bu Adder arabirimini kullanan, alanlarına erişimi olmayan bir kod yazabiliriz, örneğin:

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

Ve burada tamamen kapsüllenmiş uygulama detayları olacaktır:

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

Sınıf da vardır modüler programlama dilleri modül düzeyi arayüzleri odaklanır. ML dil ailesi dahil. OCaml, functor adı verilen modüllere ilginç bir yaklaşım içerir . OOP gölgelenmiş ve büyük ölçüde kestirilmiş modüler programlamayı sürdürse de, OOP'un öne sürülen birçok avantajı nesne yönelmesinden çok modülerlikle ilgilidir.

Ayrıca, C ++ veya Java gibi OOP dillerinde sınıfların genellikle nesneler için (geç bağlama / dinamik gönderme yoluyla işlemleri çözen varlıklar anlamında) kullanılmadığı, ancak yalnızca soyut veri türleri için (gizleyen bir ortak arayüz tanımladığımız yerlerde ) gözlemleri vardır. iç uygulama detayları). Veri Soyutlamasını Anlama, Revisited (Cook, 2009) makalesi bu farkı daha ayrıntılı olarak tartışmaktadır.

Ancak evet, birçok dilde hiçbir kapsülleme mekanizması yoktur. Bu dillerde yapı üyeleri herkese açık bırakılmıştır. En çok, kullanımı cesaretlendiren bir adlandırma kuralı olacaktı. Örneğin, Pascal'ın yararlı bir kapsülleme mekanizması olmadığını düşünüyorum.

İlk olarak, usule karşı nesne yönelimli olmak, özel ve kamuoyuyla hiçbir ilgisi yoktur. Nesne yönelimli dillerin çoğunda erişim denetimi kavramı yoktur.

İkincisi, çoğu insanın prosedürel olarak adlandırdığı ve nesneye yönelik olmayan "C" de, olayları etkin bir şekilde özel kılmak için kullanabileceğiniz birçok püf noktası vardır. Çok yaygın olanı opak (örn; boşluk *) işaretçiler kullanmaktır. Veya - bir nesneyi iletebilir ve üstbilgi dosyasında tanımlayamazsınız.

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'ya bak! HANDLE ve UINT_PTR kullanır ve bunun gibi API'lerde kullanılan belleğe genel tutamaçlar gibi şeyler yapar - uygulamaları özel kılar.

"Opak veri tipleri" bilgisayar bilimi diplomamı 30 yıl önce yaptığım zaman bilinen bir kavramdı. OOP'yi o zamanlar yaygın kullanımda olmadığından ve “işlevsel programlama” nın daha doğru olduğu düşünülmedi.

Modula-2 onlara doğrudan destek verdi, bkz. Https://www.modula2.org/reference/modules.php .

Lewis Pringle tarafından daha önce bir yapının ilan edilmesinin C'de nasıl kullanılabileceğini zaten açıklamıştı. Modül-2'den farklı olarak, nesneyi oluşturmak için bir fabrika işlevi sağlanmalıydı. ( Sanal yöntemlerin , bir yapının ilk üyesinin, yöntemlere işlev işaretçileri içeren başka bir yapıya işaretçi olmasıyla C'de uygulanması da kolaydı .)

Sık sık kongre de kullanılmıştır. Örneğin, “_” ile başlayan hiçbir alana verinin bulunduğu dosyanın dışına erişilmemelidir. Bu, özel kontrol araçlarının yaratılmasıyla kolayca zorlandı.

Üzerinde çalıştığım her büyük proje, (C ++ 'a taşınmadan önce C #' ya) "özel" verinin yanlış kodla erişilmesini önleyen bir sisteme sahipti. Şimdi olduğundan daha az standart hale geldi.

Üyeleri özel olarak işaretleme konusunda yerleşik bir yeteneği olmayan birçok OO dili olduğunu unutmayın. Bu, derleyicinin gizliliği sağlamasına gerek kalmadan kongre ile yapılabilir. Örneğin, insanlar genellikle özel değişkenleri alt çizgi ile öneklendirir.

En çok PIMPL deyimi olan "özel" değişkenlere erişmeyi zorlaştıran teknikler var . Bu, özel değişkenlerinizi ayrı bir yapıya koyar, genel başlık dosyalarınızda yalnızca bir işaretçi gösterir. Bu ((private_impl)(obj->private))->actual_value, pratikte nadiren kullanılan , herhangi bir özel değişkenin, sinir bozucu gibi bir şeyin elde edilmesi için ekstra bir zorunluluk ve aldatma anlamına gelir .

Veri yapılarının “üyeleri” yoktu, sadece veri alanları (bir kayıt türü olduğu varsayılarak). Görünürlük genellikle tüm tür için ayarlandı. Ancak, bu fonksiyonlar kaydın bir parçası olmadığından, düşündüğünüz kadar sınırlı olmayabilir.

Geri çekilelim ve burada biraz tarih yazalım ...

OOP'dan önceki baskın programlama paradigmasına yapısal programlama adı verildi . Bunun ilk amacı, yapılandırılmamış atlama ifadelerinin ("goto" lar) kullanılmasından kaçınmaktı. Bu, kontrol akışı yönelimli bir paradigmadır (OOP daha fazla veri odaklı iken), ancak yine de verileri aynı kod gibi mantıksal olarak yapılandırılmış tutmaya çalışmak doğal bir uzantısıydı.

Yapısal programlamanın bir başka sonucu bilgi gizlemekti , kodun yapısının (oldukça sık değişmesi muhtemel olan) uygulamalarının arayüzden ayrı tutulması gerektiği fikri (ideal olarak neredeyse hiç değişmeyecek). Şimdi dogma, ama eski günlerde, birçok kişi aslında her geliştiricinin tüm sistemin ayrıntılarını öğrenmesini daha iyi olduğunu düşünüyordu, bu yüzden bu bir zamanlar tartışmalı bir fikirdi. Brook'un Efsanevi Adam Ayının orijinal baskısı aslında bilginin saklanmasına karşı savundu.

Daha sonra açıkça iyi bir şekilde tasarlanan programlama dilleri Yapısal Programlama dilleri (örneğin, Modula-2 ve Ada) genellikle, bir tür fonksiyonların (ve herhangi bir tür, sabit ve gerekli olabilecek nesneler). Modula-2'de bunlar Ada'ya "Paketler" den "Modüller" olarak adlandırıldı. Pek çok modern OOP dili aynı kavram "ad alanları" olarak adlandırıyor. Bu ad alanları, bu dillerde gelişimin örgütsel temelidir ve çoğu amaç için OOP sınıflarına benzer şekilde kullanılabilir (elbette miras için gerçek bir destek olmadan).

Dolayısıyla, Modula-2 ve Ada'da (83) özel veya genel olarak herhangi bir rutin, tür, sabit veya nesne adını açıklayabilirdiniz, ancak bir kayıt türünüz varsa, bazı kayıt alanlarını genel olarak ilan etmenin hiçbir (kolay) yolu yoktu. ve diğerleri özel. Ya tüm kayıtların halka açık ya da değil.

C de, tüm alanlara erişimi kısıtlamak amacıyla, diğerlerinin söylediği gibi, tanımlanmış ancak tanımlanmamış türlere işaretçilerin arasından geçebilirsiniz.

Modül-modül bazında özel ve genel işlevlere de sahip olabilirsiniz. Kaynak dosyada statik olarak bildirilen işlevler, adlarını tahmin etmeye çalışsanız bile, dış görünmez. Benzer şekilde, genel olarak kötü bir uygulama olan ancak modül bazında yalıtmaya izin veren statik dosya düzeyinde global değişkenlere sahip olabilirsiniz.

Dilin uyguladığı bir yapıdan ziyade iyi bir standart olan kongre olarak erişim kısıtlamasının gayet iyi çalıştığını vurgulamak büyük olasılıkla önemlidir (bakınız Python). Bunun da ötesinde, nesne alanlarına erişimi kısıtlamak ancak programcıyı, oluşturulduktan sonra bir nesnenin içindeki verilerin değerini değiştirme ihtiyacı olduğunda koruyacaktır. Bu zaten bir kod kokusu. Muhtemelen, C'ler ve özellikle de C ++ 'ların constmetot ve fonksiyon argümanları için kullandıkları anahtar kelime, programcıya Java’dan ziyade çok daha fazla yardımcı olmaktadır final.

Kamu tanımınız, uygulamaya ve verilere / özelliklere kendi kodunuzla herhangi bir noktada erişme yeteneği ise, cevap basitçe: Evet . Ancak, diline bağlı olarak çeşitli yollarla soyutlanmıştır.

Umarım bu sorunuzu kesin olarak cevaplamıştır.

İşte çok basit bir karşı örnek: Java'da, interfaces nesneleri tanımlamak ama classes yok. A class, bir nesneyi değil bir Soyut Veri Türünü tanımlar.

Ergo, bir Java'da ne zaman kullanırsanız kullanın private, classözel üyelere nesne yönelimli olmayan bir veri yapısı örneğine sahipsiniz.