ฟังก์ชั่นการเขียนโปรแกรมเทียบกับการเขียนโปรแกรมเชิงวัตถุ [ปิด]

ฉันได้รับส่วนใหญ่สัมผัสกับการเขียนโปรแกรม OO เพื่อให้ห่างไกลและฉันหวังว่าจะได้เรียนรู้ภาษาที่ใช้งานได้ คำถามของฉันคือ:

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

คุณจะเลือกการเขียนโปรแกรมการทำงานมากกว่าวัตถุที่มุ่งเน้น?

เมื่อคุณคาดการณ์วิวัฒนาการซอฟต์แวร์ประเภทต่าง ๆ :

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

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

เมื่อวิวัฒนาการไปในทางที่ผิดคุณมีปัญหา:

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

• การเพิ่มสิ่งใหม่ลงในโปรแกรมการใช้งานอาจจำเป็นต้องแก้ไขนิยามฟังก์ชันจำนวนมากเพื่อเพิ่มเคสใหม่

ปัญหานี้เป็นที่รู้จักกันดีมานานหลายปี ในปี 1998 ฟิล Wadler ขนานนามมันว่า "ปัญหาการแสดงออก" แม้ว่านักวิจัยบางคนคิดว่าปัญหาการแสดงออกสามารถแก้ไขได้ด้วยคุณสมบัติทางภาษาเช่นมิกซ์อิน แต่วิธีการแก้ปัญหาที่ได้รับการยอมรับอย่างกว้างขวางก็ยังไม่เป็นที่นิยม

อะไรคือคำจำกัดความของปัญหาทั่วไปที่การตั้งโปรแกรมการทำงานเป็นตัวเลือกที่ดีกว่า

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

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

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

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

ภาษาสมัยใหม่หลายภาษาเป็นกระบวนทัศน์ที่หลากหลาย

อ่านที่แนะนำ

ในขณะที่ฉันอยู่ในเรือลำเดียวกัน (พื้นหลังของ OOP, การเรียนรู้ FP) ฉันขอแนะนำให้คุณอ่านบางอย่างที่ฉันชื่นชมจริงๆ:

• การเขียนโปรแกรมเชิงหน้าที่เพื่อการพัฒนา. NET ทุกวันโดย Jeremy Miller บทความที่ดี (แม้ว่าจะมีการจัดรูปแบบไม่ดี) แสดงให้เห็นถึงเทคนิคมากมายและตัวอย่างการใช้งานจริงของ FP บน C #

• การเขียนโปรแกรมใช้งานจริงในโลกโดย Tomas Petricek หนังสือยอดเยี่ยมที่เกี่ยวกับแนวคิดของ FP โดยส่วนใหญ่พยายามอธิบายสิ่งที่พวกเขาควรใช้เมื่อใด มีตัวอย่างมากมายทั้งใน F # และ C # นอกจากนี้บล็อกของ Petricekยังเป็นแหล่งข้อมูลที่ดีเยี่ยม

ข้อเสนอการเขียนโปรแกรมเชิงวัตถุ:

1. การห่อหุ้ม
   • การกลายพันธุ์ควบคุมของรัฐภายใน
   • จำกัด การมีเพศสัมพันธ์กับการเป็นตัวแทนภายใน
2. ชนิดย่อยที่อนุญาต:
   • การทดแทนประเภทที่เข้ากันได้ (polymorphism)
   • วิธีการแบ่งปันการใช้งานระหว่างชั้นเรียนอย่างหยาบ

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

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

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

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

2. ในภาษาหลายรูปแบบคุณอาจต้องการสร้างแบบจำลองบางสิ่งบางอย่างทำงานได้หากการดำรงอยู่ของรัฐที่ไม่แน่นอนจะต้องมีรายละเอียดการใช้งานและทำให้ FP เป็นแบบจำลองที่ดีสำหรับโดเมนปัญหา ตัวอย่างเช่นดูรายการความเข้าใจใน Python หรือstd.rangeในภาษาการเขียนโปรแกรม D เหล่านี้เป็นแรงบันดาลใจจากการเขียนโปรแกรมการทำงาน