เราจะสอน OO โดยไม่อ้างอิงวัตถุทางกายภาพจริงได้อย่างไร [ปิด]

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

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

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

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

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

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

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

ฉันไม่ชอบที่จะอ้างถึง Alan Kay ราวกับว่าเขาเป็นโมเสสส่งแท็บเล็ต ฉันเชื่อว่าเขาได้รับการฝึกฝนด้านคณิตศาสตร์และชีวภาพ ในฐานะนักคณิตศาสตร์เขาอาจมีความคุ้นเคยกับแลมบ์ดาแคลคูลัสซึ่งค่อนข้างเป็นนามธรรมไม่เกี่ยวข้องกับฮาร์ดแวร์ ใน LC คุณอาจพูดว่าทุกอย่างเป็น "วัตถุ" เช่นหมายเลข 0 และหมายเลข 1 เป็นวัตถุที่ประเมินสิ่งต่าง ๆ เมื่อได้รับการโต้แย้ง นั่นนำไปสู่ ​​Smalltalk ค่อนข้างดี แนวคิดของ "ข้อความ" คือเพื่อให้เราสามารถหลีกเลี่ยงการพูดคุยเกี่ยวกับฮาร์ดแวร์ คุณสามารถพูดได้ว่าเมื่อคุณเรียกใช้ฟังก์ชัน (หรือวิธีการของวัตถุ) ที่คุณกำลังส่งข้อความและเมื่อมันกลับมาก็จะส่งข้อความถึงคุณ (หรือเพื่อความต่อเนื่องของคุณ) นั่นคือวิธีการอธิบายวิธีการสื่อสารระหว่างโปรแกรมที่ทำงานแบบอะซิงโครนัสกับฮาร์ดแวร์แยกกัน ไม่เป็นไร, แต่สำหรับการเขียนโปรแกรมทั่วไปมันจะถูกพาไป ในการรับคุณค่าของแนวคิด OOP คุณไม่จำเป็นต้องปฏิเสธความเกี่ยวข้องของงานที่เป็นรูปธรรมที่คุณพยายามทำหรือปฏิเสธความเป็นรูปธรรมของฮาร์ดแวร์ที่คุณใช้งานอยู่ ฉันคิดว่าการสอนเกี่ยวกับ OOP ในแง่ของการเปรียบเทียบที่คล้ายคลึงกันทำให้คนคิดเกี่ยวกับการออกแบบซอฟต์แวร์มากเกินไปในแง่ของโครงสร้างข้อมูลที่นำไปสู่การออกแบบที่มากเกินไปนำไปสู่ปัญหาการขยายตัวของโค้ดและการทำงานขนาดใหญ่ มันแย่พอสมควร

ฉันอ้างว่ามันมีความแตกต่างเล็กน้อยในการใช้วัตถุทางกายภาพสำหรับตัวอย่างและใช้วัตถุที่ไม่ใช่วัตถุเป็นตัวอย่าง ในรหัสพวกเขาทั้งสองมีส่วนเดียวกันที่แน่นอน ถ้าเราใช้ตัวอย่างกราฟิกและสอนมันด้วย Sphere, cube, cylinder มันเกือบจะเหมือนกับการใช้ ball, box, pole

ดังนั้นเพื่อสอนโดยไม่ใช้ตัวอย่างทางกายภาพฉันขอแนะนำไม่ให้ใช้ตัวอย่างใด ๆ เลย แต่ฉันไม่เห็นว่าทำไมคุณไม่ต้องการตัวอย่างทางกายภาพดังนั้นท่าทางของฉันในหัวข้อคือ

ไม่คุณไม่ควรสอนหากไม่มีวัตถุในโลกแห่งความจริง

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

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

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

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

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

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

คำอธิบายนี้ขัดแย้งกับวิธีการทางคณิตศาสตร์ / comp sci ทั่วไปของการสอนแนวคิดที่เป็นอิสระจากการดำเนินการ แต่มันเป็นมุมมองที่ทำให้ฉัน (ยอมรับคนที่มีวิศวกรรม