เทียบเท่าหลักการของ SOLID สำหรับการโปรแกรมเชิงฟังก์ชัน

ฉันพบว่าหลักการของ SOLIDค่อนข้างมีประโยชน์เมื่อคิดถึงการออกแบบเชิงวัตถุ

มีหลักการเกี่ยวกับภาษาที่ไม่เชื่อเรื่องพระเจ้า / ชุดที่คล้ายกันเหมาะสำหรับการเขียนโปรแกรมการทำงานหรือไม่?

design-patterns functional-programming solid

FWIW ได้มีการพูดคุยกันสั้น ๆ เกี่ยวกับSOเมื่อปีที่แล้ว

— StuartLC

DI และ HOF: programmers.stackexchange.com/questions/103508/…

— paul

วิดีโอนี้รวมถึงสไลด์เหล่านี้นำเสนอหลักการ SOLID ที่ใช้กับฟังก์ชั่นการเขียนโปรแกรม พวกเขาทั้งสองใช้ภาษา Clojure เป็นตัวอย่าง แต่หลักการมีไว้ในภาษาอื่น

— คาร่า

slideshare.net/RichardWarburton/ …

— Ray Tayek

ดูเพิ่มเติมที่: การเขียนโปรแกรมใช้งานเป็นชุดของวัตถุที่มุ่งเน้น?

— ริ้น

คำตอบ:

มันยากที่จะหาสิ่งที่เทียบเท่า แต่ฉันสามารถลอง:

S (SRP) ใน FP ฟังก์ชั่นสร้างเสมอผลลัพธ์เดียวกันสำหรับอาร์กิวเมนต์เดียวกันนี้เรียกว่าโปร่งใสอ้างอิง
O (OCP) ใน FP มีแนวคิดที่เรียกว่าชนิดข้อมูลเกี่ยวกับพีชคณิตลองดูว่ามันเกี่ยวข้องกับลำดับชั้นของชั้นเรียนอย่างไรและปัญหาอะไรที่ทั้งคู่พยายามแก้ไข¹
L (LSP) หลักการทดแทน Liskov คือความขัดแย้ง²
D (DIP) ในการเขียนโปรแกรมการทำงานทั่วไปบรรลุความเป็นนามธรรมผ่านองค์ประกอบของฟังก์ชั่นนอกจากนี้ยังมีกลไกอื่น ๆ ด้วยความช่วยเหลือของทฤษฎีหมวดหมู่ (เช่น monoid หรือ functor) สำหรับ "Dependency Injection" ³

— AndreasScheinert
แหล่งที่มา

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

— Goran Jovic

อ่าฉันไม่ดี - ฉันเข้าใจแล้วตอนนี้ สิ่งเหล่านี้เทียบเท่าในแง่ของการเป็นหลักการและการสร้างตัวย่อเดียวกันไม่ได้หมายถึงสิ่งที่เหมือนกันหรือคล้ายกัน ขออภัยสำหรับ downvote!

— Goran Jovic

ใช่นั่นเป็นวิธีที่ตั้งใจจะอ่าน ฉันพยายามอธิบายการทำแผนที่สำหรับคำเหล่านั้นในบริบทของ fp

— AndreasScheinert

ผู้ชายฉันเกลียดที่คุณไม่สามารถแก้ไขความคิดเห็นในความเป็นจริงสิ่งที่ SHOULD หมายถึงอย่างน้อยสิ่งที่คล้ายกัน

— AndreasScheinert

บางทีฟังก์ชั่นที่มีลำดับสูงกว่าอาจให้การฉีดพึ่งพาบางอย่าง: คุณฉีดฟังก์ชั่นคอนกรีตเป็นพารามิเตอร์ในฟังก์ชั่นทั่วไป (ลำดับที่สูงกว่า)

— Giorgio

SOLID กลายเป็นความคิดที่ดีสำหรับขอบเขตการทำงาน / ความจำเป็นเช่นกัน

SRP - 'ทำสิ่งเดียวเท่านั้น' ถูกนำมาจากการเขียนโปรแกรมที่จำเป็นในตอนแรก การมีฟังก์ชั่นเล็ก ๆ ที่เน้นโฟกัสนั้นดี

OCP - ช่วยให้คุณสามารถเปลี่ยนพฤติกรรมโดยไม่ต้องแก้ไขโค้ดได้ดี ฟังก์ชั่นการเขียนโปรแกรมใช้ฟังก์ชั่นการสั่งซื้อสูงกว่ามรดก แต่หลักการถือ

LSP - การปฏิบัติตามสัญญาส่วนต่อประสานนั้นดีพอ ๆ กับการเขียนโปรแกรมเชิงฟังก์ชันเช่นเดียวกับการวางวัตถุ หากฟังก์ชันการเรียงลำดับใช้ตัวเปรียบเทียบคุณจะคาดหวังว่า '0 จะเท่ากับน้อยกว่าที่ให้ผลลัพธ์เชิงลบมากกว่าพฤติกรรมที่เป็นบวกมากกว่า'

ISP - ภาษาที่ใช้งานได้ส่วนใหญ่ยังคงมีโครงสร้าง การระบุชุดข้อมูลที่เล็กที่สุดที่จำเป็นสำหรับฟังก์ชั่นยังคงเป็นแนวปฏิบัติที่ดี ต้องการอินเทอร์เฟซที่เจาะจงน้อยที่สุดกับข้อมูล (เหตุใดจึงใช้รายการของ ints เมื่อ Enumerations of T ทำงานด้วย?) ยังคงเป็นแนวปฏิบัติที่ดี

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

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

— Telastyn
แหล่งที่มา