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

อะไรเป็นแรงบันดาลใจจากคำถามนี้: สำหรับปัญหาที่พบบ่อยคือการตั้งโปรแกรมการทำงานที่ไม่เหมาะสม - แต่อย่างไรก็ตามคำถามที่ฉันต้องการเสมอ แต่ก็กลัวที่จะถาม

ฉันอยู่ใน ... ดีมาเรียกมันว่าการพัฒนาซอฟต์แวร์ทางวิศวกรรมเกือบตลอดชีวิตของฉันและในช่วงเวลานั้นถึงแม้ว่า OO จะอยู่ที่นั่นเสมอ ( ส่วนใหญ่แล้ว) ฉันไม่เคยต้องการใช้ "วิธีการของมัน" หรือเรียนรู้กระบวนทัศน์นั้น เราใช้โครงสร้างของโปรแกรมที่ค่อนข้างง่ายรูทีน / ฟังก์ชั่น / โมดูลและตรงข้ามกับแนวปฏิบัติที่ดีที่สุดของวันนี้ในการจัดการโปรแกรมเหล่านั้น (โปรแกรมที่มีความยาวไม่เกิน 300k LOC ไม่มีอะไรใหญ่เกินไป) ไม่เคยพิสูจน์ว่าเป็นเรื่องยาก

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

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

William Cookอธิบายความแตกต่างระหว่างวัตถุและชนิดข้อมูลนามธรรมอย่างชัดเจน

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

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

การทำงานพร้อมกัน: กลไกการล็อคดูเหมือนว่าเป็นปัญหา มีเพียงนักพัฒนาที่ดีมากเท่านั้นที่ทำงานในส่วนของเธรด

การขยาย: ไม่ทราบว่าภาษา OO ที่ขยายได้ในปัจจุบันเป็นอย่างไร รู้เพียงว่า Java ไม่ดี ดังนั้น DSL (ภาษาเฉพาะโดเมน) จะต้องดำเนินการในฐานะ Framework Clojure ในอีกทางหนึ่ง (นั่นคือการทำงาน) มีมาโคร

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

อัลกอริทึมหลักเช่นqsort()ใช้ abstractions สำหรับการเปรียบเทียบวัตถุโดยพลการ fread()ใช้ส่วนต่อประสานเพื่อย่อรายละเอียดของกระแสเป็นต้น

จากมุมมองนั้นฉันพบว่ามันยากที่จะเกิดขึ้นกับปัญหาเฉพาะที่แก้ไขได้ดีกว่าด้วยวิธีการที่ไม่ใช่ OO

ฉันคิดว่าเมื่อสร้างระบบที่รวมระบบอื่น ๆ ผ่านเว็บ apis (ส่วนที่เหลือ xmlprc, curl / wget ธรรมดา) คุณสามารถเขียน wraps OO แต่ชัดเจนว่ามันสะดวก หากบริการเว็บที่จะใช้นั้นเรียบง่ายและเป็นเพียงเรื่องของหนึ่งหรือสองบรรทัด OO นั้นมากเกินไป ถ้าในอีกแง่หนึ่งคุณต้องห่อเว็บ API ที่ซับซ้อน (เช่น Amazon AWS เป็นต้น) ก็ดีที่มีไลบรารีแรปเปอร์ (เช่น boto ใน python สำหรับ AWS)

คิด?

ภาษาเชิงวัตถุของ PURE ไม่เหมาะกับหลาย ๆ กรณี เนื่องจากมีเกณฑ์บางประการที่จะต้องทำให้สำเร็จสำหรับการเป็นภาษาเชิงวัตถุบริสุทธิ์ ดู -
/programming/250062/what-is-meant-by-the-term-true-object-orientation/250098#250098

แต่ภาษาการเขียนโปรแกรมที่ใช้กันอย่างแพร่หลายส่วนใหญ่เป็นแบบหลายกระบวนทัศน์ พวกเขารวมคุณสมบัติที่ไม่ใช่ OO จำนวนมากเพื่อพบปัญหาการเขียนโปรแกรมและการพัฒนาประเภทต่างๆ C ++, C #, Java หรือ Ruby ทั้งหมดมีฟังก์ชันที่ไม่ใช่ OO ดังนั้นพวกเขาสามารถเผชิญปัญหาที่บริสุทธิ์ -OO ไม่ดีที่

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

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

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

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