ทำไม OOP ถึงยาก? [ปิด]

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

ทำไม OOP จึงเข้าใจยาก คือมันยากที่จะเข้าใจ?

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

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

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

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

ฉันคิดว่ามีปัจจัยบางอย่างที่ยังไม่ได้กล่าวถึง

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

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

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

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

1. อย่ายืนยันอะไรเลยเกี่ยวกับจำนวนล้อที่รถมี - แต่สิ่งนี้มีแนวโน้มที่จะนำไปสู่ข้อสันนิษฐานที่แน่นอนว่ามันจะเป็น 4 เสมอและรหัสที่มีแนวโน้มว่าจะแตกสำหรับหมายเลขอื่น
2. ยืนยันว่ารถยนต์ทุกคันมีสี่ล้อและแยกประเภทอื่น ๆ เป็น "ไม่ใช่รถยนต์" แม้ว่าเราจะรู้ว่าพวกเขาเป็นจริง
3. ออกแบบคลาสเพื่อให้มีความหลากหลายของล้อในกรณีที่มีโอกาสที่ดีไม่จำเป็นต้องใช้ความสามารถหรือทดสอบอย่างเหมาะสม

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

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

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

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

OOP ต้องการความสามารถในการคิดอย่างเป็นนามธรรม ของขวัญ / คำสาปที่มีไม่กี่คนแม้แต่โปรแกรมเมอร์มืออาชีพก็มีอยู่จริง

ฉันคิดว่าคุณสามารถสรุปปัญหาพื้นฐานด้วยวิธีนี้:

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);

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

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

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

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

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

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

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

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

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

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

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

ฉันไม่เห็นด้วยกับคำตอบของ dsimcha ส่วนใหญ่:

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

2. วิธีการส่วนบุคคลในโปรแกรม OO ที่ดีนั้นมักจะไม่เป็นการมองขั้นตอนทั้งหมด สิ่งนี้กำลังกลายเป็นจริงมากขึ้นเรื่อย ๆ กับวิวัฒนาการของภาษา OO (อ่าน C # เพราะนอกเหนือจาก C ++ นั่นเป็นภาษา OO อื่น ๆ เท่านั้นที่ฉันรู้จัก) และไวยากรณ์ของพวกเขาที่ซับซ้อนมากขึ้นในแต่ละวัน (lambdas, LINQ กับวัตถุ ฯลฯ ) ความคล้ายคลึงกันเพียงอย่างเดียวระหว่างวิธีการของ OO กับขั้นตอนในภาษาเชิงโพรซีเดอร์คือลักษณะเชิงเส้นของแต่ละวิธีซึ่งฉันสงสัยว่าจะเปลี่ยนแปลงได้ทุกเวลาในไม่ช้า

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

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

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

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

คุณควรอ่านObjects Never? ดีแทบจะไม่เคย (จำเป็นต้องมีสมาชิก ACM) โดย Mordechai Ben-Ari ผู้ซึ่งแสดงให้เห็นว่า OOP นั้นยากมากเพราะไม่ใช่กระบวนทัศน์ที่เป็นธรรมชาติสำหรับการสร้างแบบจำลองอะไร (แม้ว่าฉันจะมีการจองเกี่ยวกับบทความเพราะมันไม่ชัดเจนว่าเกณฑ์ที่เขารู้สึกว่าโปรแกรมต้องการตอบสนองที่จะบอกว่ามันเขียนไว้ในกระบวนทัศน์ OOP เมื่อเทียบกับกระบวนทัศน์กระบวนงานโดยใช้ภาษา OO)

การเขียนโปรแกรมเชิงวัตถุในตัวเองนั้นไม่ยาก

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

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

ฉันแค่ดูวิดีโอโดย Richard Feynman พูดคุยเกี่ยวกับวิธีที่ผู้คนอาจมีวิธีการที่แตกต่างกันอย่างสิ้นเชิงที่เกิดขึ้นในหัวของพวกเขาเมื่อคิด - ฉันหมายถึงแตกต่างกันโดยสิ้นเชิง

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

ฉันยังมีปัญหาในการจดจำรายละเอียดและพบว่า OO เป็นองค์กรที่ยอดเยี่ยม - หาฟังก์ชั่นได้ง่ายกว่าการสแกนผ่านรูทีนย่อยที่จัดอย่างเป็นระเบียบ

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

ฉันเคยเขียนโปรแกรม GW-Basic และ Turbo Pascal เล็กน้อยก่อนที่จะได้รับการแนะนำให้รู้จักกับ OO ดังนั้นในตอนแรกDIDจะทำหัวของฉัน

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

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

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

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

นอกจากนี้ยังมี OOP ที่ไม่ดีมากมายที่นั่นถ้าผู้คนกำลังอ่าน / เห็นว่ามันง่ายที่จะเห็นว่าทำไมพวกเขาถึงพบว่ามันยาก

IMO คุณต้องรอจนกว่าจะ 'คลิก' หรือสอนโดยผู้ที่มีความรู้จริงฉันไม่คิดว่าคุณจะรีบเร่ง

ฉันคิดว่าเหตุผลที่ OOP นั้นยากสำหรับหลาย ๆ คนก็เพราะเครื่องมือไม่อำนวยความสะดวก

ภาษาคอมพิวเตอร์ทุกวันนี้เป็นนามธรรมของสิ่งที่เกิดขึ้นในคอมพิวเตอร์

OOP เป็นวิธีที่เป็นนามธรรมเพื่อเป็นตัวแทนของนามธรรม

ดังนั้นเราจึงใช้นามธรรมเพื่อสร้าง abstractions ด้วยนามธรรม เพิ่มไปที่สิ่งที่เราเป็นนามธรรมมักจะมีปฏิสัมพันธ์ทางกายภาพ / สังคมที่ซับซ้อนมากและก็ไม่น่าแปลกใจ

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

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

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

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

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

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

ไม่ว่าคุณจะเลือกกระบวนทัศน์ใด (OOP, functional และอื่น ๆ ) ในการเขียนโปรแกรมคอมพิวเตอร์คุณจำเป็นต้องรู้ว่าขั้นตอนใดที่โปรแกรมของคุณจะทำ

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

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

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

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

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

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

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

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

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

ตกลงว่าควรออกแบบรูปแบบการออกแบบอย่างน้อยให้ขนานกับ OOP

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

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

สูตรอาหาร

ความเข้าใจที่ดีของ OOP = ที่ปรึกษาที่ดีหรือหนังสือที่ดีหรือทั้งสองอย่าง + ความสนใจส่วนบุคคล + การปฏิบัติ

ความสนใจส่วนบุคคล

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

การปฏิบัติการปฏิบัติและการปฏิบัติ

เพื่อนที่ดีที่สุดของฉันที่จะเข้าใจ OOP ได้ดีขึ้นไม่ได้มีอะไรนอกจากการฝึกฝน สิ่งนี้จะส่งเสริมความสามารถของ OOP ของคุณอย่างแน่นอน

ดังคำกล่าวที่ว่า“ ไม่มีทางแทนที่การทำงานหนักและไม่มีทางลัดสู่ความสำเร็จ”

โชคดี!