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

รหัสนำมาใช้ใหม่ตามที่ OOP กำหนดไว้หรือไม่ทำให้โครงการมีประสิทธิผลมากขึ้น

หรือจัดการได้มากขึ้น? หรือง่ายต่อการบำรุงรักษา? หรือมีคุณภาพมากขึ้น?

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

บอกเล่าประสบการณ์ของคุณกับการใช้ OOP ซ้ำหรือกระบวนทัศน์อื่น ๆ

การใช้รหัสซ้ำเป็นความคิดที่ดี ไม่ได้เป็นหนึ่งที่ดี

ฉันมีมุมมองจากวิศวกรรมซอฟต์แวร์ประมาณ 30 ปีพยายาม "ใช้ซ้ำ"

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

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

ฉันเป็นซานตาคลอส (โอเพ่นซอร์สโอเค) และฉันมีส่วนประกอบของซอฟต์แวร์ 1 พันล้านรายการ คุณสามารถมีหนึ่งในนั้น

ขอให้โชคดีในการเลือก

วิธีแก้ปัญหาการใช้ซ้ำ:

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

ส่วนใหญ่สิ่งที่ได้รับการค้นพบในช่วงหลายปีที่ผ่านมาก็คือเพื่อให้โค้ดสามารถนำกลับมาใช้ใหม่ได้มันต้องได้รับการออกแบบมาเพื่อจุดประสงค์นั้นหรือมีข้อสันนิษฐานมากมาย ไลบรารีที่นำโค้ดกลับมาใช้ใหม่ที่ประสบความสำเร็จมากที่สุดนั้นมีขนาดค่อนข้างเล็ก เนื้อหาและไลบรารีเฟรมเวิร์กเป็นรหัส "นำกลับมาใช้" และพวกเขาจะประสบความสำเร็จอย่างมาก; Java และ C # ไม่ได้ประสบความสำเร็จเพราะพวกเขาเป็นภาษาคอมพิวเตอร์ที่ดี แต่เป็นเพราะพวกเขามีห้องสมุดขนาดใหญ่ที่ได้รับการออกแบบใช้งานและมีเอกสารเป็นจำนวนมาก แต่ผู้คนไม่ได้ดูซอร์สโค้ดในไลบรารี พวกเขาเรียก API ที่มีเอกสารอย่างดี (ออกแบบมาให้ใช้งานได้โดยทั่วไป)

การใช้ซ้ำรหัสใดที่ยังไม่ได้ทำ (ไม่รวม OOP) คือคำสั่งให้ปรับปรุงขนาดในความสามารถของเราในการใช้ระบบรหัส

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

สิ่งที่เราควรจะทำงานในคือนำมาใช้ใหม่ของความรู้ในการสร้างรหัส หากเราสามารถทำสิ่งนี้ได้เราสามารถนำความรู้นั้นไปใช้ในการสร้างรหัสที่เราต้องการจัดการกับชุดของสมมติฐานปัจจุบัน

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

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

เครื่องจักรที่สำคัญชิ้นหนึ่งที่จำเป็นสำหรับสิ่งนี้คือเครื่องมือทางกลสำหรับการยอมรับ "คำอธิบายส่วนประกอบ" (นี่เป็นเพียงเอกสารทางการและสามารถแยกวิเคราะห์เช่นภาษาโปรแกรม) และใช้การแปลงโปรแกรมกับพวกเขา

คอมไพเลอร์ทำสิ่งนี้แล้ว: -} และพวกเขาเก่งในระดับของปัญหาที่พวกเขาแก้ไข

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

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

แต่ DMS มีคุณสมบัติหลักสองอย่างที่ฉันอธิบายไว้ข้างต้น: ความสามารถในการประมวลผลข้อมูลจำเพาะที่เป็นทางการโดยพลการและความสามารถในการจับ "ความรู้เกี่ยวกับการสร้างรหัส" เป็นการแปลงและนำไปใช้ตามต้องการ และที่น่าทึ่งคือเราสร้างในบางกรณีพิเศษบางรหัสที่น่าสนใจจากสเปค; DMS ส่วนใหญ่สร้างขึ้นโดยใช้ตัวมันเองเพื่อสร้างการใช้งาน ที่ได้รับสำหรับเราอย่างน้อยคำสัญญาของ (ความรู้) นำมาใช้ใหม่: การเพิ่มผลผลิตที่สำคัญอย่างยิ่ง ฉันมีทีมงานประมาณ 7 คนด้านเทคนิค เราได้เขียนอาจเป็น 1-2 MSLOC ของ "ข้อมูลจำเพาะ" สำหรับ DMS แต่มี 10MSLOC ของรหัสที่สร้างขึ้น

สรุป: การนำความรู้กลับมาใช้ใหม่เป็นเรื่องชนะไม่ใช่การใช้รหัสซ้ำ

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

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

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

จาก Wikpedia:

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

ใช่และไม่

การใช้รหัสซ้ำเป็นคำที่จับได้สำหรับกิจกรรมต่างๆมากมาย

1. รหัสนำมาใช้ใหม่ภายในโครงการเดียว OO เหมาะอย่างยิ่งสำหรับสิ่งนี้แอพพลิเคชั่นที่ออกแบบมาอย่างดีจะแมปความสัมพันธ์ของโลกจำลองอย่างใกล้ชิดจึงกำจัดรหัสที่ซ้ำกันให้มากที่สุดและแนะนำให้ใช้ อย่างไรก็ตามคุณสามารถยืนยันว่าเทคโนโลยี pre-OO สามารถบรรลุสิ่งเดียวกันซึ่งเป็นจริง แต่ OO นั้นสะดวกกว่าหลายวิธี
2. ห้องสมุดบุคคลที่สามสิ่งนี้ดูเหมือนว่าจะทำงานได้ดีไม่ว่าจะมีหรือไม่มี OO
3. การใช้ซ้ำรหัสข้ามวัตถุประสงค์สัญญาการใช้ซ้ำรหัสที่ใหญ่ที่สุดของ OO คือรหัสเมื่อมีการเขียนสำหรับแอปพลิเคชันหนึ่งสามารถนำกลับมาใช้ในภายหลังได้สำหรับแอปพลิเคชันอื่นซึ่งไม่ได้ออกแบบมาเฉพาะสำหรับ ทั้งหมดนี้เป็นความโกรธเมื่อความคิดของ OO ถูกกรองผ่านประตูของสำนักงานบริหารที่สูงขึ้นและ OO ล้มเหลวอย่างสิ้นเชิงในการบรรลุเป้าหมาย มันกลับกลายเป็นว่าจุดประสงค์นั้นเป็นสิ่งสำคัญอย่างยิ่งของการออกแบบ OO (และอาจเป็นไปได้ว่ารหัสขั้นตอนทั้งหมด แต่เป็นเพียงทฤษฎีของฉัน) และความพยายามที่จะเปลี่ยนรหัสสิ้นสุดในภัยพิบัติการบำรุงรักษา (antipatterns ที่รู้จักกันดีของเฟรมเก่าที่ไม่มีใครกล้าแก้ไขและเพื่อนเฟรมที่แตกต่างกันเล็กน้อยสำหรับแอปทุกตัวมักเกิดจากที่นี่)

ฉันจะโพสต์คำตอบยาว ๆ แต่ทำไม? อุดีดาฮันอธิบายได้ดีกว่าที่ฉันสามารถทำได้

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

นี่คือจุดเริ่มต้นของการโพสต์:

อุตสาหกรรมนี้ถูกครอบครองล่วงหน้าด้วยการใช้ซ้ำ

มีความเชื่อนี้ว่าหากเราเพิ่งนำโค้ดกลับมาใช้ใหม่มากขึ้น

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

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

ฉันอาจปล่อยให้คุณเข้าไปในความลับที่สกปรกน้อย:

การใช้ซ้ำเป็นความเข้าใจผิด

ฉันเห็นด้วยกับ Chris โปรแกรมการทำงานเป็นวิธีที่ดีในการนำรหัสมาใช้ซ้ำ

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

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

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

ฟังก์ชั่นการสั่งซื้อสูงนอกจากนี้ยังมีประโยชน์อย่างมากเมื่อมันมาถึงนำมาใช้รหัสเช่นmapและfoldrที่เป็นรากฐานสำหรับของ Google MapReduce

การส่งข้อความแบบอะซิงโครนัสยังเป็นวิธีที่ดีในการจัดระเบียบซอฟต์แวร์ที่ซับซ้อนและนักวิทยาศาสตร์คอมพิวเตอร์บางคนระบุว่าวัตถุนั้นถูกสมมติให้สื่อสารกับแต่ละคนแบบอะซิงโครนัสเหมือนในTell ไม่ต้องถามหลักการ OOP ดูเพิ่มเติมเกี่ยวกับสิ่งนี้ใน การเขียนโปรแกรมเชิงวัตถุ: เส้นทางผิด ถูกJoe Armstrongถูกยกมา:

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

ข้อความแบบอะซิงโครนัสที่ส่งผ่านในระบบขับเคลื่อนเหตุการณ์และใน Erlang เป็นวิธีที่ดีมากในการแยกระบบและการเชื่อมต่อแบบหลวมมีความสำคัญในระบบที่ซับซ้อน ด้วยระบบที่แยกออกอย่างเพียงพอคุณสามารถพัฒนาระบบในขณะที่มันกำลังทำงานอยู่อาจจะอยู่บนโหนดที่ต่างกัน Unibet ได้นำเสนอที่ยอดเยี่ยมเกี่ยวกับสิ่งนี้: Domain Event Driven Architecture

อย่างไรก็ตามฉันคิดว่าการใช้รหัสซ้ำส่วนใหญ่นั้นทำได้โดยใช้ไลบรารีและกรอบงาน

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

OOP ไม่มีความพิเศษ คุณสามารถสร้างรหัสที่สามารถใช้ซ้ำได้โดยมีหรือไม่มี OOP ฟังก์ชั่นที่บริสุทธิ์นั้นสามารถนำกลับมาใช้ใหม่ได้โดยเฉพาะ : ยกตัวอย่างเช่นjava.lang.math.sqrt(double)ใช้ตัวเลขและให้ตัวเลข ไม่มี OOP แต่สามารถใช้ซ้ำได้มากกว่าโค้ดส่วนใหญ่

จากมุมมองการเขียนโปรแกรมการทำงาน OOP ส่วนใหญ่เกี่ยวกับการจัดการสถานะ

ในการเขียนโปรแกรมการทำงานคุณสามารถมีหลายร้อยฟังก์ชันที่มีประโยชน์สำหรับรายการ: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Data-List.html

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

น่าเศร้าที่แทนที่จะใช้ฟังก์ชั่นเล็ก ๆ จำนวนมากบางคนใช้ฟังก์ชั่นซ้ำซ้อน สำหรับฉันนั่นเป็นเพราะ OOP ไม่สนับสนุนให้ใช้รหัสซ้ำได้มากเท่าที่การเขียนโปรแกรมใช้งานได้

สำหรับฉันใช่ แต่ไม่ใช่ตลอดเวลาและสามารถทำได้ในวิธีอื่น

ใช้เวลาส่วนใหญ่โดยการสร้างคลาสพื้นฐานที่เป็นนามธรรมและสร้างการใช้งานที่เป็นรูปธรรมของคลาสนั้น

เฟรมเวิร์กจำนวนมากใช้ประโยชน์จากการสืบทอดเพื่อให้นำโค้ดกลับมาใช้ใหม่ (Delphi, Java, .Net เป็นเพียงส่วนหนึ่งที่ทำให้เกิดความคิดขึ้นทันที)

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

จากประสบการณ์ของฉันฉันประสบความสำเร็จในการใช้ประโยชน์จากรหัส "reusable" ผ่านการเขียนโปรแกรมทั่วไป (เช่นเทมเพลต C ++) มากกว่าที่ฉันเคยใช้หลักการ OOP เช่นลำดับชั้นการสืบทอด

OOP เปิดเกินไปสำหรับการใช้ซ้ำอย่างมีประสิทธิภาพ

มีวิธีการใช้ซ้ำมากเกินไป แต่ละชั้นสาธารณะถามว่า: "ทำตัวอย่างใหม่ให้ฉัน!" แต่ละวิธีสาธารณะพูดว่า: "โทรหาฉัน!" แต่ละวิธีที่ได้รับการป้องกันจะให้: "แทนที่ฉัน!" - และวิธีการนำกลับมาใช้ใหม่เหล่านี้แตกต่างกันพวกเขามีพารามิเตอร์ที่แตกต่างกันพวกเขาปรากฏในบริบทที่แตกต่างกันทั้งหมดมีกฎที่แตกต่างกันวิธีการโทร / ขยาย / แทนที่

APIดีกว่ามันเป็นเซตย่อยของ OOP (หรือ non-oop) อย่างเข้มงวด แต่ในชีวิตจริง API นั้นมีการใช้งานเกินขนาดและเติบโตตลอดไปยังคงมีจุดเชื่อมต่อมากเกินไป นอกจากนี้ API ที่ดีสามารถทำให้ชีวิตง่ายขึ้นเป็นวิธีที่ดีที่สุดในการจัดหาส่วนต่อประสานสำหรับ OOP

Datadlow กระบวนทัศน์ให้อินเทอร์เฟซที่เข้มงวดสำหรับคอมโพเนนต์มีพอร์ตประเภทต่อไปนี้:

• ผู้บริโภค (ปัจจัยการผลิต) และ
• ผู้ผลิต (ผลลัพธ์)

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

ฉันเป็นบิตชัดเจนคุณอาจจะดูใน"dataflow" แท็กใน StackOverflowหรือวิกิพีเดีย "การเขียนโปรแกรม datafow"หรือวิกิพีเดีย"การเขียนโปรแกรมการไหลตาม"

(นอกจากนี้ฉันได้เขียนระบบดาต้าโฟลว์ใน C ++ ดังนั้น OOP และ DF ไม่ใช่ศัตรู DF เป็นวิธีการจัดการระดับที่สูงขึ้น)

ใน CommonLisp มีวิธีการมากมายที่จะนำมาใช้ซ้ำได้:

• การพิมพ์แบบไดนามิกโดยมีรหัสของคุณเป็นรหัสทั่วไป

• abstractions ที่จำเป็น, รูทีนย่อย ie

• การวางแนววัตถุที่มีหลายมรดกและหลายส่ง

• ซินแท็คซ์ - นามธรรมความสามารถในการกำหนดโครงสร้างประโยคใหม่หรือย่อรหัสจาน - บอยเลอร์

• ฟังก์ชั่น abstractions, closures และ high-order-function

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

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

ในแง่นั้นการใช้ซ้ำในโลกแห่งความเป็นจริงนั้นเกี่ยวกับการกำหนดสิ่งใหม่ ฉันสามารถนำที่นั่งเหล่านี้กลับมาใช้ใหม่ได้ที่นี่และจัดเรียงใหม่ให้เป็น ... เตียง! ไม่ใช่เตียงที่สะดวกสบายมาก แต่ฉันสามารถทำได้ นั่นไม่ใช่การใช้งานหลักของพวกเขา ฉันกำลังนำพวกเขาไปใช้นอกขอบเขตการบังคับใช้เดิม [... ] พรุ่งนี้ฉันจะบินกลับไปอังกฤษ ฉันจะไม่นำเครื่องบินมาใช้ซ้ำ ฉันจะใช้มันเพื่อจุดประสงค์ที่ตั้งใจไว้ไม่มีอะไรที่น่าสนใจหรือน่าตื่นเต้นเกี่ยวกับเรื่องนั้น

- Kevlin Henney

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

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

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

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

ฉันเห็นโค้ดของโพรซีเดอร์เพียงพอที่จะรู้ว่าอาจเป็นที่ใดก็ได้และบางครั้งก็เป็นทุกที่

OOP ให้วิธีเพิ่มเติมแก่คุณในการนำรหัสมาใช้ซ้ำ นั้นคือทั้งหมด.

การใช้แนวนอนซ้ำ: แง่มุม, ลักษณะ, กราฟ

บางครั้ง OO แบบคลาสสิกจะย่อการใช้งานโค้ดซ้ำโดยเฉพาะอย่างยิ่งเมื่อคุณสืบทอดสิ่งที่บ้าคลั่งเพราะขาดวิธีที่ดีกว่าในการแบ่งปันฟังก์ชั่นการใช้งานจริงระหว่างคลาส สำหรับปัญหานี้มีการสร้างกลไกการใช้ซ้ำในแนวนอนเช่น AOP ลักษณะและกราฟ

มุมมองการเขียนโปรแกรมเชิง

ฉันคิดว่า AOP เป็นครึ่งส้มที่หายไปของ OOP AOP ไม่เป็นที่รู้จักจริง ๆ แต่มันทำให้เป็นรหัสการผลิต

ฉันจะลองอธิบายอย่างง่าย ๆ : ลองจินตนาการว่าคุณสามารถฉีดและกรองการทำงานด้วยโครงสร้างพิเศษที่เรียกว่าด้านมุมมองเหล่านี้มี "วิธีการ" ที่กำหนดว่าอะไรและอย่างไรจะได้รับผลกระทบจากการสะท้อนกลับแต่ในเวลารวบรวม กระบวนการนี้เรียกว่าการทอผ้า

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

ดูการพูดคุยสองเรื่องนี้หากคุณต้องการทำความเข้าใจ AOP ให้ดีขึ้น:

• การใช้การเขียนโปรแกรมเชิงมุมมองเพื่อป้องกันการโจมตีแอปพลิเคชัน 1/6
• Aspect Oriented Programming: Radical Research in ModularityโดยGregor Kiczales (คนหลักที่อยู่เบื้องหลัง AOP)

ลักษณะและกราฟ

ลักษณะเป็นอีกโครงสร้างหนึ่งสำหรับการกำหนดรหัสที่สามารถใช้ซ้ำได้ซึ่งเติมเต็ม OOP ซึ่งคล้ายกับมิกซ์อินแต่สะอาดกว่า

แทนที่จะอธิบายพวกเขามีPHP RFC ที่ยอดเยี่ยมที่อธิบายทั้งสองอย่าง ลักษณะจะมาถึง PHP btw พวกเขาได้ผูกมัดกับลำต้นแล้ว

สรุป

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

OOP จัดเตรียมชุดเครื่องมือที่มีประโยชน์ที่อนุญาตให้คุณเขียนโค้ดที่สามารถใช้งานได้ในหลายสถานที่มากกว่าที่คุณจะไม่มีเครื่องมือเหล่านั้น หากคุณเขียนPrintItฟังก์ชันที่ใช้วัตถุเก่าใด ๆ และเรียก.toString()ใช้คุณจะได้ใช้รหัสนั้นอีกครั้งทันทีที่คุณเรียกมันด้วยวัตถุมากกว่าหนึ่งประเภท ด้วยเครื่องมือเหล่านี้โค้ดแต่ละบรรทัดจะมีมากขึ้น

การเขียนโปรแกรมฟังก์ชั่นร้อนแรงมากในขณะนี้ในหมู่ hipsters มันมีชุดเครื่องมือแยกต่างหากให้คุณเพื่อให้โค้ดแต่ละบรรทัดทำงานได้มากขึ้น มันอาจจะไม่ดีขึ้นหรือใช้งานได้ แต่มีเครื่องมืออื่นในกล่องเครื่องมือ

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

อ่านกระทู้ข้างต้นพูดไม่กี่:

• หลายคนคิดว่าการใช้รหัสซ้ำใน OOP หมายถึงการสืบทอด ผมไม่เห็นด้วย. ส่วนต่อประสานและสัญญาเป็นส่วนสำคัญในการใช้รหัสซ้ำในระบบ OOP OOP เป็นความพยายามแบบกล่องสีเทาในการสร้างเทคโนโลยีส่วนประกอบ
• ความแตกต่างระหว่างโดเมนเฉพาะและ "กรอบ" ทั่วไปที่เป็นเรื่องของการใช้ซ้ำถือว่าฉันเป็นนามธรรมเกินไป ในมุมมองของฉันในสิ่งต่าง ๆ ส่วนประกอบ (ข้อตกลงที่กระชับน้อยที่สุดและสามารถใช้งานได้อีกครั้งและการใช้งานที่อยู่เบื้องหลัง) สามารถทำได้ถ้าปัญหาที่อยู่นั้นเป็นที่เข้าใจกันดี ส่วนประกอบเฉพาะของโดเมนซึ่งช่วยให้ผู้เชี่ยวชาญที่ไม่ใช่โดเมนทำงานได้โดยมีความรู้น้อยเกี่ยวกับโดเมนเป็นส่วนประกอบที่มีประโยชน์ ผู้ใช้จำเป็นต้องเข้าใจอินเตอร์เฟสน้อยกว่าความซับซ้อนของโดเมนปัญหา
• ระดับของการใช้ซ้ำมักจะถูกลืม: การนำความคิดกลับมาใช้ใหม่การนำข้อมูลจำเพาะสถาปัตยกรรม / การออกแบบกลับมาใช้ใหม่การใช้ซ้ำอินเตอร์เฟสการใช้ซ้ำกรณีทดสอบ การใช้รหัสซ้ำอาจไม่ได้ผลดีเสมอไป แต่มันเป็นการประหยัดครั้งใหญ่ที่จะยึดติดกับสถาปัตยกรรมเฉพาะเพื่อจัดการผลิตภัณฑ์ใหม่ที่คล้ายคลึงกัน
• รูปแบบการออกแบบ OOP (Gamma et. al) ในสายตาของฉันได้อธิบายอย่างละเอียดเกี่ยวกับเทคนิคการนำยุทธวิธีมาใช้แทนที่จะมีความหมายในบริบทของการใช้รหัสซ้ำในระดับที่ใหญ่ขึ้น พวกเขาช่วยเขียนแอปพลิเคชันที่มีองค์ประกอบ OOP แต่ฉันจะไม่เห็นพวกเขาเป็นโซลูชันสำหรับคำถาม "ใช้ซ้ำรหัส" เกินกว่าแอปพลิเคชันเดียว
• อาจจะไม่ยุติธรรม: ประสบการณ์ C / C ++ / C # 20 ปีและการเขียนโปรแกรมใช้งานได้ 6 เดือน (F #) องค์ประกอบสำคัญอย่างหนึ่งของการเปิดใช้งานการนำกลับมาใช้ใหม่คือ: ผู้คนจำเป็นต้องค้นหา "อินเทอร์เฟซ" อย่างง่ายศึกษาศึกษาเข้าใจแล้วใช้มัน การเขียนโปรแกรมที่ใช้งานได้จริงไม่ได้ทำให้ฉันเห็นโครงสร้างผู้สมัครเพื่อนำมาใช้ซ้ำได้ง่ายหรือเริ่มต้นที่ไหนและจบลงอย่างไร "น้ำตาลซินแทติกเชียล" ที่น่าชื่นชมเป็นอย่างมากคือเกลือในสายตาของฉันทำให้ฉันไม่สามารถเห็นสิ่งที่เกิดขึ้นได้อย่างง่ายดาย ดังนั้นฉันจึงมีโอกาสน้อยที่จะพยายามใช้ฟังก์ชั่นใหม่ (มันคืออะไร - ฟังก์ชั่นมากมาย?) ซึ่งอาจมีผลข้างเคียงที่ซ่อนอยู่ซึ่งฉันไม่สามารถมองเห็นได้ อย่าเข้าใจฉันผิดการเขียนโปรแกรมที่ใช้งานได้ดีมาก ๆ แต่จุดแข็งทั้งหมดที่ฉันเห็นด้วยความสงสัย
• สเปค, การออกแบบ, การใช้งานจะถูกเชื่อมโยงเข้าด้วยกัน สิ่งที่สำคัญยิ่งกว่าสำหรับการเพิ่มผลผลิตในอนาคตมากกว่ากระบวนทัศน์การเขียนโปรแกรมใหม่คือการปิดช่องว่างเพื่อเพิ่ม (การให้เหตุผลอัตโนมัติ, การตรวจสอบย้อนกลับ) ซึ่งเป็นประโยชน์ร่วมกันระหว่างมุมมองเหล่านั้น ภาษาสเปคที่เป็นทางการ, สัญลักษณ์ทดสอบที่เป็นมาตรฐาน (เช่น ttcn3) และภาษาโปรแกรมที่รองรับการตรวจสอบอินเทอร์เฟซและสัญญากับข้อกำหนดโดยไม่ทิ้งความคิดเห็นอาจเป็นสิ่งที่เราต้องการอย่างเร่งด่วนที่สุด

ปัญหาคือสิ่งที่ลึกซึ้งยิ่งขึ้น:

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

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

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

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

... ซึ่งนำไปสู่ความละเอียดอ่อนครั้งสุดท้าย: การใช้รหัสซ้ำเป็นเรื่องเกี่ยวกับส่วนติดต่อผู้ใช้ | รหัสไม่ใช่เกี่ยวกับรหัสเท่านั้น OOP ทำงานได้ดีในการให้บริการอินเทอร์เฟซนี้เนื่องจากแมปได้ดีกับจำนวนผู้ที่คิดเกี่ยวกับโค้ดที่เขียนในปัจจุบัน FP อาจจะดีกว่าสำหรับการนำโค้ดกลับมาใช้ใหม่ แต่ imho ไม่ได้นำมาใช้ซ้ำได้อย่างง่ายดายชนิดของรหัสที่ผู้คนจำเป็นต้องเขียนในปัจจุบัน สิ่งนี้จะเปลี่ยนเป็นรหัสที่เราต้องเขียนการเปลี่ยนแปลง

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