OOP พัฒนาขึ้นอย่างไรเพื่อรวมแนวคิดของ Properties

ฉันมาจากพื้นหลัง C ++ และหมดทุกอย่าง C # ในงานปัจจุบันของฉันและฉันเพิ่งอ่านคำถามมากมายเกี่ยวกับความแตกต่างระหว่างฟิลด์สาธารณะและคุณสมบัติและสิ่งที่แตกต่างและกลับมาในรูปแบบนี้ คำถามพื้นฐาน (เช่นโพสต์ SO นี้และคำถามที่เชื่อมโยงทั้งหมดที่เกี่ยวข้อง) คำถามทั้งหมดเหล่านี้ได้รับการแก้ไขในแง่ของความแตกต่างในทางปฏิบัติที่ได้รับการมีอยู่ของระบบทรัพย์สิน แต่ฉันคิดว่ามันเป็นการดีที่จะเข้าใกล้เรื่องนี้ในแง่ของสิ่งที่นักออกแบบของทุกภาษาที่ตัดสินใจสนับสนุนคุณสมบัติในครั้งแรก สถานที่กำลังคิด (ตรวจสอบรายชื่อในบทความ Wikipedia ที่นี่) OOP วิวัฒนาการมาจาก C ++ / Java เพื่อขยายสู่บทความ Wikipedia ที่น่าสนใจว่าเป็นตัวกลางระหว่างวิธีการและข้อมูลสมาชิกอย่างไร

"นั่นคือคุณสมบัติจะอยู่ตรงกลางระหว่างรหัสสมาชิก (วิธีการ) และข้อมูลสมาชิก (ตัวแปรอินสแตนซ์) ของคลาสและคุณสมบัติให้ระดับการห่อหุ้มที่สูงกว่าเขตข้อมูลสาธารณะ"

MSDNเพิ่มพื้นหลังเพิ่มเติม:

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

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

มันคือทั้งหมดที่เกี่ยวกับ Encapsulation และหลักการเข้าถึงแบบฟอร์มเดียวกัน

วัตถุควรสามารถตอบกลับข้อความได้โดยการส่งคืนข้อมูลที่มีอยู่หรือใช้วิธีการ แต่ผู้ส่งไม่ควรบอกได้ว่าควรใช้วิธีใด หรือถ้าคุณดูจากด้านผู้ส่ง: ผู้ส่งควรสามารถเข้าถึงข้อมูลที่มีอยู่หรือเรียกใช้วิธีการผ่านอินเตอร์เฟซที่เหมือนกัน

มีหลายวิธีในการบรรลุเป้าหมายนี้:

• กำจัดข้อมูลทั้งหมดเพียงมีวิธี (Newspeak ทำสิ่งนี้)

  • รูปแบบที่ต่างไปจากเดิมอย่างสิ้นเชิงน้อยกว่า: กำจัดข้อมูลในส่วนต่อประสานสาธารณะเช่นทำให้ข้อมูลเป็นส่วนตัวเสมอในส่วนต่อประสานสาธารณะเปิดเผยเฉพาะวิธีการ (Smalltalk, Ruby ทำสิ่งนี้)

• กำจัดวิธีการทั้งหมดเพียงแค่มีข้อมูล (ตัวเองทำสิ่งนี้ "วิธีการ" เป็นเพียงMethodวัตถุที่กำหนดให้กับตัวแปรอินสแตนซ์ตัวแปรอินสแตนซ์จะถูกค้นหาด้วยการจัดส่งเสมือน)

• ทำให้ไม่มีความแตกต่างประโยคหรือความหมายระหว่างวิธีการและข้อมูล (Scala ไม่นี้การเข้าถึงข้อมูลเป็น syntactically แยกไม่ออกจากการเรียกวิธีการที่ไม่มีรายการอาร์กิวเมนต์ ( foo.bar) มอบหมายให้เขตข้อมูลเป็น syntactically แยกไม่ออกจากการเรียกวิธีการตั้งชื่อเป็นพิเศษ ( foo.bar = baz) ก็เช่นเดียวกัน เป็นfoo.bar_=(baz)เช่นเรียกวิธีการตั้งชื่อfoo_=และอ่านอย่างเดียวค่าสามารถแทนที่หรือดำเนินการโดยวิธีการที่ไม่มีรายการพารามิเตอร์ (คือval foo) ใน superclass สามารถแทนที่ A (หรือabstract valจะดำเนินการ) ในประเภทรองที่มีวิธีการdef foo)

อย่างไรก็ตาม Java ไม่ปฏิบัติตาม Uniform Access Principle ใน Java เป็นไปได้ที่จะแยกแยะระหว่างการเข้าถึงข้อมูลและการเรียกใช้เมธอด จะแตกต่างจากfoo.bar foo.bar()สาเหตุของเรื่องนี้ก็คือฟิลด์และวิธีการมีความหมายและความแตกต่าง syntactically

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

ดังนั้นนี่ไม่ได้แก้ไขปัญหา: คุณไม่สามารถแก้ไขได้โดยมีสองวิธีในการเข้าถึงสิ่งต่าง ๆ โดยการเพิ่มวิธีที่สามในการเข้าถึงสิ่งต่าง ๆ ! แม้ว่าวิธีที่สามนั้นจะดูเหมือนหนึ่งในสองวิธี แต่คุณจะยังมี (อย่างน้อย) สองวิธีที่ต่างกัน คุณสามารถแก้ไขได้โดยกำจัดทุกวิธียกเว้นวิธีเดียวหรือกำจัดความแตกต่าง

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

ฉันไม่แน่ใจ 100% แต่ฉันคิดว่าสิ่งต่าง ๆ อาจจะง่ายกว่าที่คุณคาดไว้ จากโรงเรียนการสร้างแบบจำลอง OO ของ 90's มีความต้องการสำหรับการสร้างแบบจำลองชั้นเรียนที่มีคุณสมบัติสมาชิกห่อหุ้มและเมื่อดำเนินการในภาษาเช่น C ++ หรือ Java นี้มักจะนำไปสู่รหัสที่มีจำนวนมากของ getters และ setters ดังนั้น "เสียง" รหัสสำหรับความต้องการค่อนข้างง่าย โปรดทราบว่าส่วนใหญ่ (อาจเป็นทั้งหมดไม่ได้ตรวจสอบสิ่งนี้) ภาษาที่ปรากฏในบทความ Wikipedia ที่เชื่อมโยงของคุณเริ่มที่จะแนะนำ "คุณสมบัติ" ของวัตถุเมื่อสิ้นสุดยุค 90 หรือหลังจากนั้น

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

คุณมีมันไปข้างหลัง (ชนิด) แลมบ์ดาแคลคูลัสมีพื้นฐานที่เป็นทางการสำหรับภาษาการเขียนโปรแกรมและเป็นเวลาหลายสิบปีแล้ว มันไม่มีฟิลด์

ในการสร้างแบบจำลองสภาวะที่ไม่แน่นอนคุณจะต้องสร้างสอง abstractions หนึ่งแสดงถึงการตั้งค่าบางสถานะและอีกอันที่ดึงสถานะนั้น (บทที่ 13 ในเวอร์ชันTaPLของฉันสำหรับการอ้างอิง) ฟังดูคุ้น ๆ ไหม? จากพื้นฐานทางทฤษฎี OO ไม่ได้มีวิวัฒนาการในการมีสิ่งนี้ OO อ่านภาษาการเขียนโปรแกรม 101 และก้าวไปข้างหน้า

จากมุมมองของการปฏิบัติมีแรงจูงใจที่ชัดเจนสองอย่าง คุณมาจากพื้นหลัง C ++ ดังนั้นสิ่งที่จะต้องเกิดขึ้นถ้าคุณมีเขตข้อมูลสาธารณะ - พูดว่า ... ข้อความในกล่องข้อความ จะเกิดอะไรขึ้นเมื่อคุณต้องการเปลี่ยนการออกแบบของคุณเพื่อให้ "เมื่อใดก็ตามที่กล่องข้อความนี้เปลี่ยนให้ทำสีฟ้า" คุณจะต้องฆ่าฟิลด์นั้นทำฟังก์ชั่นหนึ่งหรือสองและต่อตรรกะนั้นเนื่องจากคุณไม่สามารถไว้วางใจนักพัฒนาให้เรียก "UpdateTextbox" ได้ นี่เป็นการเปลี่ยนแปลงที่เปลี่ยนแปลงอย่างมากต่อ API ของคุณ (และน่าเสียดายที่การเปลี่ยนแปลงในการใช้คุณสมบัติของ. NET) การจัดเรียงของลักษณะการทำงานนี้ทั่วทุกสถานที่ใน API ของ Windows เนื่องจากเป็นเรื่องใหญ่ที่ Microsoft, C # อาจต้องการทำให้เจ็บปวดน้อยลง

แรงจูงใจที่ยิ่งใหญ่อื่น ๆ คือJava Beansและเครือญาติ เฟรมเวิร์กจำนวนหนึ่งถูกสร้างขึ้นเพื่อใช้การสะท้อน Java เพื่อค้นหาGetXและSetXจับคู่และปฏิบัติกับมันอย่างมีประสิทธิภาพเหมือนคุณสมบัติที่ทันสมัย แต่เนื่องจากพวกเขาไม่ได้สร้างภาษาจริงกรอบเหล่านี้จึงเปราะบางและไม่สวย หากคุณพิมพ์ชื่อสิ่งต่าง ๆ ก็จะเงียบลง หากมีการปรับโครงสร้างใหม่จะไม่มีสิ่งใดเคลื่อนย้ายอีกด้านของคุณสมบัติ และการทำทุกอย่างในฟิลด์ / รับ / ชุดสำเร็จรูปนั้นเป็นเรื่องละเอียดและน่าเบื่อ (แม้แต่สำหรับ Java!) เนื่องจาก C # ได้รับการพัฒนาส่วนใหญ่ในฐานะ "Java พร้อมบทเรียนที่เรียนรู้" ความเจ็บปวดนั้นเป็นหนึ่งในบทเรียนเหล่านั้น

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

ใน. net โดยเฉพาะคุณสมบัติมาจากวัน Visual Basic เก่าซึ่งมันเกิดขึ้นไม่เชิงวัตถุในวิธีที่เราคิดเกี่ยวกับมันวันนี้ มันถูกสร้างขึ้นเป็นส่วนใหญ่รอบ ๆ ระบบ COM ใหม่ที่ให้การดูแลทุกสิ่งอย่างไม่จำเป็นต้องเป็นคลาส แต่ในแง่ขององค์ประกอบซึ่งจะเปิดเผยคุณสมบัติที่สามารถเข้าถึงได้ทั้งในโค้ด แต่ในเอดิเตอร์กราฟิก เมื่อ VB และ C # ที่สร้างขึ้นใหม่ถูกรวมเข้ากับ. net VB ได้รับคุณสมบัติ OOP มากมายและพวกเขาเก็บคุณสมบัติไว้ตั้งแต่การลบออกจะเป็นขั้นตอนย้อนหลัง - ลองคิดดูว่าเครื่องมืออัปเดตโค้ดอัตโนมัติที่พวกเขามีใน Visual Studio นั้นเป็นอย่างไร แทนที่คุณสมบัติทั้งหมดของคุณด้วย getters และ setters และทำลายความเข้ากันได้กับ COM-libraries ทั้งหมด มันจะเป็นตรรกะที่จะสนับสนุนพวกเขาในทุก

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

คุณสมบัติมีข้อดีเหนือฟิลด์:

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

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

มันเป็นเรื่องของการดำเนินงานเมื่อเทียบกับความหมาย คุณสมบัติอยู่ใน OOP ก่อน C ++ หรือ Java เข้าสู่ฉาก (อยู่ที่นั่นด้วยความหยาบรอบ ๆ ขอบใน Simula และเป็นพื้นฐานของ Smalltalk) หน่วยงานที่มีคุณสมบัติแตกต่างจากแนวคิดที่มีค่าพร้อมรหัสแนบ การรับ & ตั้งค่าคำนำหน้าในบางภาษาใช้เพื่อทำน้ำโคลนเท่านั้น พวกเขาทำให้คุณตระหนักถึงความแตกต่างระหว่างเขตข้อมูลและคุณสมบัติโดยสมมติว่าเขตข้อมูลนั้นสามารถเข้าถึงได้โดยตรงโดยไม่ได้รับ / ตั้งค่าในลักษณะที่เป็นสำนวนต่อภาษาและสิ่งนั้นรั่วไหล

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

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

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

ไม่มีอะไรอย่างแน่นอน คุณสมบัติและ OOP ไม่มีส่วนเกี่ยวข้องกัน คุณสมบัติไม่มีอะไรมากไปกว่าน้ำตาลซินแทคติกสำหรับการเรียกใช้ฟังก์ชั่นดังนั้นจึงมีสิ่งที่แนบ OOP แบบเดียวกันทั้งหมดที่การเรียกใช้ฟังก์ชันทำซึ่งต้องบอกว่าไม่มี

Wikipedia นั้นไม่ถูกต้องอย่างสมบูรณ์ รูปแบบ getMember / setMember ที่คุณเห็นใน Java ให้ประโยชน์เหมือนกันทุกประการ (และข้อเสีย) เหมือนกับคุณสมบัติใน C # และคุณสามารถทำซ้ำรูปแบบนี้ได้แม้ใน C หากคุณต้องการ

คุณสมบัติใน C # ไม่มีอะไรมากไปกว่า syntactic-sugar ที่รองรับภาษา