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

ในภาคการศึกษาแรกเราได้รับการแนะนำให้รู้จักกับแนวคิดของ OOP เช่นการห่อหุ้มการซ่อนข้อมูลการแยกส่วนการสืบทอดและอื่น ๆ ผ่านทาง Java และ UML (Java เป็นภาษาโปรแกรมแรกของฉัน)

วิธีที่ฉันเข้าใจ OOP เป็นวิธีจัดการความซับซ้อนของซอฟต์แวร์ แต่หลักการของมันไม่ได้ใหม่หรือไม่เหมือนใคร แต่เป็นหลักการที่เป็นสากลสำหรับสาขาวิศวกรรมทั้งหมด

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

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

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

ให้ฉันลองตอบคำถามทฤษฎีต่ำมาก :)

สิ่งที่คุณถามจริงๆคือ: ทำไมรวมถึงการสนับสนุน Object Orientation (OO) โดยตรงในภาษาเมื่อภาษาขั้นตอนสามารถใช้ในการออกแบบและเขียนรหัส OO ได้

และคำตอบคือ: เพื่อให้มีมาตรฐานสำหรับวิธีการที่ OO แสดงในซอร์สโค้ดดังนั้นคุณไม่ต้องจบด้วยการใช้งาน 22 แบบที่แตกต่างกันสำหรับสิ่งที่เป็นนามธรรม

ตัวอย่างเช่นสมมติว่าฉันสร้าง a MagicButtonและ a MagicSliderซึ่งสามารถใช้ในระบบส่วนต่อประสานผู้ใช้ ฉันต้องการวิธีการจัดกลุ่มวิธีการที่สามารถใช้กับ MagicButton วิธีการที่สามารถใช้ได้กับ MagicSlider เท่านั้นและวิธีการที่ทั้งสองสามารถใช้ได้ วัตถุเหล่านี้แบ่งปันวิธีการบางอย่างเพราะพวกเขาทั้งสองวัตถุเวทมนตร์กุย

ฉันสามารถทำการจัดกลุ่มด้วยการตั้งชื่อฟังก์ชั่นในวิธีพิเศษMagicSlider_DoSomething ...โดยรวมวิธีการในไฟล์เฉพาะที่ตั้งชื่อด้วยวิธีพิเศษMagicSliderMethods.XXXหรือฉันสามารถหาวิธีพิเศษอื่น ๆ เพื่อทำสิ่งเดียวกัน หากไม่มีวิธีมาตรฐานในภาษาที่จะทำฉันจะทำมันแตกต่างจากคุณและแตกต่างจากคนอื่น ทำให้การแบ่งปันรหัสทำได้ยากขึ้น

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

ลองคิดถึงนักพัฒนาการบำรุงรักษาที่ไม่ดี บุคคลนี้ต้องจัดการ abstractions วัตถุที่แตกต่างกันและวิธีที่แตกต่างในการเรียกใช้วิธีเสมือนขึ้นอยู่กับผู้เขียนรหัสต้นฉบับ

นอกจากนี้: การมี abstractions ในภาษาช่วยให้โค้ดโค้ดขั้นสูงเช่น Eclipse ทำการวิเคราะห์สแตติกจำนวนมากบนโค้ด ตัวอย่างเช่น Eclipse สามารถเสนอรายการของวิธีการทั้งหมดที่สามารถใช้กับวัตถุได้เช่นเดียวกับการใช้งานอัตโนมัติของวิธีการ "สิ่งที่ต้องทำ" ที่ว่างเปล่า Eclispe รู้วิธีการที่คลาสของคุณต้องใช้โดยขึ้นอยู่กับว่าคุณขยายคลาสใดและอินเทอร์เฟซใดที่คุณใช้ นี่คงเป็นไปไม่ได้เลยหากไม่มีมาตรฐานภาษาที่จะทำ OO

ในภาคการศึกษาแรกเราได้รับการแนะนำให้รู้จักกับแนวคิดของ OOP เช่นการห่อหุ้มการซ่อนข้อมูลการแยกส่วนการสืบทอดและอื่น ๆ ผ่านทาง Java และ UML (Java เป็นภาษาโปรแกรมแรกของฉัน)

สิ่งเหล่านี้ไม่ใช่แนวคิดของ OOP พวกเขาทั้งหมดอยู่นอก OO เป็นอิสระจาก OO และหลายคนถูกคิดค้นขึ้นมาก่อน OO

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

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

ในขณะที่Data Abstractionมีความสำคัญใน OO มันเป็นผลมาจากคุณสมบัติหลักของ OO (Messaging) มากกว่าคุณสมบัติที่กำหนดไว้ นอกจากนี้เป็นสิ่งสำคัญที่ต้องจำไว้ว่ามีนามธรรมของข้อมูลที่แตกต่างกัน ทั้งสองชนิดที่พบบ่อยที่สุดของนามธรรมข้อมูลที่ใช้อยู่ในปัจจุบัน (ถ้าเราไม่สนใจ "นามธรรมใด ๆ" ซึ่งอาจจะยังคงใช้มากกว่าอีกสองคนรวมกัน) เป็นชนิดข้อมูลนามธรรมและวัตถุ ดังนั้นเพียงแค่พูดว่า "การซ่อนข้อมูล", "Encapsulation" และ "Data Abstraction" คุณไม่ได้พูดอะไรเกี่ยวกับ OO เนื่องจาก OO เป็นเพียงรูปแบบหนึ่งของ Data Abstraction และทั้งสองมีความแตกต่างกันโดยพื้นฐาน:

• กับชนิดข้อมูลนามธรรมกลไกสำหรับนามธรรมเป็นระบบการพิมพ์ ; เป็นระบบชนิดที่ซ่อนการนำไปใช้งาน (ระบบประเภทไม่จำเป็นต้องเป็นแบบคงที่) ด้วย Objects การนำไปใช้งานจะถูกซ่อนไว้ด้านหลังส่วนต่อประสานงานขั้นตอนซึ่งไม่ต้องการประเภท (ตัวอย่างเช่นสามารถใช้กับการปิดได้เช่นเดียวกับที่ทำใน ECMAScript)
• ด้วยประเภทข้อมูลนามธรรมอินสแตนซ์ของ ADT ที่แตกต่างกันนั้นถูกห่อหุ้มจากกันและกัน แต่อินสแตนซ์ของADT เดียวกันนั้นสามารถตรวจสอบและเข้าถึงการเป็นตัวแทนของกันและกันและการนำไปใช้ส่วนตัว วัตถุที่มีการเสมอห่อหุ้มจากทุกอย่าง เพียงวัตถุที่ตัวเองสามารถตรวจสอบการเป็นตัวแทนของตัวเองและการเข้าถึงการใช้งานส่วนตัว ไม่มีวัตถุอื่น ๆแม้แต่วัตถุชนิดเดียวกันอินสแตนซ์อื่นของคลาสเดียวกันวัตถุอื่นที่มีต้นแบบเดียวกันโคลนของวัตถุหรืออะไรก็ตามที่ทำได้ ไม่มีเลย

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

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

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

สิ่งที่คุณอธิบายคือ OO

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

การวางแนววัตถุนั้นเกี่ยวกับการส่งข้อความ ( การจัดส่งไดนามิก ) คำว่า "Object Oriented" จัดทำโดย Dr. Alan Kay ผู้ออกแบบหลักของ Smalltalk และเขานิยามดังนี้:

OOP สำหรับฉันหมายถึงเพียงการส่งข้อความการเก็บรักษาในท้องถิ่นและการป้องกันและการซ่อนกระบวนการของรัฐและการผูกมัดปลายสุดของทุกสิ่ง

มาทำลายมันกันเถอะ:

• ส่งข้อความ ("การกระจายวิธีการเสมือน" หากคุณไม่คุ้นเคยกับ Smalltalk)
• กระบวนการของรัฐควรจะเป็น
  • เก็บไว้ในเครื่อง
  • มีการป้องกัน
  • ซ่อนเร้น
• สุดขีดผูกพันทุกสิ่ง

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

ในภายหลังเขาชี้แจงว่า " ความคิดใหญ่คือ 'การส่งข้อความ' " และรู้สึกเสียใจที่ได้เรียกมันว่า "เชิงวัตถุ" แทนที่จะเป็น "ข้อความเชิง" เพราะคำว่า "เชิงวัตถุ" ให้ความสำคัญกับสิ่งที่ไม่สำคัญ (วัตถุ ) และเบี่ยงเบนความสนใจจากสิ่งที่สำคัญจริงๆ (การส่งข้อความ):

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

แนวคิดหลักคือ "การส่งข้อความ" - นั่นคือสิ่งที่ kernal ของ Smalltalk / Squeak เป็นเรื่องเกี่ยวกับ (และเป็นสิ่งที่ไม่เคยเสร็จสมบูรณ์ในระยะ Xerox PARC ของเรา) ภาษาญี่ปุ่นมีคำขนาดเล็ก - มา - สำหรับ "สิ่งที่อยู่ระหว่าง" - อาจเทียบเท่าภาษาอังกฤษที่ใกล้ที่สุดคือ "คั่นระหว่างหน้า" กุญแจสำคัญในการทำให้ระบบที่ยอดเยี่ยมและเติบโตได้นั้นมีมากขึ้นในการออกแบบว่าโมดูลสื่อสารได้อย่างไรมากกว่าคุณสมบัติและพฤติกรรมภายในของมัน คิดถึงอินเทอร์เน็ต - เพื่อการมีชีวิตอยู่ (ก) ต้องอนุญาตให้มีความคิดและการรับรู้ที่แตกต่างหลากหลายซึ่งอยู่นอกเหนือมาตรฐานเดียวและ (b) เพื่อให้การทำงานร่วมกันอย่างปลอดภัยระหว่างความคิดเหล่านี้มีระดับแตกต่างกัน

(แน่นอนวันนี้ผู้คนส่วนใหญ่ไม่ได้สนใจวัตถุ แต่เรียนซึ่งผิดยิ่งกว่า)

การส่งข้อความเป็นพื้นฐานของ OO ทั้งในฐานะคำอุปมาและเป็นกลไก

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

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

ดังนั้นมีสองวิธีในการดูคำจำกัดความของ Alan Kay: หากคุณมองมันด้วยตนเองคุณอาจสังเกตว่าการส่งข้อความนั้นเป็นการเรียกขั้นตอนที่ล่าช้าและการผูกปลายหมายถึงการห่อหุ้มดังนั้นเราจึงสามารถสรุปได้ว่า # 1 และ # 2 ซ้ำซ้อนจริง ๆ และ OO นั้นเกี่ยวกับการผูกสาย

อย่างไรก็ตามในภายหลังเขาชี้แจงว่าสิ่งสำคัญคือการส่งข้อความและเพื่อให้เราสามารถดูได้จากมุมที่แตกต่าง: การส่งข้อความนั้นล่าช้า ตอนนี้ถ้าการส่งข้อความเป็นเพียงสิ่งที่เป็นไปได้แล้ว # 3 จะนิด ๆ เป็นจริง: หากมีเพียงสิ่งหนึ่งและสิ่งที่เป็นปลายที่ถูกผูกไว้แล้วทุกสิ่งที่มีขอบล่าช้า และอีกครั้ง encapsulation ตามมาจากการส่งข้อความ

ประเด็นที่คล้ายกันนี้จัดทำขึ้นในการทำความเข้าใจเกี่ยวกับข้อมูลที่เป็นนามธรรม RevisitedโดยWilliam R. Cookและข้อเสนอของเขาสำหรับประยุกต์คำจำกัดความที่ทันสมัยของ "Object" และ "Object Oriented" :

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

ใน Smalltalk-72 ไม่มีแม้แต่วัตถุใด ๆ ! มีเฉพาะสตรีมข้อความที่แยกวิเคราะห์เขียนใหม่และเปลี่ยนเส้นทางใหม่ วิธีมาก่อน (วิธีมาตรฐานในการแยกวิเคราะห์และเปลี่ยนเส้นทางสตรีมข้อความ) มาวัตถุในภายหลัง (การจัดกลุ่มของวิธีการที่ใช้ร่วมกันบางรัฐส่วนตัว) การสืบทอดมามากในภายหลังและชั้นเรียนได้รับการแนะนำเป็นเพียงวิธีการในการสนับสนุนการสืบทอด หากกลุ่มวิจัยของเคย์รู้เรื่องต้นแบบแล้วพวกเขาอาจจะไม่เคยเข้าชั้นเรียนตั้งแต่แรก

เบนจามินเพียร์ซในประเภทและการเขียนโปรแกรมภาษาระบุว่าการกำหนดคุณสมบัติของวัตถุปฐมนิเทศคือเปิด Recursion

ดังนั้นตาม Alan Kay, OO คือทั้งหมดที่เกี่ยวกับการส่งข้อความ ตามที่ William Cook, OO เป็นข้อมูลเกี่ยวกับวิธีการจัดส่งแบบไดนามิก (ซึ่งเป็นสิ่งเดียวกันจริงๆ) ตามข้อมูลของเบนจามินเพียร์ซ OO เป็นข้อมูลเกี่ยวกับ Open Recursion ซึ่งโดยทั่วไปหมายความว่าการอ้างอิงตนเองนั้นได้รับการแก้ไขแบบไดนามิก (หรืออย่างน้อยนั่นก็เป็นวิธีคิด) หรือพูดอีกอย่างคือการส่งข้อความ

อย่างที่คุณเห็นคนที่เป็นคนบัญญัติศัพท์คำว่า "OO" นั้นมีมุมมองทางอภิปรัชญาค่อนข้างสูงบนวัตถุ Cook มีมุมมองเชิงปฏิบัติมากกว่าและเพียร์ซมีมุมมองทางคณิตศาสตร์ที่เข้มงวดมาก แต่สิ่งที่สำคัญคือนักปรัชญานักปฏิบัตินิยมและนักทฤษฎีล้วนเห็นด้วย! การส่งข้อความเป็นเสาหลักเดียวของ OO ระยะเวลา

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

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

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

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

สำหรับโปรแกรมของเล่นหลายประเภทที่นักเรียน CS ได้รับมอบหมายจากการเขียนเราสามารถเขียนมันในภาษาเบสิกหรือแอสเซมบลีเป็น Java หรือ Python นั่นเป็นเพราะความซับซ้อนโดยธรรมชาติของงานต่ำมากมีเพียงผู้พัฒนาเดียวไม่มีปัญหาการทำงานร่วมกันแบบดั้งเดิมประสิทธิภาพไม่สำคัญและรหัสจะมีแนวโน้มที่จะทำงานเพียงไม่กี่ครั้งในเครื่องเดียว

ลองนึกภาพการขับรถนักเรียนและขอให้พวกเขารวมเข้ากับถนนที่วุ่นวายในชั่วโมงเร่งด่วนในการส่งด้วยตนเองโดยไม่มี synchromesh มุ่งหน้าขึ้นเขาสูงชัน ภัยพิบัติ ทำไม? พวกเขาไม่สามารถจัดการระดับความซับซ้อนที่จำเป็นในการปฏิบัติตามกฎทั้งหมดที่งานต้องการพร้อมกัน

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

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

โปรแกรมเมอร์ที่มีทักษะเพียงพอและมีระเบียบวินัยสามารถสร้างระบบที่มีความซับซ้อนสูงใน C หรือการประกอบได้ แต่เราไม่ใช่ Linus Torvalds ทั้งหมด ไม่ควรที่เราจะต้องสร้างซอฟต์แวร์ที่มีประโยชน์

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

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

สิ่งที่คุณกำลังอธิบายไม่ใช่ OOP มันเป็นนามธรรม สิ่งที่เป็นนามธรรมนั้นมีอยู่ในการออกแบบที่ทันสมัยทุกรุ่นแม้กระทั่งที่ไม่ใช่ OOP และ OOP ก็เป็นนามธรรมที่เฉพาะเจาะจง

อย่างแรกมันก็น่าสังเกตว่าไม่มีคำจำกัดความของ OOP ดังนั้นอาจมีคนที่ไม่เห็นด้วยกับสิ่งที่ฉันเป็นลักษณะ OOP

ประการที่สองสิ่งสำคัญคือต้องจำไว้ว่า OOP ได้รับแรงบันดาลใจจากรูปแบบการออกแบบดั้งเดิมดังนั้นความคล้ายคลึงกันของการออกแบบรถยนต์จึงไม่ใช่เรื่องบังเอิญ

อย่างไรก็ตามนี่คือวิธีการบางอย่างที่ OOP เหมาะสมยิ่งกว่าที่คุณพูด:

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

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

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

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

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

เราต้องการภาษา OO เพื่อจัดการความซับซ้อนของซอฟต์แวร์หรือไม่?

ขึ้นอยู่กับความหมายของคำว่า "ต้องการ"

หาก "ต้องการ" หมายถึงต้องการเราก็ไม่จำเป็นต้องใช้

หาก "ต้องการ" หมายถึง "ให้ผลประโยชน์ที่รัดกุม" จากนั้นฉันจะบอกว่า "ใช่" เราต้องการ

ภาพใหญ่

ภาษา OO ผูกฟังก์ชันการทำงานกับข้อมูล

คุณสามารถหลีกเลี่ยงการผูกและเขียนฟังก์ชั่นที่ผ่านรอบค่าข้อมูล

แต่คุณอาจจะจบลงด้วยกลุ่มข้อมูลที่รวมตัวกันและคุณจะเริ่มผ่านสิ่งอันดับบันทึกหรือพจนานุกรมข้อมูล

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

คุณสมบัติตามคุณสมบัติ

คุณสมบัติของ OOP:

• Inheritanceอนุญาตให้ใช้โค้ด (มิกซ์อิน) และแนวคิด (Abstract Base Classes / interfaces) นำมาใช้ใหม่ - แต่คุณสามารถรับสิ่งนี้ได้โดยการทำซ้ำฟังก์ชันและตัวแปรในขอบเขตย่อย
• การห่อหุ้มช่วยให้สามารถซ่อนข้อมูลเพื่อให้เราสามารถทำงานในระดับที่สูงขึ้นของนามธรรม - แต่คุณสามารถทำได้ด้วยไฟล์ส่วนหัวฟังก์ชั่นและโมดูล
• polymorphismช่วยให้เราสามารถใช้การขัดแย้งของประเภทที่แตกต่างกันตราบใดที่ข้อโต้แย้งผู้สนับสนุนอินเตอร์เฟซเดียวกัน - แต่เราสามารถทำกับฟังก์ชั่นเช่นกัน

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

อ้างอิง

มีนักวิจารณ์ OOPมากมาย

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

ข้อสรุป

เราไม่ "ต้องการ" OOP แต่ในบางกรณีผู้ใช้ต้องการ OOP

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

ฉันจะพยายามสรุป

หลักการหลักของ OO คือการรวมกันของข้อมูลและพฤติกรรมในหน่วยองค์กรเดียว (วัตถุ)

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

เมื่อคุณมีชุดของข้อมูลและตรรกะร่วมกันสร้างแบบจำลองเอนทิตี้ของโลกแห่งความจริงคุณสามารถเริ่มต้นการแลกเปลี่ยนข้อความสร้างคลาสลูกแยกส่วนบุคคลจากข้อมูลสาธารณะและพฤติกรรม

ดังนั้นใช่ OO เป็นเรื่องใหญ่ และไม่ใช่มันไม่ใช่แค่ของโบราณที่มีชื่อแฟนซี

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

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

Encapsulation และ modularity เป็นหลักการพื้นฐานของการออกแบบมากขึ้นและควรนำไปใช้ในกระบวนทัศน์การเขียนโปรแกรมทั้งหมด ผู้เสนอ OO ไม่ได้อ้างว่าคุณสมบัติเหล่านี้สามารถทำได้กับ OO เท่านั้น - เฉพาะที่ OO นั้นเหมาะสมอย่างยิ่งที่จะบรรลุเป้าหมายนี้ แน่นอนผู้เสนอกระบวนทัศน์อื่น ๆ เช่นพูดว่าการเขียนโปรแกรมฟังก์ชั่นเรียกร้องเดียวกันสำหรับกระบวนทัศน์ของพวกเขา ในทางปฏิบัติภาษาที่ประสบความสำเร็จจำนวนมากนั้นมีกระบวนทัศน์แบบหลากหลายและ OO ควรมีการใช้งาน ฯลฯ เป็นเครื่องมือแทนที่จะเป็น

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

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

คำตอบอื่น ๆ ที่ไม่ได้กล่าวถึง: รัฐ

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

สิ่งที่ฉันคิดว่าเรากำลังพูดถึงคือความซับซ้อนที่เกี่ยวข้องกับรัฐ

มีสองความคิดหลักที่อยู่เบื้องหลังมีการห่อหุ้ม หนึ่งในนั้นคือการซ่อนรายละเอียดการใช้งานซึ่งค่อนข้างครอบคลุมในคำตอบอื่น ๆ แต่อีกสิ่งหนึ่งซ่อนสถานะของเวลาทำงานไว้ เราไม่เข้าไปยุ่งกับข้อมูลภายในของวัตถุ เราส่งข้อความ (หรือวิธีการโทรหากคุณต้องการรายละเอียดการใช้งานมากกว่าแนวคิดตามJörg Mittag ชี้ให้เห็น) ทำไม?

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

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

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

ในทางกลับกัน OO เสนอเครื่องมือในการจัดการกับสถานะการจัดการ (แทนที่จะเป็นเครื่องมือสำหรับหลีกเลี่ยง) นอกจากเครื่องมือระดับภาษาเช่นตัวดัดแปลงการเข้าถึง (ป้องกัน / สาธารณะ / ส่วนตัว), ตัวรับและตัวตั้งค่า ฯลฯ ยังมีข้อตกลงที่เกี่ยวข้องอีกหลายอย่างเช่นกฎแห่ง Demeter ซึ่งแนะนำให้เข้าถึงวัตถุผ่านข้อมูลอื่น ๆ .

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

เราต้องการภาษา OO เพื่อจัดการความซับซ้อนของซอฟต์แวร์หรือไม่?

ไม่ได้ แต่พวกเขาสามารถช่วยได้ในหลาย ๆ สถานการณ์

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

ตัวอย่างเช่นแอปพลิเคชัน Windows ที่ใช้ Windows API ระดับต่ำดั้งเดิมเพื่อแสดงฟอร์มปุ่มและฟิลด์แก้ไขต้องใช้รหัสจำนวนมากในขณะที่ใช้ไลบรารีของวัตถุที่มาพร้อมกับ Visual Basic หรือ C # หรือ Delphi แทน โปรแกรมเล็กและไม่สำคัญ ดังนั้นรหัส OO ของฉันมักจะค่อนข้างเล็กและสำหรับ GUI ในขณะที่รหัสของฉันที่วัตถุเหล่านั้นเรียกใช้นั้นใหญ่กว่ามากและมักจะไม่เกี่ยวข้องกับการเป็น OO (แม้ว่ามันจะแตกต่างกันไปขึ้นอยู่กับปัญหาที่ฉันพยายามแก้ไข)

ฉันเคยเห็นโปรแกรม OO ที่ซับซ้อนเกินไปใช้กฎลึกลับที่ซับซ้อนเกี่ยวกับวิธีการนำวัตถุมาใช้และอาจง่ายกว่ามากหากเขียนโดยไม่มีแนวคิด OO ฉันยังได้เห็นสิ่งที่ตรงกันข้าม: ระบบที่ซับซ้อนร้องให้นำมาใช้ใหม่และทำให้ง่ายขึ้นโดยใช้วัตถุ

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

ในฐานะที่เป็นคนที่มีส่วนร่วมในโครงการขนาดใหญ่มากที่เขียนด้วยภาษา C ฉันสามารถพูดได้อย่างแน่นอนว่าคำตอบนั้นชัดเจน "ไม่"

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

โครงสร้างสนับสนุนองค์ประกอบ ตัวอย่างเช่นคุณสามารถมีตารางแฮชที่ล็อกซึ่งประกอบด้วยการล็อก mutex และตารางแฮชปกติ นี่ไม่ใช่การเขียนโปรแกรมเชิงวัตถุ ไม่มีการทำคลาสย่อย การประพันธ์เป็นเครื่องมือที่เก่ากว่าความคิดของการเขียนโปรแกรมเชิงวัตถุ

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

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

หากคุณพยายามหาตัวอย่างของการเขียนโปรแกรมเชิงวัตถุในเคอร์เนล Linux ฉันแน่ใจว่าการค้นหาตัวอย่างดังกล่าวนั้นยากมากเว้นแต่คุณจะขยายการเขียนโปรแกรมเชิงวัตถุเพื่อรวมงานมาตรฐานเช่น "การกำหนดอินเทอร์เฟซแล้วใช้งาน"

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

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

เหตุผลในการแนะนำกระบวนทัศน์การเขียนโปรแกรมรวมถึงวิธีการเชิงวัตถุคือการทำให้โปรแกรมที่ซับซ้อนและมีประสิทธิภาพมากขึ้นง่ายขึ้น ในนิตยสาร Byte ฉบับเดือนสิงหาคม 1981 Daniel Ingallsหนึ่งในผู้สร้างหลักของ Smalltalk ได้นิยาม "object oriented" ซึ่งเกี่ยวข้องกับความสามารถดังต่อไปนี้:

• การจัดการพื้นที่เก็บข้อมูลอัตโนมัติ
• ความสามารถในการแลกเปลี่ยนข้อความ
• อุปมาเหมือนกันที่ใช้กับการดำเนินงานทั้งหมดของภาษา
• ไม่มีส่วนประกอบใดขึ้นอยู่กับ internals ของส่วนประกอบอื่น (แบบแยกส่วน)
• โปรแกรมกำหนดพฤติกรรมของวัตถุเท่านั้นไม่ใช่ตัวแทน (polymorphism)
• แต่ละองค์ประกอบควรปรากฏในที่เดียวเท่านั้น (แฟคตอริ่ง)
• การใช้เครื่องเสมือนซึ่งเป็นอิสระจากฮาร์ดแวร์
• ทุกองค์ประกอบที่ผู้ใช้สามารถเข้าถึงได้ควรพร้อมใช้งานสำหรับการสังเกตและควบคุม (หลักการปฏิกิริยา)
• ไม่ควรมีคอนโทรลเลอร์ทั้งหมด (ไม่มีระบบปฏิบัติการ)

นี่เป็นหลักการที่อิงกัลระบุว่าเป็นข้อพิจารณาในการออกแบบการขับขี่สำหรับ SmallTalk-80 ที่พัฒนาโดย Xerox Parc Research ในบทความในนิตยสารดังกล่าวคุณสามารถอ่านคำอธิบายโดยละเอียดของแต่ละหลักการเหล่านี้และวิธีที่พวกเขามีส่วนร่วมในกระบวนทัศน์เชิงวัตถุตาม Ingalls

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

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

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

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

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

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

จุดมุ่งหมายคือ - จัดการซอฟท์แวซับซ้อน เป้าหมายไม่ใช่ "ใช้ภาษา OO"

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

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

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

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

ดังนั้นคุณสามารถเขียนโค้ดที่เข้ารหัสและ encapsulated ได้ดีเพราะทั้งสองเป็นแนวคิดที่แตกต่างกัน

Encapsulation ช่วยในการจัดการความซับซ้อนโดยอาศัยอยู่ใกล้กับความเป็นจริง

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

สิ่งหนึ่งที่ต้องจดจำคือ:
OOP ไม่ได้เกี่ยวกับคุณสมบัติทางภาษา มันเป็นเรื่องเกี่ยวกับวิธีการที่คุณโครงสร้างรหัสของคุณ

OOP เป็นวิธีคิดและการออกแบบสถาปัตยกรรมรหัสของคุณและสามารถทำได้ในภาษาใดก็ได้ โดยเฉพาะอย่างยิ่งสิ่งเหล่านี้รวมถึงภาษาที่ไม่ใช้ภาษา OO ระดับต่ำซึ่งเรียกว่า assembler และ C คุณสามารถทำการเขียนโปรแกรมเชิงวัตถุในแอสเซมเบลอร์และเคอร์เนล Linux ซึ่งเขียนด้วยภาษา C ค่อนข้างเชิงวัตถุในหลาย ๆ ด้าน .

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

ดังนั้นไม่เราไม่ต้องการภาษา OO ในการทำ OOP เป็นเพียงว่า OOP นั้นง่ายกว่ามากในการใช้ภาษา OO ที่เหมาะสม

การเขียนโปรแกรมเชิงวัตถุเป็นมากกว่าโมดูล + การห่อหุ้ม อย่างที่คุณพูดมันเป็นไปได้ที่จะใช้โมดูล + การห่อหุ้มในภาษาที่ไม่ใช่เชิงวัตถุ (ขั้นตอน) OOP เกี่ยวข้องกับมากกว่านั้น: มันเกี่ยวข้องกับวัตถุและวิธีการ ดังนั้นไม่ว่าจะไม่จับภาพ OOP ดูเช่นhttps://en.wikipedia.org/wiki/Object-oriented_programmingหรือแนะนำตำราเรียนที่ดีเกี่ยวกับ OOP

เหตุผลที่ใหญ่ที่สุดคือเนื่องจากโปรแกรมมีความซับซ้อนมากขึ้นคุณต้องทำให้บางส่วนของมันไม่สามารถมองเห็นได้จากส่วนอื่น ๆ หรือความซับซ้อนของแอพและจำนวนหน้าที่จะทำให้สมองของคุณไหลออกมาจากหูของคุณ

ลองจินตนาการถึงระบบ 100 คลาสแต่ละอันมีการดำเนินการประมาณ 20 ครั้งที่สามารถทำได้ นั่นคือ 2,000 ฟังก์ชัน อย่างไรก็ตามมีเพียง 500 รายการที่ดำเนินการอย่างสมบูรณ์เช่น 'บันทึก' และ 'ลบ' ในขณะที่ 1500 เป็นฟังก์ชันภายในที่มีการบำรุงรักษาเล็กน้อยหรือมีบทบาทด้านอรรถประโยชน์ พิจารณา;

// intentionally in a non-specific language!

setName(person, name) {
    nameParts = splitPersonName(name);
    person.firstName = nameParts[0];
    person.lastName = nameParts[1];
    person.modified = true;
}

splitPersonName(name) {
    var result = [];
    result.add(name.substring(0, name.indexOf(" ")));
    result.add(name.substring(name.indexOf(" ") + 1));
    return result;
}

ดังนั้นSetNameฟังก์ชั่นที่คนควรทำกับคน แต่SplitPersonNameเป็นฟังก์ชั่นยูทิลิตี้ที่ใช้โดยบุคคล

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

นั่นคือสิ่งที่publicและprivateทำ;

public class Person {
    public void setName(...) {...}
    private string[] splitPersonName(...) { ...}
}