เหตุใดโมเดลโดเมน anemic จึงถือว่าไม่ดีใน C # / OOP แต่สำคัญมากใน F # / FP

ในโพสต์บล็อกใน F # เพื่อความสนุกสนานและผลกำไรกล่าวว่า:

ในการออกแบบฟังก์ชั่นมันสำคัญมากที่จะแยกพฤติกรรมออกจากข้อมูล ชนิดข้อมูลนั้นง่ายและ "โง่" จากนั้นคุณก็มีฟังก์ชั่นหลายอย่างที่ทำงานกับชนิดข้อมูลเหล่านั้น

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

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

ระบุว่าใน C # เราดูเหมือนจะยืมต่อจาก F # และพยายามเขียนโค้ดสไตล์การทำงานมากขึ้น ทำไมเราไม่ยืมความคิดในการแยกข้อมูล / พฤติกรรมและคิดว่ามันไม่ดี? มันเป็นเพียงแค่ว่าคำจำกัดความไม่ได้มาพร้อมกับ OOP หรือมีเหตุผลที่เป็นรูปธรรมว่ามันไม่ดีใน C # ที่ด้วยเหตุผลบางอย่างไม่ได้ใช้ใน F # (และในความเป็นจริงจะกลับรายการ)?

(หมายเหตุ: ฉันสนใจเป็นพิเศษในความแตกต่างใน C # / F # ที่สามารถเปลี่ยนความคิดเห็นของสิ่งที่ดี / ไม่ดีแทนที่จะเป็นบุคคลที่อาจไม่เห็นด้วยกับความเห็นทั้งในโพสต์บล็อก)

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

ใน C # OOP มีแนวคิดของการมอบหมายความรับผิดชอบที่คุณมอบหมายการจัดการของวัตถุให้กับมันดังนั้นคุณจึงต้องการให้มันเปลี่ยน internals ของตัวเอง

ใน FP คุณไม่ต้องการเปลี่ยนค่าในวัตถุดังนั้นการมีฟังก์ชั่นของคุณฝังอยู่ในวัตถุของคุณไม่สมเหตุสมผล

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

ปัญหาที่ใหญ่ที่สุดที่ฉันเคยเห็นในโมเดลโดเมน anemic ใน C # OOP คือคุณท้ายด้วยรหัสที่ซ้ำกันเพราะคุณมี DTO x และฟังก์ชันที่แตกต่างกัน 4 หน้าที่ที่กระทำกิจกรรม f ถึง DTO x เพราะ 4 คนไม่เห็นการใช้งานอื่น . เมื่อคุณวางเมธอดลงบน DTO x โดยตรงดังนั้นทั้ง 4 คนจะเห็นการใช้ f และนำกลับมาใช้ใหม่

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

ตามที่ระบุไว้ในความคิดเห็นการอนุมานประเภทเป็นหนึ่งในประโยชน์ที่ได้รับจากการพึ่งพาเพื่อให้เกิดความแตกต่างอย่างมีนัยสำคัญและโดยเฉพาะคุณสามารถติดตามกลับไปที่ระบบพิมพ์Hindley Milnerด้วยการอนุมานอัลกอริธึม W การอนุมานประเภทดังกล่าวในระบบประเภท C # OOP ถูกหลีกเลี่ยงเนื่องจากเวลารวบรวมเมื่อการอนุมานอิงตามข้อ จำกัด นั้นยาวมากเนื่องจากจำเป็นต้องค้นหาอย่างละเอียดรายละเอียดที่นี่: https://stackoverflow.com/questions/3968834/generics-why -cant ที่คอมไพเลอร์-สรุป-the-ชนิดข้อโต้แย้งในนี้กรณี

เหตุใดโมเดลโดเมน anemic จึงถือว่าไม่ดีใน C # / OOP แต่สำคัญมากใน F # / FP

คำถามของคุณมีปัญหาใหญ่ที่จะ จำกัด ยูทิลิตี้ของคำตอบที่คุณได้รับ: คุณหมายถึง / สมมติว่า F # และ FP คล้ายกัน FP เป็นตระกูลใหญ่ของภาษารวมถึงการเขียนคำซ้ำสัญลักษณ์แบบไดนามิกและแบบคงที่ แม้ในภาษา FP ที่พิมพ์แบบสแตติกมีเทคโนโลยีที่แตกต่างกันมากมายสำหรับการแสดงโมเดลโดเมนเช่นโมดูลลำดับสูงกว่าใน OCaml และ SML (ที่ไม่มีอยู่ใน F #) F # เป็นหนึ่งในภาษาที่ใช้งานได้เหล่านี้ แต่มีความโดดเด่นเป็นพิเศษสำหรับการเรียนแบบ Lean และโดยเฉพาะอย่างยิ่งไม่ได้จัดเตรียมโมดูลที่สูงกว่าหรือประเภทที่สูงกว่า

ที่จริงแล้วฉันไม่สามารถบอกคุณได้ว่าแบบจำลองโดเมนแสดงใน FP อย่างไร คำตอบอื่น ๆ ที่นี่พูดถึงโดยเฉพาะอย่างยิ่งเกี่ยวกับวิธีการทำใน Haskell และไม่สามารถใช้ได้กับ Lisp (แม่ของภาษา FP ทั้งหมด), ตระกูล ML ของภาษาหรือภาษาอื่น ๆ

ทำไมเราไม่ยืมความคิดในการแยกข้อมูล / พฤติกรรมและคิดว่ามันไม่ดี?

ยาสามัญอาจพิจารณาวิธีการแยกข้อมูลและพฤติกรรม Generics มาจากตระกูล ML ของภาษาโปรแกรมการทำงานไม่ใช่ส่วนหนึ่งของ OOP C # มีข้อมูลทั่วไปแน่นอน ดังนั้นเราอาจโต้แย้งว่า C # ยืมความคิดในการแยกข้อมูลและพฤติกรรมอย่างช้าๆ

มันเป็นเพียงแค่ว่าคำจำกัดความไม่เหมาะสมกับ OOP

ฉันเชื่อว่า OOP ขึ้นอยู่กับสถานที่ตั้งที่แตกต่างกันโดยพื้นฐานและดังนั้นจึงไม่ได้ให้เครื่องมือที่คุณต้องการในการแยกข้อมูลและพฤติกรรม เพื่อวัตถุประสงค์ในทางปฏิบัติทั้งหมดคุณต้องการผลิตภัณฑ์และประเภทข้อมูลและส่งไปพวกเขา ใน ML หมายถึงยูเนี่ยนและประเภทบันทึกและการจับคู่รูปแบบ

ตรวจสอบตัวอย่างผมให้ที่นี่

หรือมีเหตุผลอย่างชัดเจนที่ทำให้ C # นั้นไม่ดีด้วยเหตุผลบางอย่างที่ใช้ไม่ได้ใน F # (และที่จริงแล้วกลับกัน)

ระวังการกระโดดจาก OOP ไปยัง C # C # ไม่มีความใกล้เคียงกับเจ้าระเบียบเกี่ยวกับ OOP เหมือนกับภาษาอื่น ๆ .NET Framework ตอนนี้เต็มไปด้วย generics วิธีการคงที่และแม้กระทั่ง lambdas

(หมายเหตุ: ฉันสนใจเป็นพิเศษในความแตกต่างใน C # / F # ที่สามารถเปลี่ยนความคิดเห็นของสิ่งที่ดี / ไม่ดีแทนที่จะเป็นบุคคลที่อาจไม่เห็นด้วยกับความเห็นทั้งในโพสต์บล็อก)

การขาดประเภทสหภาพและการจับคู่รูปแบบใน C # ทำให้แทบเป็นไปไม่ได้ที่จะทำ เมื่อทุกสิ่งที่คุณมีคือค้อนทุกอย่างดูเหมือนเล็บ ...

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