โพสต์บล็อกที่คุณยกมาพูดเกินจริงเรียกร้องเล็กน้อย FP ไม่ได้กำจัดความต้องการรูปแบบการออกแบบ คำว่า "รูปแบบการออกแบบ" ไม่ได้ใช้อย่างกว้างขวางเพื่ออธิบายสิ่งเดียวกันในภาษา FP แต่พวกเขามีอยู่ ภาษาหน้าที่มีกฎการปฏิบัติที่ดีที่สุดมากมายของรูปแบบ "เมื่อคุณพบปัญหา X ใช้รหัสที่มีลักษณะเหมือน Y" ซึ่งโดยทั่วไปก็คือรูปแบบการออกแบบ
อย่างไรก็ตามมันถูกต้องว่ารูปแบบการออกแบบเฉพาะ OOP ส่วนใหญ่นั้นไม่เกี่ยวข้องกับภาษาที่ใช้งานได้จริง
ฉันไม่คิดว่ามันควรจะเป็นความขัดแย้งโดยเฉพาะอย่างยิ่งที่จะบอกว่ารูปแบบการออกแบบโดยทั่วไปมีอยู่เพียงเพื่อแก้ไขข้อบกพร่องในภาษา และหากภาษาอื่นสามารถแก้ไขปัญหาเดียวกันได้เล็กน้อยภาษาอื่นไม่จำเป็นต้องมีรูปแบบการออกแบบสำหรับภาษานั้น ผู้ใช้ภาษานั้นอาจไม่ทราบด้วยซ้ำว่าปัญหานั้นเกิดขึ้นเพราะก็ไม่ใช่ปัญหาในภาษานั้น
นี่คือสิ่งที่ Gang of Four พูดถึงเกี่ยวกับปัญหานี้:
การเลือกภาษาโปรแกรมเป็นสิ่งสำคัญเพราะมันมีอิทธิพลต่อมุมมองของคน ๆ หนึ่ง รูปแบบของเราถือว่าคุณสมบัติภาษาระดับ Smalltalk / C ++ และตัวเลือกนั้นเป็นตัวกำหนดสิ่งที่สามารถและไม่สามารถนำไปปฏิบัติได้อย่างง่ายดาย หากเราสันนิษฐานว่าภาษาเชิงโพรซีเดอร์เราอาจรวมรูปแบบการออกแบบที่เรียกว่า "Inheritance", "Encapsulation," และ "Polymorphism" ในทำนองเดียวกันบางรูปแบบของเราได้รับการสนับสนุนโดยตรงจากภาษาเชิงวัตถุที่พบได้น้อย CLOS มีหลายวิธีเช่นซึ่งช่วยลดความต้องการรูปแบบเช่น Visitor ในความเป็นจริงมี Smalltalk และ C ++ แตกต่างกันมากพอที่จะหมายความว่ารูปแบบบางอย่างสามารถแสดงได้อย่างง่ายดายในภาษาหนึ่งมากกว่าอีกภาษาหนึ่ง (ดูที่ Iterator เป็นต้น)
(ข้างต้นเป็นคำพูดจากหนังสือแนะนำรูปแบบการออกแบบหน้า 4 วรรค 3)
คุณสมบัติหลักของฟังก์ชั่นการเขียนโปรแกรมฟังก์ชั่นรวมถึงฟังก์ชั่นเป็นค่าชั้นหนึ่ง, currying, ค่าไม่เปลี่ยนรูปแบบ ฯลฯ ฉันไม่ได้ดูเหมือนชัดเจนว่ารูปแบบการออกแบบ OO จะประมาณคุณสมบัติใด ๆ เหล่านั้น
รูปแบบคำสั่งคืออะไรถ้าไม่ประมาณฟังก์ชั่นชั้นหนึ่ง? :) ในภาษา FP คุณเพียงแค่ส่งฟังก์ชันเป็นอาร์กิวเมนต์ไปยังฟังก์ชันอื่น ในภาษา OOP คุณจะต้องสรุปฟังก์ชันในคลาสซึ่งคุณสามารถสร้างอินสแตนซ์แล้วส่งวัตถุนั้นไปยังฟังก์ชันอื่น เอฟเฟกต์เหมือนกัน แต่ใน OOP เรียกว่ารูปแบบการออกแบบและใช้รหัสมากกว่าเดิมทั้งหมด และรูปแบบโรงงานที่เป็นนามธรรมคืออะไรถ้าไม่ได้แกง? ส่งพารามิเตอร์ไปยังฟังก์ชันทีละบิตเพื่อกำหนดค่าชนิดใดที่มันจะคายออกมาเมื่อคุณเรียกมันในที่สุด
ใช่รูปแบบการออกแบบ GoF หลายรูปแบบนั้นซ้ำซ้อนในภาษา FP เพราะมีตัวเลือกที่ทรงพลังกว่าและใช้งานง่ายกว่า
แต่แน่นอนว่ายังมีรูปแบบการออกแบบที่ไม่ได้รับการแก้ไขโดยภาษา FP อะไรคือสิ่งเทียบเท่า FP ของซิงเกิลตัน? (ไม่คำนึงถึงช่วงเวลาที่ซิงเกิลมักจะเป็นรูปแบบที่แย่มากที่จะใช้)
และมันก็ใช้ได้ทั้งสองทางด้วย อย่างที่ฉันบอกไปว่า FP มีรูปแบบการออกแบบเช่นกัน คนมักจะไม่คิดว่าเป็นเช่นนั้น
แต่คุณอาจวิ่งข้ามพระ พวกเขาคืออะไรถ้าไม่ใช่รูปแบบการออกแบบสำหรับ "การรับมือกับสภาวะโลกาภิวัฒน์"? นั่นเป็นปัญหาที่ง่ายมากในภาษา OOP ที่ไม่มีรูปแบบการออกแบบเทียบเท่ากัน
เราไม่จำเป็นต้องรูปแบบการออกแบบสำหรับ "เพิ่มตัวแปรคงที่" หรือ "อ่านจากซ็อกเก็ตว่า" เพราะมันเป็นเพียงสิ่งที่คุณทำ
การพูดแบบ monad เป็นรูปแบบการออกแบบที่ไร้สาระเหมือนกับการพูดถึงจำนวนเต็มที่มีการดำเนินการตามปกติและองค์ประกอบศูนย์เป็นรูปแบบการออกแบบ ไม่ Monad เป็นรูปแบบทางคณิตศาสตร์ไม่ใช่รูปแบบการออกแบบ
ในภาษาที่ใช้งานได้จริงผลข้างเคียงและสถานะที่ไม่แน่นอนนั้นเป็นไปไม่ได้เว้นแต่คุณจะหลีกเลี่ยงมันด้วยรูปแบบการออกแบบ“ monad” หรือวิธีการอื่นใดในการอนุญาตสิ่งเดียวกัน
นอกจากนี้ในภาษาที่ใช้งานได้ซึ่งสนับสนุน OOP (เช่น F # และ OCaml) ดูเหมือนว่าสำหรับฉันแล้วโปรแกรมเมอร์ที่ใช้ภาษาเหล่านี้จะใช้รูปแบบการออกแบบเดียวกันกับภาษา OOP อื่น ๆ อันที่จริงตอนนี้ฉันใช้ F # และ OCaml ทุกวันและไม่มีความแตกต่างที่โดดเด่นระหว่างรูปแบบที่ฉันใช้ในภาษาเหล่านี้เทียบกับรูปแบบที่ฉันใช้เมื่อฉันเขียนด้วย Java
อาจเป็นเพราะคุณยังคิดอย่างไม่ดีอยู่ใช่ไหม ผู้คนจำนวนมากหลังจากที่ต้องรับมือกับภาษาที่จำเป็นตลอดชีวิตพวกเขามีช่วงเวลาที่ยากลำบากในการเลิกนิสัยนี้เมื่อพวกเขาลองใช้ภาษาที่ใช้งานได้ (ฉันเคยเห็นความพยายามที่ค่อนข้างตลกที่ F # โดยแท้จริงทุกฟังก์ชั่นเป็นเพียงคำสั่ง 'Let' โดยทั่วไปราวกับว่าคุณใช้โปรแกรม C และแทนที่เครื่องหมายอัฒภาคทั้งหมดด้วย 'let' :))
แต่ความเป็นไปได้อีกอย่างหนึ่งก็คือคุณเพิ่งไม่ได้ตระหนักว่าคุณกำลังแก้ปัญหาเล็กน้อยซึ่งจะต้องใช้รูปแบบการออกแบบในภาษา OOP
เมื่อคุณใช้การ currying หรือส่งผ่านฟังก์ชันเป็นอาร์กิวเมนต์ให้หยุดและคิดเกี่ยวกับวิธีที่คุณทำในภาษา OOP
มีความจริงใด ๆ ที่อ้างว่าการเขียนโปรแกรมใช้งานได้นั้นไม่จำเป็นต้องใช้รูปแบบการออกแบบ OOP หรือไม่?
อ๋อ :) เมื่อคุณทำงานในภาษา FP คุณไม่จำเป็นต้องใช้รูปแบบการออกแบบเฉพาะ OOP อีกต่อไป แต่คุณยังต้องการรูปแบบการออกแบบทั่วไปเช่น MVC หรือสิ่งที่ไม่ใช่ OOP อื่น ๆ และคุณต้องการรูปแบบการออกแบบเฉพาะ "FP รูปแบบใหม่" สองรายการแทน ทุกภาษามีข้อบกพร่องและรูปแบบการออกแบบมักเป็นวิธีที่เราแก้ไข
อย่างไรก็ตามคุณอาจพบว่ามันน่าสนใจที่จะลองใช้ภาษา FP ที่ "สะอาด" เช่นML (รายการโปรดส่วนตัวของฉันอย่างน้อยก็เพื่อจุดประสงค์ในการเรียนรู้) หรือHaskellที่คุณไม่มีไม้ยันรักแร้ OOP ที่จะถอยกลับเมื่อคุณ กำลังเผชิญกับสิ่งใหม่
ตามที่คาดไว้มีไม่กี่คนที่คัดค้านคำจำกัดความของรูปแบบการออกแบบว่า "การแก้ไขข้อบกพร่องในภาษา" ดังนั้นนี่คือเหตุผลของฉัน:
ดังที่ได้กล่าวไปแล้วรูปแบบการออกแบบส่วนใหญ่มีความเฉพาะสำหรับกระบวนทัศน์การเขียนโปรแกรมหนึ่งภาษาหรือบางครั้งแม้แต่ภาษาเดียว บ่อยครั้งที่พวกเขาแก้ปัญหาที่มีอยู่ในกระบวนทัศน์นั้นเท่านั้น(ดู monads for FP หรือโรงงานที่เป็นนามธรรมสำหรับ OOP)
เหตุใดรูปแบบนามธรรมของโรงงานจึงไม่มีใน FP เนื่องจากปัญหาที่พยายามแก้ไขไม่มีอยู่
ดังนั้นหากปัญหามีอยู่ในภาษา OOP ซึ่งไม่มีอยู่ในภาษา FP แสดงให้เห็นอย่างชัดเจนว่าเป็นข้อบกพร่องของภาษา OOP ปัญหาสามารถแก้ไขได้ แต่ภาษาของคุณไม่สามารถทำได้ แต่ต้องใช้รหัสสำเร็จรูปจากคุณในการแก้ไข เป็นการดีที่เราต้องการให้ภาษาการเขียนโปรแกรมของเราสามารถทำให้ปัญหาทั้งหมดหายไปได้อย่างน่าอัศจรรย์ ปัญหาใด ๆ ที่ยังคงมีอยู่ในหลักการข้อบกพร่องของภาษา ;)