โครงการของฉันสามารถอยู่รอดโดยปราศจากการวางแนววัตถุหรือไม่

ฉันกำลังเขียนแพคเกจ MATLAB ขนาดเล็กซึ่งจะแก้ปัญหาเรื่องตัวเลขในระดับหนึ่ง อัลกอริทึมมี 3 ขั้นตอนและผู้ใช้มี 5 ตัวเลือกสำหรับแต่ละสเตจ ฉันใช้ปัญหาทั้งหมดไปแล้วโดยใช้$\approx 20$ฟังก์ชั่นและ 3 สวิตช์กรณี (หนึ่งสำหรับแต่ละขั้นตอนวิธี) มันใช้งานได้ดี แต่ฉันกำลังพิจารณาที่จะทำสิ่งต่าง ๆ (มีให้เลือกมากกว่า 5 ตัวเลือกและอีกหนึ่งเวที) และสร้างพอร์ต Python (บางคนสนใจ)

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

โปรดย้ายข้อมูลนี้ไปยัง SO หากคุณคิดว่าเหมาะสมในโดเมนของพวกเขา

ไม่จำเป็นต้องแปลงเป็น OOP framework เพื่อรับประโยชน์จากการวางแนววัตถุที่ช่วย โปรดทราบว่าจำนวนฟังก์ชั่นน้อยกว่าตัวบ่งชี้กว่าการทำสำเนารหัสภายในและระหว่างฟังก์ชั่นเหล่านี้หรือความยาวของฟังก์ชั่นเหล่านี้ (ฟังก์ชั่นที่มีโค้ดมากกว่า 100 บรรทัดจะเป็นตัวบ่งชี้ทั่วไปสำหรับ "โอกาสในการพัฒนา")

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

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

สำหรับพอร์ต Python เพียงแค่ทำตามความรู้ปัจจุบันของคุณสำหรับการเริ่มต้นและมีการเริ่มต้นที่สองในภายหลังหลังจากที่คุณเรียนรู้มากพอที่จะทำให้ดีขึ้นอย่างมีนัยสำคัญ

คำถามนี้อาจเหมาะสำหรับ Stack Overflow ฉันคิดว่ามันก็เป็นแบบที่ดีที่นี่เพราะมันเป็นปัญหาที่พบบ่อยในวิทยาศาสตร์การคำนวณ

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

ไม่ใช่ทุกสิ่งที่จำลองมาจากวัตถุ พิจารณา$1 + 1$ซึ่งโดยทั่วไปแล้วระบบ OO จะปฏิบัติต่อ1s เป็นวัตถุและ+เป็นวิธี1.plus(1)แต่ไม่สอดคล้องกับการตีความตามธรรมชาติของเรา$1+1$เป็นฟังก์ชั่นไบนารีมัดplus(1,1); มันแนะนำสมส่วนผิดธรรมชาติระหว่างครั้งแรก1ในฐานะที่เป็นวัตถุที่วิธีการที่plusถูกกำหนดและที่สองซึ่งเป็นข้อโต้แย้งที่จะวิธีการที่ (ซึ่งก่อให้เกิด kludges ชอบ__plus__และ__rplus__ในหลาม)

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