คำถามทั่วไปที่นักเรียนอาจถามเมื่อพวกเขาเรียนรู้ OOP?

Jan 19 2021

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

ตัวอย่างเช่นในคำถามที่ผู้เขียนถามว่า

ฉันเป็นนักเรียน CS ที่เริ่มต้น ... ในภาคเรียนแรกเราได้รับการแนะนำให้รู้จักกับแนวคิด OOP เช่นการห่อหุ้มการซ่อนข้อมูลการแยกส่วน ...

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

ฉันต้องยอมรับว่าฉันมีการต่อสู้ของตัวเองเช่นฉันถามคำถามนี้OOP เน้นความสำคัญของคำนามมากเกินไปหรือไม่และทำให้การกระทำ / คำกริยาอยู่ในตำแหน่งที่มีความสำคัญน้อยกว่า?บนไซต์นั้นด้วย (ไม่มีนักเรียนคนใดถามคำถามนี้กับฉัน) คำถามของฉันถูกปิดและได้รับคะแนนลบ 2 ครั้ง แต่นั่นก็เป็นข้อกังวลของฉัน

หากนักเรียนของฉันหรือเพื่อนร่วมงานของฉันที่มีประสบการณ์กับ javascript และชอบเรียนรู้ OOP ฉันจะให้พวกเขาเปรียบเทียบmomentjsกับdate-fns เสมอทั้งคู่จัดการกับวันที่และให้ฟังก์ชันที่คล้ายกันทั้งคู่ทำงานได้ดี แต่มีห้องสมุด OOP และ date-fns คือไลบรารีฟังก์ชัน

จุดประสงค์ของฉันคือให้พวกเขาเข้าใจว่ามีมากกว่าหนึ่งวิธีในการทำสิ่งต่างๆ

คำถามทั่วไปที่นักเรียนของคุณถามคืออะไร?

คำตอบ

4 Qiulang Jan 20 2021 at 11:01

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

ดังนั้นฉันจึงระบุคำถามบางอย่างจากไซต์วิศวกรรมซอฟต์แวร์

  1. เหตุใดจึงควรแบ่งโปรแกรมออกเป็นหลายชั้นเรียน? . คำถามนี้ถูกถามโดยนักเรียนมัธยมปลาย
  2. ออบเจ็กต์ใน OOP ต้องแสดงถึงเอนทิตีหรือไม่ . นักเรียนของฉันถามคำถามนี้กับฉัน
  3. ประโยชน์ของการเขียนโปรแกรมเชิงวัตถุผ่านการเขียนโปรแกรมขั้นตอนคืออะไร? คำถามนี้ค่อนข้างเกี่ยวข้องกับคำถาม "จัดการความซับซ้อนของซอฟต์แวร์" ในคำถามของฉันและฉันจะพูดคุยกับเพื่อนร่วมงานของฉันอีกคำถามที่น่าสนใจซึ่งถูกถามใน quora Linux จะรักษาฐานรหัสขนาดใหญ่ได้อย่างไรเมื่อ C ไม่ใช่ภาษาเชิงวัตถุ? ฐานรหัสทั้งหมดยุ่งเหยิงหรือไม่?
  4. OOP ปฏิบัติตามสัญญาของการใช้โค้ดซ้ำหรือไม่ มีทางเลือกใดบ้างเพื่อให้เกิดการนำโค้ดกลับมาใช้ใหม่ ฉันไม่แน่ใจว่านักเรียนจะถามคำถามนี้หรือไม่และฉันก็มีคำถามสองเท่าของตัวเองเช่นกัน
  5. เมื่อเขียนโค้ดเชิงวัตถุฉันควรทำตามรูปแบบการออกแบบเสมอหรือไม่? . เว็บไซต์นี้ยังมีคำถามเกี่ยวกับรูปแบบการออกแบบหลักสูตรวิทยาการคอมพิวเตอร์ที่ไม่ได้สอนรูปแบบการออกแบบจะแย่แค่ไหน?
  6. คำอธิบายเกี่ยวกับวิธีการ“บอกไม่ได้ถาม” ถือว่า OO หลังจากที่พวกเขาได้รับประสบการณ์การเขียนโค้ดแล้วพวกเขาก็สามารถถาม / ชื่นชมคำถามได้ แต่ก็เป็นสิ่งที่ดี
  7. ฉันควรสร้างคลาสหรือไม่หากฟังก์ชันของฉันซับซ้อนและมีตัวแปรจำนวนมาก นอกจากนี้ยังมีคำตอบหนึ่งคำแนะนำของฉันให้กับนักเรียนเมื่อพวกเขามีคำถามเช่น "ใช้ชั้นเรียน แต่ยังมีฟังก์ชันยืนอิสระที่สร้างวัตถุเรียกใช้เมธอดและส่งกลับผลลัพธ์ซึ่งเป็นคลาสที่คุณใช้เป็นการภายในจริงๆ กลายเป็นเพียงรายละเอียดการนำไปใช้ในงานสาธารณะของคุณ "

Quora ยังมีคำถามที่น่าสนใจที่ฉันรู้สึกว่าผู้คนจะถามเมื่อพวกเขาเรียนรู้ OOP เป็นครั้งแรกฉันระบุไว้ที่นี่:

  1. ทุกคน (ในตำแหน่งโปรแกรมเมอร์) สามารถอยู่รอดในอุตสาหกรรมเทคโนโลยีสมัยใหม่ (ซอฟต์แวร์หรือไม่มีซอฟต์แวร์) โดยไม่มี OOP ได้หรือไม่?
  2. นักพัฒนาซอฟต์แวร์ใช้ OOP บ่อยแค่ไหน? . คำตอบหนึ่งของ Kurt Guntheroth นั้นน่าสนใจ "เมื่อใดก็ตามที่คุณเขียนโปรแกรมยาวเกินกว่า 1,000 บรรทัดคุณควรใช้ OOP 1,000 บรรทัดทำไมถึงเป็นเช่นนั้น ... ?"
  3. การเขียนโปรแกรมเชิงวัตถุไม่เหมาะสมเมื่อใด

หวังว่าคงจะได้คำตอบอื่น ๆ บ้าง

1 Eddie Feb 06 2021 at 17:23

นี่เป็นคำถามที่ดีจริงๆ! คำตอบของคุณครอบคลุมพื้นมากเช่นกัน

ฉันต้องการเสนอภาพสะท้อนว่าอะไรอาจกระตุ้นคำถามเหล่านี้

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

  1. พวกเขายังไม่ประสบปัญหาที่ OOP แก้ไข
  2. พวกเขาเชื่อว่ามีโซลูชั่นที่สมบูรณ์แบบสำหรับความท้าทายในการเขียนโปรแกรมทั้งหมดที่รอให้ค้นพบ

สิ่งเหล่านี้ก่อให้เกิดคำถามมากมายความสับสนและในบางกรณีความไม่ปลอดภัย