ประโยชน์ของ OOP แบบคลาสสิกในภาษา Go-like

13

ฉันคิดถึงการออกแบบภาษาเป็นอย่างมากและองค์ประกอบใดบ้างที่จำเป็นสำหรับภาษาการเขียนโปรแกรม "อุดมคติ" และการศึกษา Go's ของ Google ทำให้ฉันตั้งคำถามกับความรู้ทั่วไปหลายอย่าง

ดูเหมือนว่า Go จะได้รับประโยชน์ที่น่าสนใจทั้งหมดจากการเขียนโปรแกรมเชิงวัตถุโดยไม่มีโครงสร้างของภาษาเชิงวัตถุ ไม่มีคลาส, โครงสร้างเท่านั้น; ไม่มีการสืบทอดคลาส / โครงสร้าง - การฝังโครงสร้างเท่านั้น ไม่มีลำดับชั้นไม่มีคลาสพาเรนต์ไม่มีการปรับใช้อินเตอร์เฟสที่ชัดเจน กฎการคัดเลือกนักแสดงประเภทนั้นขึ้นอยู่กับระบบที่หลวมคล้ายกับการพิมพ์เป็ดเช่นหาก struct ดำเนินองค์ประกอบที่จำเป็นของ "Reader" หรือ "Request" หรือ "Encoding" คุณจะสามารถใช้และใช้มันได้ หนึ่งเดียว.

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

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

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

— tylerl
แหล่งที่มา

1

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

— Jamie Taylor

1

นอกจากนี้ที่น่าสนใจบางคนอ่านเมื่อคุณ Google เพื่อOOP ตาย ฉันขอแนะนำWeb Will Die เมื่อ OOP Dies

— Andomar

มีค่าเล็กน้อยใน OOP ที่ไม่คุ้มค่ากับการเสียเวลาเลย

— SK-logic

1

ฉันเห็นด้วยกับความคิดเห็นก่อนหน้าไม่เน้น OOP มากเกินไป นอกจาก OOP ไม่ได้แปลว่า C ++ หรือ Java ลองอ่าน ABIT บน ltu.org

— AndreasScheinert

C ++, Java และ C # ไม่ใช่ภาษา OOP "คลาสสิค" หากมีภาษา OOP คลาสสิกฉันคิดว่ามันเป็นสมอลล์ทอล์ค

— วินไคลน์

16

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

หลายภาษาที่มีคุณสมบัติเหล่านี้ไม่มีอะนาล็อกของแนวคิดคลาส - ตัวอย่างเช่น Javascript และ Common Lisp การติดตั้งใช้งานโดยภาษาที่มีลักษณะคล้าย Java (อิงกับคลาสพร้อมกับการสืบทอดเดี่ยวอินเตอร์เฟสการกระจายตามประเภท) เป็นเพียงหนึ่งในความเป็นไปได้และไม่จำเป็นต้องดีที่สุด

— อันเดรีย
แหล่งที่มา

11

+1 สำหรับ "ไม่จำเป็นต้องดีที่สุด" การอ้างถึง Alan Kay: "ฉันคิดค้นคำว่า Object-Oriented และฉันสามารถบอกได้ว่าฉันไม่มี C ++ ในใจ" (และเขาไม่ได้มี C # และ / หรือ Java ฉันจะเดาอย่างถ่อมตน)

— เธอ

1

@ โดยที่ฉันได้เห็นมันชี้ให้เห็นว่าระบบตัวแทน (คล้ายกับวิธีการทำงานของ Erlang) นั้นใกล้เคียงกับ OOP ของอลันเคย์ในที่สุด

— CodexArcanum

2

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

— Vatine

ใช่สิ่งที่ฉันหมายถึงคือมันไม่มีคลาสในความหมายของ Java

— Andrea

5

คุณมีประโยชน์อะไรที่ต้องยอมแพ้เพื่อให้ได้ความเรียบง่ายที่กระบวนทัศน์ใหม่นี้แสดงให้เห็น?

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

ระบบดังกล่าวล้าสมัยแนวคิดของ OOP หรือไม่

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

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

วิธีภาษาช่วยให้ที่ไม่ได้เรื่องจริงๆ

— Telastyn
แหล่งที่มา

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

— Jan Hudec

4

ฉันคิดว่าความคิดของคุณเกี่ยวกับ OOP ค่อนข้างจะออกไปเล็กน้อย:

ฉันคิดค้นคำว่า 'Object Oriented Programming' และ {Java และ C ++} นี้ไม่ใช่สิ่งที่ฉันนึกไว้
- อลันเคย์

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

ตอนนี้คุณสามารถถามได้ว่าประเภทของระบบใดที่ "ดีกว่า" และความหมายของการใช้รหัสซ้ำและการรวมกันคืออะไร และพยายามกำหนดข้อดีและข้อเสียระหว่างตัวเลือกที่ทำใน Simula (และดำเนินการในภายหลังใน C ++, Java และ C #) และที่ทำใน Go แต่นี่เป็นคำถามที่แตกต่างและแตกต่าง

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

— back2dos
แหล่งที่มา

2

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

— tylerl

@tylerl: คุณสับสนอย่างน้อยสองคำถามในหนึ่งคำถาม หนึ่งคือว่าการพิมพ์ย่อยโครงสร้างดีกว่าการพิมพ์ย่อยการออกเสียงหรือไม่ อีกองค์ประกอบหนึ่งเป็นองค์ประกอบที่ดีกว่ามรดก คำถามเหล่านี้ตั้งฉากกัน ฉันคิดว่าท้ายที่สุดแล้วภาษาที่ "ดีที่สุด" ไม่ได้เลือกตัวเลือกนี้ให้คุณ ฉันคาดการณ์ว่า Go จะมีปัญหาที่แตกต่างออกไป แต่เราจะเห็นว่า Google เพิ่มคุณลักษณะเหล่านั้น "ย้อนกลับ" หรือไม่

— back2dos

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

— Erik Alapää

1

OOP ไม่ล้าสมัย

ในฐานะที่เป็น Andrea กล่าวว่ามีแนวคิดมากมายที่เสนอเป็นทางเลือกให้กับคลาส (เช่น: haskell typeclass) OOP มีประโยชน์อย่างยิ่งใหญ่เพียงอย่างเดียว: มีการสอนในหลาย ๆ ที่และวัฒนธรรมของ OOP นั้นมีการแบ่งปันกันอย่างกว้างขวางในหมู่ผู้พัฒนา

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

— Simon Bergot
แหล่งที่มา

1

ฉันคิดว่า: มีหลายแห่ง ไม่ได้เปรียบจริง

— AndreasScheinert

@AndreasScheinert ทำไมมันไม่ได้เปรียบ?

— Simon Bergot

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

— AndreasScheinert

@AndreasScheinert ใช้เครื่องมือที่เหมาะสมสำหรับงาน Oop ใช้ไม่ได้กับทุกสถานการณ์ .... ไม่มีส่วนเกี่ยวข้องกับเขตความสะดวกสบายของพวกเขา

— pqsk

1

ไม่ไม่มีอะไรใหม่ที่นี่และ OOP ล้าสมัยแล้ว C ++ มีส่วนต่อประสานโดยนัยในรูปแบบของเทมเพลต แต่ผู้ใช้ยังคงใช้ฟังก์ชันเสมือน คุณต้องมีอินเตอร์เฟสที่ชัดเจนเพื่อจัดการกับเช่นอินเทอร์เฟซแบบไบนารี่หรืออินเทอร์เฟซที่ไม่รู้จักรหัสอื่น ๆ ในเวลารวบรวม

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

— DeadMG
แหล่งที่มา