ก่อน OOP สมาชิกโครงสร้างข้อมูลถูกปล่อยให้เป็นสาธารณะหรือไม่


44

เมื่อโครงสร้างข้อมูล (ตัวอย่างเช่นคิว) ถูกนำไปใช้โดยใช้ภาษา OOP สมาชิกบางส่วนของโครงสร้างข้อมูลจะต้องเป็นส่วนตัว (ตัวอย่างเช่นจำนวนรายการในคิว)

คิวนอกจากนี้ยังสามารถนำมาใช้ในภาษากระบวนการใช้และชุดของฟังก์ชั่นที่ใช้งานบนstruct structอย่างไรก็ตามในภาษาขั้นตอนคุณไม่สามารถทำให้สมาชิกของstructเอกชน สมาชิกของโครงสร้างข้อมูลมีการใช้งานในภาษาขั้นตอนที่ปล่อยให้สาธารณะหรือมีเคล็ดลับที่จะทำให้พวกเขาเป็นส่วนตัวหรือไม่?


75
"สมาชิกบางคนของโครงสร้างข้อมูลจำเป็นต้องเป็นส่วนตัว"มีความแตกต่างอย่างมากระหว่าง "น่าจะเป็น" และ "ต้องเป็น" ให้ภาษา OO แก่ฉันและฉันรับประกันว่าฉันสามารถสร้างคิวที่ทำงานได้อย่างสมบูรณ์แบบแม้กับสมาชิกทุกคนและวิธีการของการเป็นสาธารณะตราบใดที่คุณไม่ไปใช้เสรีภาพในทางที่ผิด
8bittree

48
หากต้องการพูดถึงสิ่งที่ @ 8bittree พูดอย่างตรงไปตรงมาการมีทุกอย่างในที่สาธารณะเป็นสิ่งที่ดีถ้าคนที่ใช้รหัสของคุณมีระเบียบวินัยมากพอที่จะยึดติดกับอินเทอร์เฟซที่คุณกำหนดไว้ สมาชิกส่วนตัวสร้างขึ้นเพราะคนที่ไม่สามารถป้องกันไม่ให้จมูกของพวกเขาอยู่ที่ไหน
Blrfl

20
คุณหมายถึง "ก่อน encapsulation กลายเป็นที่นิยม"? Encapsulation ค่อนข้างเป็นที่นิยมก่อนที่ภาษา OO จะได้รับความนิยม
Frank Hileman

6
@ FrankHileman ฉันคิดว่าจริง ๆ แล้วเป็นแกนหลักของคำถาม: OP ต้องการทราบว่ามี encapsulation อยู่ในภาษาที่ใช้ในขั้นตอนก่อนหน้า Simula / Smalltalk / C ++
dcorking

18
ฉันขอโทษล่วงหน้าหากสิ่งนี้เกิดขึ้นพร้อมกับการวางตัวฉันไม่ได้หมายความว่ามันจะเป็น คุณต้องเรียนรู้ภาษาอื่น การเขียนโปรแกรมภาษาไม่ได้สำหรับเครื่องจะทำงานได้ก็มีการเขียนโปรแกรมที่จะคิดใน พวกเขาจำเป็นต้องกำหนดรูปแบบที่คุณคิด คุณจะไม่มีคำถามนี้หากคุณใช้เวลาทำงานกับ JavaScript / Python / Ocaml / Clojure อย่างมีนัยสำคัญแม้ว่าคุณจะทำ Java ทั้งวันในงานประจำวันของคุณ นอกเหนือจากโครงการโอเพ่นซอร์ส C ++ มากกว่าหนึ่งที่ฉันทำงานอยู่ (ส่วนใหญ่เป็นภาษาซีอย่างไรก็ตาม) ฉันไม่ได้ใช้ภาษากับตัวดัดแปลงการเข้าถึงมาตั้งแต่เรียนมหาวิทยาลัยและฉันก็ไม่ได้คิดถึงพวกเขา
Jared Smith

คำตอบ:


139

OOP ไม่ได้คิดค้นการห่อหุ้มและไม่ได้มีความหมายเหมือนกันกับการห่อหุ้ม ภาษา OOP หลายภาษาไม่มีตัวดัดแปลงการเข้าถึงสไตล์ C ++ / Java ภาษาที่ไม่ใช่ OOP ส่วนใหญ่มีเทคนิคต่าง ๆ ที่พร้อมใช้งานเพื่อเสนอการห่อหุ้ม

วิธีการหนึ่งที่คลาสสิกสำหรับการห่อหุ้มเป็นปิดที่ใช้ในการเขียนโปรแกรมการทำงาน สิ่งนี้เก่ากว่า OOP อย่างมีนัยสำคัญ แต่มีวิธีที่เทียบเท่า เช่นใน 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ภาษาสนับสนุนบางชนิด encapsulation ผ่านไฟล์ส่วนหัวกลไกโดยเฉพาะอย่างยิ่งตัวชี้ทึบแสงเทคนิค ใน C เป็นไปได้ที่จะประกาศชื่อ struct โดยไม่ต้องกำหนดสมาชิก ณ จุดนั้นไม่มีตัวแปรชนิดของ struct นั้นสามารถใช้ได้ แต่เราสามารถใช้พอยน์เตอร์กับ struct นั้นได้อย่างอิสระ (เนื่องจากขนาดของตัวชี้ struct นั้นเป็นที่รู้จักในเวลารวบรวม) ตัวอย่างเช่นพิจารณาไฟล์ส่วนหัวนี้:

#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 รวมถึงวิธีการที่น่าสนใจที่จะเรียกว่าโมดูลfunctors OOP มีการบดบังและการเขียนโปรแกรมแบบโมดูลย่อยส่วนใหญ่ แต่ข้อได้เปรียบที่ได้รับจาก OOP นั้นมีความหลากหลายมากกว่าการวางแนววัตถุ

นอกจากนี้ยังมีข้อสังเกตว่าคลาสในภาษา OOP เช่น C ++ หรือ Java มักจะไม่ใช้สำหรับวัตถุ (ในแง่ของเอนทิตีที่แก้ไขการดำเนินงานผ่านการเชื่อมโยงล่าช้า / การจัดส่งแบบไดนามิก) แต่สำหรับประเภทข้อมูลนามธรรม (ที่เรากำหนดอินเทอร์เฟซสาธารณะ รายละเอียดการใช้งานภายใน) กระดาษในการทำความเข้าใจข้อมูลที่เป็นนามธรรม, Revisited (Cook, 2009) กล่าวถึงความแตกต่างในรายละเอียดเพิ่มเติมนี้

แต่ใช่หลายภาษาไม่มีกลไกการห่อหุ้ม แต่อย่างใด ในภาษาเหล่านี้สมาชิกโครงสร้างจะถูกปล่อยให้เป็นสาธารณะ อย่างน้อยที่สุดก็จะมีการตั้งชื่อการใช้งานท้อใจ เช่นฉันคิดว่า Pascal ไม่มีกลไกการห่อหุ้มที่เป็นประโยชน์


11
ดูข้อผิดพลาดAdder self = malloc(sizeof(Adder));ใช่หรือไม่ มีเหตุผลที่เป็นพอยน์เตอร์ที่พิมพ์ออกมาและsizeof(TYPE)ขมวดคิ้วอยู่ทั่วไป
Deduplicator

10
คุณไม่สามารถเขียนsizeof(*Adder)ได้เพราะ*Adderไม่ใช่ประเภทเช่นเดียวกับที่*int *ไม่ใช่ประเภท การแสดงออกT t = malloc(sizeof *t)มีทั้งสำนวนและถูกต้อง ดูการแก้ไขของฉัน
wchargin

4
ปาสคาลมีตัวแปรหน่วยที่ไม่สามารถมองเห็นได้จากภายนอกหน่วยนั้น อย่างมีประสิทธิภาพตัวแปรหน่วยเทียบเท่ากับprivate staticตัวแปรใน Java เช่นเดียวกันกับ C คุณสามารถใช้ตัวชี้ทึบแสงเพื่อส่งผ่านข้อมูลใน Pascal โดยไม่ต้องประกาศว่าเป็นอะไร Classic MacOS ใช้ตัวชี้ทึบแสงจำนวนมากเนื่องจากส่วนสาธารณะและส่วนตัวของระเบียน (โครงสร้างข้อมูล) อาจส่งผ่านกัน ฉันจำได้ว่า Window Manager ทำสิ่งนี้มากมายเนื่องจากบางส่วนของ Window Record เป็นข้อมูลสาธารณะ แต่มีข้อมูลภายในบางอย่างรวมอยู่ด้วย
Michael Shopsin

6
บางทีตัวอย่างที่ดีกว่า Pascal ก็คือ Python ซึ่งรองรับการวางแนวของวัตถุ แต่ไม่มีการห่อหุ้มโดยหันไปใช้หลักการตั้งชื่อเช่น_private_memberและoutput_property_หรือเทคนิคขั้นสูงสำหรับการสร้างวัตถุที่จำลองได้
Mephy

11
มีแนวโน้มที่น่ารำคาญในวรรณคดีของ OOD ที่จะนำเสนอหลักการออกแบบทุกประการเป็นหลักการออกแบบOO วรรณกรรม OOD (ที่ไม่ใช่เชิงวิชาการ) มีแนวโน้มที่จะวาดภาพของ "ยุคมืด" ที่ทุกคนทำทุกอย่างผิดปกติและจากนั้นผู้ปฏิบัติงานของ OOP ก็นำความสว่างมาให้ เท่าที่ฉันสามารถบอกได้สิ่งนี้ส่วนใหญ่มาจากความไม่รู้ ตัวอย่างเช่นเท่าที่ฉันสามารถบอกได้ Bob Martin ให้รูปลักษณ์การเขียนโปรแกรมที่ใช้งานได้อย่างจริงจังเมื่อไม่กี่ปีที่ผ่านมา
Derek Elkins

31

ประการแรกการเป็นเชิงเปรียบเทียบกับออบเจกต์ไม่เกี่ยวกับ public vs private ภาษาเชิงวัตถุจำนวนมากไม่มีความคิดเรื่องการควบคุมการเข้าถึง

ประการที่สองใน "C" - ซึ่งคนส่วนใหญ่จะเรียกขั้นตอนและไม่ใช่เชิงวัตถุมีเทคนิคมากมายที่คุณสามารถใช้เพื่อทำให้สิ่งต่าง ๆ เป็นส่วนตัวได้อย่างมีประสิทธิภาพ ที่พบบ่อยมากคือการใช้ตัวชี้ทึบแสง (เช่นโมฆะ *) หรือ - คุณสามารถส่งต่อประกาศวัตถุและไม่ได้กำหนดไว้ในไฟล์ส่วนหัว

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

ดู SDK ของ windows! มันใช้ HANDLE และ UINT_PTR และสิ่งต่าง ๆ เช่นที่จะจัดการทั่วไปกับหน่วยความจำที่ใช้ใน API - ทำให้การปรับใช้เป็นส่วนตัวอย่างมีประสิทธิภาพ


1
ตัวอย่างของฉันแสดงให้เห็นถึงวิธีการที่ดีกว่า (C) - การใช้ struct ที่ประกาศไปข้างหน้า เพื่อใช้วิธี void * ฉันจะใช้ typedefs: ในไฟล์. h พูด typedef void * queue แล้วทุกที่ที่เรามี struct struct เพียงแค่พูดว่าคิว; จากนั้นในไฟล์. c ให้เปลี่ยนชื่อ struct struct เป็น struct queImpl และอาร์กิวเมนต์ใด ๆ กลายเป็นคิว (isntead ของ struct คิว *) และบรรทัดแรกของรหัสสำหรับแต่ละฟังก์ชันดังกล่าวจะกลายเป็น struct queImpl * qi = (struct queImpl *) q
Lewis Pringle

7
อืมมม มันทำให้เป็นส่วนตัวเพราะคุณไม่สามารถเข้าถึง (อ่านหรือเขียน) ฟิลด์ใด ๆ ของ 'คิว' จากที่ใดก็ได้นอกเหนือจากการนำไปใช้ (ไฟล์ foo.c) ส่วนตัวคุณหมายถึงอะไรอีก BTW - เป็นจริงสำหรับทั้งโมฆะ typedef * apporach และ (ดีกว่า) ไปข้างหน้าประกาศแนวทาง struct
Lewis Pringle

5
ฉันต้องยอมรับว่ามันเกือบ 40 ปีแล้วตั้งแต่ฉันอ่านหนังสือใน smalltalk-80 แต่ฉันจำความคิดของสมาชิกข้อมูลสาธารณะหรือข้อมูลส่วนตัวไม่ได้ ฉันคิดว่า CLOS ก็ไม่มีความคิดเช่นนั้น Object Pascal ไม่มีความเห็นเช่นนั้น ฉันจำได้ว่า Simula ทำ (อาจเป็นที่ Stroustrup มีความคิด) และภาษา OO ส่วนใหญ่ตั้งแต่ C ++ มี อย่างไรก็ตามเราเห็นด้วยกับการห่อหุ้มและข้อมูลส่วนตัวเป็นความคิดที่ดี แม้แต่ผู้ถามดั้งเดิมก็ยังชัดเจนในประเด็นนั้น เขาแค่ถาม - คนชราทำ encapsulation ในภาษา pre-C ++ อย่างไร
Lewis Pringle

5
@LewisPringle ไม่มีการกล่าวถึงสมาชิกข้อมูลสาธารณะใน Smalltalk-80 เพราะ "อินสแตนซ์ตัวแปร" (สมาชิกข้อมูล) ทั้งหมดเป็นส่วนตัวยกเว้นว่าคุณใช้การสะท้อน AFAIU Smalltalkers เขียน accessor สำหรับทุกตัวแปรที่พวกเขาต้องการให้เป็นสาธารณะ
dcorking

4
@LewisPringle โดยคมชัดทุกสมอลล์ทอล์ค "วิธีการ" (สมาชิกฟังก์ชั่น) เป็นสาธารณะ (มีการประชุมเงอะงะสำหรับการทำเครื่องหมายไว้ส่วนตัว)
dcorking

13

"ประเภทข้อมูลทึบแสง" เป็นแนวคิดที่เป็นที่รู้จักกันดีเมื่อฉันสำเร็จการศึกษาด้านวิทยาศาสตร์คอมพิวเตอร์เมื่อ 30 ปีที่แล้ว เราไม่ได้ครอบคลุม OOP เนื่องจากไม่ใช่การใช้งานทั่วไปในเวลานั้นและ "การเขียนโปรแกรมเชิงฟังก์ชัน" ก็ถือว่าถูกต้องมากขึ้น

Modula-2 ได้รับการสนับสนุนโดยตรงสำหรับพวกเขาดูhttps://www.modula2.org/reference/modules.php

มันได้รับการอธิบายโดย Lewis Pringle ว่าการประกาศไปข้างหน้าสามารถใช้โครงสร้างใน C ได้อย่างไรซึ่งแตกต่างจากโมดูล -2 จึงต้องมีฟังก์ชันโรงงานเพื่อสร้างวัตถุ ( วิธีการเสมือนจริงยังง่ายต่อการใช้งานใน Cโดยให้สมาชิกคนแรกของ struct เป็นตัวชี้ไปยังโครงสร้างอื่นที่มีตัวชี้ฟังก์ชั่นกับวิธีการ)

มักใช้แบบแผน ตัวอย่างเช่นฟิลด์ใด ๆ ที่ขึ้นต้นด้วย“ _” ไม่ควรเข้าถึงนอกไฟล์ที่เป็นเจ้าของข้อมูล สิ่งนี้ถูกบังคับใช้อย่างง่ายดายโดยการสร้างเครื่องมือตรวจสอบที่กำหนดเอง

ทุกโครงการขนาดใหญ่ที่ฉันได้ทำงาน (ก่อนที่ฉันจะย้ายไปยัง C ++ จากนั้น C #) มีระบบในสถานที่เพื่อป้องกันการเข้าถึงข้อมูล "ส่วนตัว" โดยรหัสที่ไม่ถูกต้อง มันเป็นมาตรฐานน้อยกว่าตอนนี้เล็กน้อย


9

หมายเหตุมีหลายภาษา OO ที่ไม่มีความสามารถในการทำเครื่องหมายสมาชิกส่วนตัว สิ่งนี้สามารถทำได้โดยการประชุมโดยไม่ต้องใช้คอมไพเลอร์เพื่อบังคับใช้ความเป็นส่วนตัว ตัวอย่างเช่นคนมักจะนำหน้าตัวแปรส่วนตัวด้วยการขีดเส้นใต้

มีเทคนิคที่จะทำให้มันยากที่จะเข้าถึงตัวแปร "เอกชน" ที่พบมากที่สุดเป็นเป็นสำนวน PIMPL สิ่งนี้ทำให้ตัวแปรส่วนตัวของคุณอยู่ในโครงสร้างที่แยกต่างหากโดยมีเพียงตัวชี้ที่จัดสรรในไฟล์ส่วนหัวสาธารณะของคุณ นี่หมายถึงการเพิ่มช่องว่างและการส่งเพื่อรับตัวแปรส่วนตัวใด ๆ เช่น((private_impl)(obj->private))->actual_valueที่น่ารำคาญดังนั้นในทางปฏิบัติจึงไม่ค่อยได้ใช้


4

โครงสร้างข้อมูลไม่มี "สมาชิก" มีเพียงเขตข้อมูลเท่านั้น (สมมติว่าเป็นประเภทบันทึก) โดยทั่วไปการเปิดเผยจะถูกตั้งค่าสำหรับประเภททั้งหมด อย่างไรก็ตามนั่นอาจไม่ จำกัด ตามที่คุณคิดเพราะฟังก์ชั่นไม่ได้เป็นส่วนหนึ่งของบันทึก

ลองย้อนกลับไปและรับประวัติเล็กน้อยที่นี่ ...

กระบวนทัศน์การเขียนโปรแกรมที่โดดเด่นก่อน OOP ถูกเรียกว่าการเขียนโปรแกรมโครงสร้าง เป้าหมายหลักเริ่มต้นของสิ่งนี้คือการหลีกเลี่ยงการใช้คำสั่งกระโดดที่ไม่มีโครงสร้าง ("ข้ามไป") นี่เป็นกระบวนทัศน์ที่มุ่งเน้นการควบคุมการไหล (ในขณะที่ OOP นั้นมุ่งเน้นข้อมูลมากกว่า) แต่ก็ยังคงเป็นส่วนขยายตามปกติของมันในการพยายามที่จะรักษาโครงสร้างข้อมูลเชิงตรรกะเช่นเดียวกับรหัส

การเขียนโปรแกรมแบบมีโครงสร้างอีกชุดหนึ่งคือการซ่อนข้อมูลความคิดที่ว่าการใช้งานโครงสร้างของโค้ด (ซึ่งมีแนวโน้มที่จะเปลี่ยนแปลงได้บ่อยครั้ง) ควรถูกแยกออกจากอินเทอร์เฟซ ตอนนี้มันเป็นความเชื่อ แต่ในสมัยก่อนหลายคนคิดว่ามันดีกว่าสำหรับนักพัฒนาทุกคนที่จะได้รับรู้รายละเอียดของระบบทั้งหมดดังนั้นนี่เป็นครั้งเดียวที่ความคิดแย้ง ฉบับดั้งเดิมของเรื่องThe Mythical Man Monthของบรู๊คแย้งกับการซ่อนข้อมูล

ภาษาการเขียนโปรแกรมในภายหลังได้รับการออกแบบมาอย่างชัดเจนว่าเป็นภาษาโปรแกรมโครงสร้างที่ดี (ตัวอย่างเช่น Modula-2 และ Ada) โดยทั่วไปแล้วรวมข้อมูลที่ซ่อนอยู่ในแนวคิดพื้นฐานซึ่งสร้างขึ้นจากแนวคิดบางประการของสิ่งอำนวยความสะดวก วัตถุที่พวกเขาอาจจำเป็นต้องใช้) ใน Modula-2 สิ่งนี้เรียกว่า "Modules" ใน Ada "Packages" ภาษา OOP สมัยใหม่จำนวนมากเรียกว่า "เนมสเปซ" ในแนวคิดเดียวกัน เนมสเปซเหล่านี้เป็นรากฐานของการพัฒนาองค์กรในภาษาเหล่านี้และเพื่อจุดประสงค์ส่วนใหญ่สามารถใช้ในลักษณะเดียวกันกับคลาส OOP (โดยไม่มีการสนับสนุนที่แท้จริงสำหรับการสืบทอดแน่นอน)

ดังนั้นใน Modula-2 และ Ada (83) คุณสามารถประกาศรูทีนชนิดค่าคงที่หรือวัตถุใด ๆ ในเนมสเปซส่วนตัวหรือสาธารณะ แต่ถ้าคุณมีประเภทเร็กคอร์ดไม่มีวิธี (ง่าย) ในการประกาศเขตข้อมูลเร็กคอร์ดสาธารณะ และอื่น ๆ ส่วนตัว ไม่ว่าระเบียนทั้งหมดของคุณจะเป็นแบบสาธารณะหรือไม่ก็ตาม


ฉันใช้เวลาไปกับการทำงานที่ Ada การเลือกซ่อน (ส่วนหนึ่งของชนิดข้อมูล) เป็นสิ่งที่เราทำตลอดเวลา ในแพ็คเกจที่มีคุณจะต้องกำหนดประเภทของตัวเองเป็นส่วนตัวหรือ จำกัด ส่วนตัว อินเตอร์เฟสแพ็กเกจจะเปิดเผยฟังก์ชัน / โพรซีเดอร์สาธารณะเพื่อรับและ / หรือตั้งค่าฟิลด์ภายใน แน่นอนกิจวัตรเหล่านั้นจะต้องใช้พารามิเตอร์ประเภทส่วนตัว ฉันไม่ได้แล้วและไม่ได้พิจารณาเรื่องนี้ยาก
David

นอกจากนี้ AFAIK ภาษา OO ส่วนใหญ่ยังทำงานในลักษณะเดียวกันภายใต้ประทุนเช่น myWidget.getFoo () ถูกนำมาใช้จริง ๆ เช่นเดียวกับ getFoo (myWidget) การobject.method()ภาวนาเป็นเพียงวากยสัมพันธ์น้ำตาล IMHO สำคัญ - ดูหลักการเข้าถึง / อ้างอิงอ้างอิงของเมเยอร์ - แต่ยังคงเป็นเพียงน้ำตาลเชิงซ้อน
David

@David - นั่นคือข้อโต้แย้งของชุมชน Ada เป็นเวลาหลายปีในยุค Ada 95 ฉันเชื่อว่าในที่สุดพวกเขาก็ยอมแพ้และพิสูจน์ข้อโต้แย้งของตัวเองโดยอนุญาตให้object.method()เป็นรูปแบบทางเลือกmethod(object, ...) สำหรับคนที่ไม่สามารถก้าวข้ามความคิดได้
TED

0

ใน C คุณสามารถส่งผ่านพอยน์เตอร์ไปยังประกาศ แต่ยังไม่ได้กำหนดประเภทตามที่คนอื่นพูดในการ จำกัด การเข้าถึงทุกฟิลด์

นอกจากนี้คุณยังสามารถมีฟังก์ชั่นส่วนตัวและสาธารณะในแบบโมดูลต่อโมดูล ฟังก์ชั่นที่ประกาศคงที่ในไฟล์ต้นฉบับจะไม่สามารถมองเห็นได้จากภายนอกแม้ว่าคุณจะพยายามเดาชื่อของมันก็ตาม ในทำนองเดียวกันคุณสามารถมีตัวแปรโกลบอลระดับไฟล์สแตติกซึ่งเป็นแนวปฏิบัติที่ไม่ดี แต่อนุญาตให้แยกได้ตามโมดูล

อาจเป็นเรื่องสำคัญที่จะต้องเน้นว่าการ จำกัด การเข้าถึงเป็นแบบแผนที่ได้มาตรฐานมากกว่าการสร้างโครงสร้างที่บังคับใช้ภาษาได้ผลดี (ดู Python) ยิ่งไปกว่านั้นการ จำกัด การเข้าถึงฟิลด์วัตถุจะป้องกันโปรแกรมเมอร์เมื่อจำเป็นต้องเปลี่ยนค่าของข้อมูลภายในวัตถุหลังจากการสร้าง ซึ่งเป็นรหัสกลิ่นแล้ว เนื้อหาของซีและโดยเฉพาะอย่างยิ่งภาษา C ++ 's คำหลักสำหรับวิธีการและฟังก์ชั่นการขัดแย้งเป็นความช่วยเหลือที่ไกลมากขึ้นกว่าการเขียนโปรแกรมจาวาค่อนข้างยากจนconstfinal


ฟีเจอร์ C เดียวที่มีเพื่อการซ่อนข้อมูลโดยเฉพาะคือข้อมูลstaticทั่วโลกและการดำเนินงาน คุณอาจโต้เถียงใด ๆ ที่สนับสนุน C สำหรับแนวทางการออกแบบซอฟต์แวร์ที่ดีนอกเหนือจากที่แฮ็คค่อนข้างมากและไม่ได้เป็นส่วนหนึ่งของการออกแบบดั้งเดิมของภาษาย้อนกลับไปในปี 1972
TED

0

ถ้านิยามของสาธารณะเป็นความสามารถในการดำเนินงานและการเข้าถึงข้อมูล / คุณสมบัติรหัสผ่านของคุณเองที่จุดใดคำตอบคือเพียง: ใช่ อย่างไรก็ตามมันเป็นนามธรรมโดยวิธีการที่หลากหลาย - ขึ้นอยู่กับภาษา

ฉันหวังว่าสิ่งนี้จะตอบคำถามของคุณอย่างกระชับ


-1

นี่คือตัวอย่างการนับที่ง่ายมาก: ใน Java, interfaces กำหนดวัตถุ แต่classes ทำไม่ได้ A classกำหนดประเภทข้อมูลนามธรรมไม่ใช่วัตถุ

ดังนั้นทุกครั้งที่คุณใช้privateใน a classใน Java คุณมีตัวอย่างของโครงสร้างข้อมูลที่มีสมาชิกส่วนตัวที่ไม่ได้มุ่งเน้นวัตถุ


7
คำตอบนี้แน่นอนว่าถูกต้องทางเทคนิค แต่ก็ไม่สามารถเข้าใจได้อย่างสมบูรณ์สำหรับผู้ที่ไม่รู้ว่า ADT คืออะไรและแตกต่างจากวัตถุอย่างไร
amon

1
ฉันเรียนรู้บางอย่างจากคำตอบนี้
littleO

3
อินเทอร์เฟซไม่ "กำหนด" วัตถุ พวกเขาระบุสัญญาสำหรับการดำเนินงาน / พฤติกรรมที่วัตถุสามารถทำได้หรือดำเนินการ เช่นเดียวกับการสืบทอดโดยทั่วไปจะอธิบายโดยa คือความสัมพันธ์และองค์ประกอบโดย a มีความสัมพันธ์อินเตอร์เฟสโดยทั่วไปอธิบายโดยสามารถทำความสัมพันธ์ได้
code_dredd
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.