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

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

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

ข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่ต้องทำ:

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

ตอนนี้มันไม่ได้เป็นแอพพลิเคชั่นขนาดใหญ่ / หนักและมันก็เกือบจะเสร็จสิ้นแล้ว แต่ในระหว่างกระบวนการพัฒนาทั้งหมดฉันก็ถามตัวเองว่าควรจะใช้ OOP หรือไม่

ดังนั้นคำถามของฉันคือ: คุณรู้จัก / ตัดสินใจว่าจะใช้ OOPในแอปพลิเคชันได้อย่างไร

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

ฉันสังเกตว่าโปรแกรมของคุณเป็นแอพ CLI ที่อ่านอินพุตบางไฟล์ (csv และไฟล์ config) และสร้างเอาต์พุตบางไฟล์ (ไฟล์ xml) แต่ไม่สามารถโต้ตอบได้และดังนั้นจึงไม่มี GUI หรือ API ที่ไม่ทำงาน โปรแกรมดังกล่าวจะแสดงออกมาเป็นฟังก์ชั่นตามธรรมชาติจากอินพุตไปยังเอาต์พุตซึ่งมอบหมายให้ฟังก์ชั่นอื่น ๆ สำหรับงานย่อย

OO นั้นเกี่ยวกับการห่อหุ้มสถานะที่ไม่แน่นอนดังนั้นจึงเหมาะสมกว่าสำหรับแอปพลิเคชันแบบโต้ตอบ, GUI และ API ที่เปิดเผยสถานะที่ไม่แน่นอน มันไม่ใช่เรื่องบังเอิญที่ OO ได้รับการพัฒนาควบคู่ไปกับ GUI ตัวแรก

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

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

Bottom line: ฉันขอแนะนำกลุ่มฟังก์ชันที่แบ่งเป็นโมดูลสำหรับองค์กร แต่ไม่มีวัตถุ

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

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

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

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

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

การเขียนโปรแกรมเชิงวัตถุเพิ่มเครื่องมือใหม่สี่อย่างลงในคลังแสงของคุณ:

1. encapsulation
2. สิ่งที่เป็นนามธรรม
3. มรดก
4. ความแตกต่าง

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

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

จากความคิดเห็นที่นี่ใช่ Python สนับสนุนกระบวนทัศน์การทำงาน แต่เป็นวัตถุพื้นฐาน ภาษาตัวเองและ libs ในตัวจะเน้นไปที่วัตถุ ใช่มันรองรับแลมบ์ดา (เช่นเดียวกับ Java และภาษาอื่น ๆ อีกมากมายที่ปกติจะอธิบายว่าเป็น OO) แต่ก็จงใจง่ายเมื่อเทียบกับภาษาที่ใช้งานได้จริง

บางทีความแตกต่างเหล่านี้เกี่ยวกับการออกแบบ OO และการออกแบบฟังก์ชั่นกำลังล้าสมัย ถ้าฉันสร้างฟังก์ชั่น polymorphic บน OO ที่ออกแบบ Object * และส่งตัวชี้ไปยังฟังก์ชันนั้นบนวัตถุเป็นพารามิเตอร์ไปยังฟังก์ชันที่มีสไตล์ตามหน้าที่ * นั่นคือ OO หรือไม่ ฉันคิดว่ามันเป็นทั้งสองอย่างและเป็นวิธีการที่มีประสิทธิภาพจริงๆในการแก้ปัญหา

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

* ความซ้ำซ้อนเป็นความตั้งใจ: ฉันไม่ต้องการถูกกล่าวหาว่าเป็นวัตถุ OO หรือฟังก์ชั่นทำงานได้

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

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

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

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

และสิ่งที่ดีคือคุณสามารถทดสอบได้

ในแง่ของคนธรรมดา:

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

ที่กล่าวว่ามีปัจจัยอื่น ๆ ที่ต้องคำนึงถึง:

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

อย่าเข้าใจฉันผิด: คุณสามารถบรรลุทุกสิ่งโดยไม่ใช้ OOP แต่ด้วย OOP จะง่ายขึ้น

แต่...

หากทีมของคุณไม่เชี่ยวชาญใน OOP / OOD และไม่มีความเชี่ยวชาญในพื้นที่นั้นไปกับทรัพยากรที่คุณมี

ดังนั้นคำถามของฉันคือ: คุณรู้จัก / ตัดสินใจว่าจะใช้ OOP ในแอปพลิเคชันได้อย่างไร

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

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

• ตัวอย่างการบันทึกเพราะมันทำให้ง่ายต่อการแทนที่คนตัดไม้ที่แตกต่างกัน

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

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

การเขียนโปรแกรมเชิงวัตถุมีเครื่องมือในการสร้างกรอบ เครื่องมือเหล่านี้คือ Encapsulation, Abstraction, Inheritance และ Polymorphism แนวคิดเหล่านี้จะช่วยคุณแบ่งโปรแกรมออกเป็นสองส่วน

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

จะทำอย่างไร - ส่วนนี้เป็นที่ที่บล็อกทำหน้าที่ได้จริง นี่คือคลาสที่ได้รับมาจากคลาสพื้นฐานที่สร้างใน "วิธีการส่วน"

หนึ่งสามารถได้รับประโยชน์อย่างมากจาก OOPS

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