กระบวนทัศน์การเขียนโปรแกรมเชิงวัตถุนั้นล้าสมัยเนื่องจากต่อต้านแบบแยกส่วนและแบบขนานหรือไม่? [ปิด]


23

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

และเขาอ้างว่า:

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

เหตุใดจึงต้องพิจารณาว่า OOP เป็นแบบแยกส่วนและป้องกันแบบขนาน?



14
Buhwaaaah ?! OO ทำให้ความเป็นโมดูลและความขนานได้ง่ายกว่าในขั้นตอนและไม่เป็นเอกสิทธิ์ของ FP ทำให้ฉันสับสน
Matt Ellen

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

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

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

คำตอบ:


30

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

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

คำใบ้อีกข้อคือความสำคัญของรูปแบบการออกแบบและความซับซ้อนของการนำไปใช้ - เมื่อเทียบกับกระบวนทัศน์การเขียนโปรแกรมอื่น ๆ - เช่นโรงงาน, ผู้สร้าง, อะแดปเตอร์, สะพาน, มัณฑนากร, ผู้ตกแต่ง, ซุ้ม, คำสั่ง คอมโพสิตทั้งหมดในบางวิธีที่เกี่ยวข้องกับการปรับปรุง modularity ของรหัส OO

การสืบทอดยังเป็นปัญหา (เช่นปัญหาระดับฐาน Fragile ) และ (subtype) polymorphism ล่อลวงคนหนึ่งให้ดำเนินการตามอัลกอริธึมระหว่างคลาสหลายชั้นซึ่งการเปลี่ยนแปลงสามารถกระเพื่อมผ่านห่วงโซ่มรดกทั้งหมด (ขึ้นและลง!)

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

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


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

2
ในขณะที่ฉันเห็นด้วยกับทุกสิ่งที่คุณพูดที่นี่ฉันอยากจะชี้ให้เห็นว่ารูปแบบการออกแบบมาในกระบวนทัศน์การเขียนโปรแกรมทั้งหมด สำหรับการเขียนโปรแกรมการใช้งานฉันจะชี้ให้เห็นสิ่งต่าง ๆ เช่น monads และ map / ลด
Anm

@ davidk01 ยกตัวอย่างเช่น รองรับการเขียนโปรแกรมเชิงวัตถุและมีการทำงานพร้อมกันที่ยอดเยี่ยม ที่สำคัญกว่านั้นคือการหยุดเขียนโปรแกรมพร้อมกันโดยไม่ต้องใช้งานได้เลย
weberc2

19

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

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

  1. การเรียกร้องเกี่ยวกับ OOP เป็นการต่อต้านแบบแยกส่วนเป็นเพียงเรื่องไร้สาระที่สุด ฉันไม่รู้ด้วยซ้ำว่าจะตอบอย่างไรไม่เพียง แต่ไม่มีการโต้แย้ง แต่ยัง OOP โดยการออกแบบเป็นวิธีการสร้างต้นแบบที่มีการเชื่อมต่อที่ต่ำมากระหว่างแต่ละโมดูลผ่านวิธีการห่อหุ้มและนามธรรม

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

ปัญหาของ OOP คือมีเพียงไม่กี่คนที่เข้าใจในความหมายของAlan Kay ที่กำหนดไว้

  1. OOP เป็นแนวทาง ในบางภาษามีการใช้รูปแบบในบางภาษาคุณสามารถใช้สำนวนภาษาในตัวได้โดยตรง (เช่น Ruby, Objective-C, Smalltalk, Io )
  2. ตรงกันข้ามกับความเชื่อทั่วไป OOP ไม่เกี่ยวกับชั้นเรียน มันเกี่ยวกับวัตถุและวัตถุที่เกี่ยวกับการส่งข้อความหรือวิธีการห่อหุ้มและนามธรรมที่ไม่รั่วไหล

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

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


1
+1 สำหรับการส่งข้อความและ +1 สำหรับ 'กับ Java' น่าเสียดายถ้าพวกเขาลบ Java พวกเขาเพียงแค่แทนที่ด้วย C # และดำเนินการต่อมรดกของมัน
gbjbaanb

@ back2dos +1 สำหรับนักวิจารณ์ -1 สำหรับ Java แน่นอน Smalltalk นั้น "มากกว่า OO" มากกว่า Java แต่ใครใช้บ้าง Object--C นั้นยากสำหรับผู้เริ่มต้นเช่นเดียวกับ C
maaartinus

@ maaartinus: คุณจะพบ Squeak ที่ใช้กันอย่างแพร่หลายในด้านการศึกษาและวิชาการหากตอบคำถามของคุณ สำหรับ Java: คุณอาจชอบฉันอาจไม่ชอบ มันก็เป็นเรื่องของความชอบส่วนตัวและไม่มีประเด็นใดที่จะพูดถึงเรื่องนี้ อย่างไรก็ตาม Java ไม่เหมาะสมสำหรับการแนะนำ OOP คือ IMHO เป็นนัยที่ปฏิเสธไม่ได้ของธรรมชาติของ Java และแนวคิดของ OOP และนั่นคือสิ่งที่ฉันพูด ความนิยมของ Java จะไม่ทำให้หายไป ในฐานะที่เป็นสำหรับ C ผมขอแนะนำให้คุณอ่านjoelonsoftware.com/articles/ThePerilsofJavaSchools.html
back2dos

@ back2dos Squeak อาจจะใช้ในพื้นที่เหล่านี้ แต่ที่มหาวิทยาลัยฉันได้เรียนรู้ ML แล้ว ทั้งสองใช้ไม่ได้อย่างเท่าเทียมกันในอุตสาหกรรมและทั้งคู่มีค่าการเรียนรู้เนื่องจากแนวคิดของพวกเขา บทความที่แหลมเป็นบทความที่แย่ที่สุดของโจเอลที่ฉันเคยอ่านมานานเกินไปและตั้งแต่แรกเห็นข้อความดูเหมือนจะเป็นความสำคัญของการจัดการกับ segfaults : D ฉันยังคงแนะนำ Java สำหรับการสอน OOP
maaartinus

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

12

คุณได้รับความสนใจจากทุกแถบ

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

ยี่สิบปีนับจากนี้ไม่ต้องสงสัยเลยว่าเราจะมีแบคแลชอื่น ๆ ที่ต่อต้านการเขียนโปรแกรมใช้งาน


1
มีอยู่แล้ว!
quant_dev

1
++ "คุณได้รับความสนใจจากทุกแถบ" ผมเป็นนักวิชาการและประสบการณ์ของผมเป็นแบบนี้ นักวิชาการชอบที่จะพ่นความคิดเห็นที่เร้าใจสร้างความประทับใจให้กับนักเรียนของพวกเขา
Mike Dunlavey

5

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

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

Parallelisation : สำหรับการเขียนโปรแกรมแบบขนานเฟรมเวิร์กส่วนใหญ่รองรับ interupts จากนั้นจึงทำการเธรดและตอนนี้การขนานที่เหมาะสมเช่นสิ่งที่เราเห็นใน. Net Framework 4.0 และภาษา OOP ที่เข้ากับมัน

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


4

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

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

โดยส่วนตัวฉันคิดว่ามันเกินความจริง แต่นักวิชาการชอบที่จะลองสิ่งใหม่และสุดขั้ว ในฐานะที่เป็นดุลยภาพ MIT เคยสอน (และอาจยัง) สอนกระบวนทัศน์การเขียนโปรแกรมที่สำคัญทั้งหมดในชั้นเรียนครั้งแรก

ผิดปกติพอทั้งสองโรงเรียนได้ผลิตโปรแกรมเมอร์ที่ดีจริงๆ ไปคิด

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.