เหตุใดจึงไม่มีคำจำกัดความที่สอดคล้องกันของแนวคิดที่สำคัญสำหรับ OOP

ฉันยังใหม่กับการเขียนโปรแกรมและสับสนเล็กน้อยจากการอ่าน \ ฟังการประชุมต่าง ๆ จากแหล่งต่าง ๆ :

การโปรแกรมเชิงวัตถุมีแนวคิด 4 หรือ 5 หรือไม่?

ในฐานะผู้มาใหม่ฉันเข้าใจว่านี่คือแนวคิด 5 ประการ:

• สิ่งที่เป็นนามธรรม
• มรดก
• encapsulation
• ความแตกต่าง
• modularity

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

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

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

การเขียนโปรแกรมเชิงวัตถุมีองค์ประกอบ 5 หรือ 4 หรือไม่

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

ในฐานะผู้มาใหม่ฉันเข้าใจว่านี่คือ 5 องค์ประกอบ:

นามธรรม, การสืบทอด, การห่อหุ้ม, ความหลากหลายและความเป็นโมดุล

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

Abstraction, Encapsulation และ Modularity นั้นมีส่วนเกี่ยวข้องกับรหัสน้อยกว่าและเกี่ยวกับวิธีที่คุณมองปัญหาวิธีที่คุณพยายามทำความเข้าใจปัญหานั้นและวิธีที่คุณออกแบบและจัดโครงสร้างโซลูชันในโค้ด

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

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

ยกตัวอย่างเช่นตัวอย่างคลาสสิกมักจะอ้างถึงหน่วยงานเช่นDog, Cat, Elephant, Seagull, Sharkฯลฯ มาใหม่ใน "OO" มักจะดูตัวอย่างดังกล่าวทันทีและคิดว่า"โอ้ฉันต้องนิติบุคคลฐานที่เรียกว่าAnimal"และพวกเขายังอาจจะจบลงกับคนอื่น ๆ หน่วยงานระดับกลางเช่นMammalและAmphibianในการสืบทอดมรดกที่เป็นระเบียบเรียบร้อยซึ่งมีคุณลักษณะที่แตกต่างกันในแต่ละอัน

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

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

โดยรวมแล้วความเข้าใจของคุณจะได้รับประสบการณ์มากมาย แนวคิดเหล่านั้นที่คุณได้เรียนรู้มานั้นเป็นการเริ่มต้นที่ดีมีแนวคิดมากมายที่คุณจะต้องเรียนรู้ไปพร้อมกัน (เช่นหลักการ "SOLID" และ "DRY") และคุณจะต้องใช้เวลานานในการวาง ทฤษฎีไปสู่การปฏิบัติกับปัญหาที่ซับซ้อนสูงจริง ๆ ก่อนที่จะมีการ "คลิก" เข้ามา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

จุดที่คล้ายกันจะทำยังในการทำความเข้าใจข้อมูลที่เป็นนามธรรมมาเยือนโดยวิลเลียมอาร์คุกและเขาเสนอแบบย่อ, คำจำกัดความที่ทันสมัยของ "วัตถุ" และ "Object Oriented"

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

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

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

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

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

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

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

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

แต่การคัดค้านที่แท้จริงของฉันต่อ Modularity คือมันไม่ได้เป็นกุญแจสำคัญในการเขียนโปรแกรม OO หรือภาษาการเขียนโปรแกรม OO เท่าที่ภาษาการเขียนโปรแกรมแบบดั้งเดิม Smalltalk-80 ไม่สนับสนุนโมดูลเลย และเมื่อคุณคิดถึงมันการสนับสนุนด้านภาษาสำหรับโมดูลใน OOPL ที่ใช้กันอย่างแพร่หลายก็คือ "อ่อนแอ"

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

^{ฉันไม่ได้มีส่วนร่วมในการถกเถียงเกี่ยวกับคุณลักษณะอีก 4 อย่างและ (ตัวอย่าง) ว่า "มรดก" รุ่นใดที่เป็นของแท้ OO นอกจากนี้ในขณะที่ Alan Kay ให้เครดิตกับการเขียนโปรแกรม OO ซึ่งไม่ได้แปลว่าคำจำกัดความของ OO / และ OOPL มีความสำคัญ เห็นได้ชัดว่านี่ไม่ใช่กรณี เขาเป็นแหล่งเผด็จการ แต่มีแหล่งข้อมูลอื่น ๆ ที่ให้คำจำกัดความอื่น ๆ สำหรับ OO & OOPLs ว่า (ในทางปฏิบัติ) มีน้ำหนักมากขึ้น}