เมื่อการเขียนโปรแกรมในลักษณะการทำงานคุณมีสถานะแอปพลิเคชันเดียวที่คุณสานผ่านตรรกะของแอปพลิเคชันหรือไม่

ฉันจะสร้างระบบที่มีสิ่งต่อไปนี้ทั้งหมดได้อย่างไร :

1. การใช้ฟังก์ชั่นบริสุทธิ์กับวัตถุที่ไม่เปลี่ยนรูป
2. ส่งผ่านไปยังข้อมูลฟังก์ชันที่ฟังก์ชันต้องการเท่านั้นไม่เกิน (เช่นไม่มีวัตถุสถานะแอปพลิเคชันขนาดใหญ่)
3. หลีกเลี่ยงการขัดแย้งกับฟังก์ชันมากเกินไป
4. หลีกเลี่ยงการสร้างวัตถุใหม่เพียงเพื่อจุดประสงค์ในการบรรจุและเอาพารามิเตอร์ออกจากฟังก์ชั่นเพื่อหลีกเลี่ยงการส่งพารามิเตอร์ไปยังฟังก์ชันมากเกินไป ถ้าฉันจะแพ็คหลายรายการไปยังฟังก์ชันเป็นวัตถุเดียวฉันต้องการให้วัตถุนั้นเป็นเจ้าของข้อมูลนั้นไม่ใช่สิ่งที่สร้างขึ้นชั่วคราว

สำหรับฉันแล้วดูเหมือนว่ารัฐ monad ทำผิดกฎข้อที่ 2 ถึงแม้ว่ามันจะไม่ชัดเจนเพราะมันถูกสานต่อผ่าน monad

ฉันรู้สึกว่าฉันจำเป็นต้องใช้เลนส์อย่างใด แต่มีน้อยมากที่เขียนเกี่ยวกับมันสำหรับภาษาที่ไม่สามารถใช้งานได้

พื้นหลัง

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

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

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

จากนั้นฉันก็ผ่านแอปพลิเคชันของฉันและ: 1. ขั้นแรกให้สถานะแอปพลิเคชันทั้งหมดของฉันเป็นวัตถุระดับโลกเดียว (GameState) 2. ประการที่สองฉันทำให้ GameState ไม่เปลี่ยนรูป คุณไม่สามารถเปลี่ยนได้ หากคุณต้องการการเปลี่ยนแปลงคุณต้องสร้างสิ่งใหม่ ฉันทำสิ่งนี้โดยการเพิ่มตัวคัดลอกตัวเลือกที่จะเลือกหนึ่งหรือมากกว่าหนึ่งช่องที่มีการเปลี่ยนแปลง 3. สำหรับแต่ละแอปพลิเคชันฉันส่งผ่าน GameState เป็นพารามิเตอร์ ภายในฟังก์ชั่นหลังจากที่ทำสิ่งที่มันจะทำมันจะสร้าง GameState ใหม่และส่งคืน

ฉันมีคอร์ที่ใช้งานได้จริงได้อย่างไรและมีลูปด้านนอกที่ดึง GameState นั้นเข้าสู่เวิร์กโฟลว์หลักของแอปพลิเคชัน

คำถามของฉัน:

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

มีบางอย่างเกี่ยวกับที่ดูเหมือนผิด ฟังก์ชั่นไม่ต้องการ GameState ทั้งหมด มันแค่ต้องการวัตถุคะแนน ดังนั้นฉันจึงอัปเดตเพื่อให้ผ่านคะแนนและคืนคะแนนเท่านั้น

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

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

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

ดูเหมือนว่าจะผ่าน GameState ไปตามทางเพื่อหลีกเลี่ยงปัญหานี้ แต่ฉันกลับไปที่ปัญหาดั้งเดิมของการส่งผ่านข้อมูลเพิ่มเติมไปยังฟังก์ชันมากกว่าความต้องการของฟังก์ชัน

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

• แบ่งGameStateลำดับขั้นเพื่อให้คุณได้ชิ้นส่วนเล็กลง 3-5 ชิ้นแทน 15
• ปล่อยให้มันใช้อินเทอร์เฟซดังนั้นวิธีการของคุณเห็นเฉพาะส่วนที่จำเป็น อย่าโยนพวกเขากลับไปเพราะคุณโกหกตัวเองเกี่ยวกับประเภทที่แท้จริง
• ให้ส่วนต่าง ๆ ใช้อินเทอร์เฟซเพื่อให้คุณควบคุมสิ่งที่คุณผ่านได้ดี
• ใช้วัตถุพารามิเตอร์ แต่ทำเท่าที่จำเป็นและพยายามที่จะทำให้พวกเขาเป็นวัตถุจริงที่มีพฤติกรรมของตนเอง
• บางครั้งการส่งเกินความจำเป็นเล็กน้อยอาจดีกว่ารายการพารามิเตอร์ที่มีความยาว

ดังนั้นตอนนี้ฉันสงสัยว่าปัญหาที่ฉันมีคือการทำงานของฉันซ้อนกันลึกเกินไป

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

เปรียบเทียบการออกแบบของคุณกับสิ่งที่ไม่แน่นอน มีสิ่งใดที่แย่ไปกว่าการเขียนใหม่? ถ้าเป็นเช่นนั้นคุณไม่สามารถทำให้ดีขึ้นในแบบเดียวกับที่คุณเคยทำหรือไม่?

ฉันไม่สามารถพูดกับ C # ได้ แต่ใน Haskell คุณจะต้องผ่านรัฐทั้งหมดรอบ ๆ คุณสามารถทำสิ่งนี้อย่างชัดเจนหรือกับรัฐ monad สิ่งหนึ่งที่คุณสามารถทำได้เพื่อแก้ไขปัญหาของฟังก์ชั่นที่ได้รับข้อมูลเพิ่มเติมจากนั้นพวกเขาต้องการคือใช้มีประเภทของพิมพ์ (ถ้าคุณไม่คุ้นเคย Haskell typeclasses จะคล้ายกับอินเตอร์เฟส C #) สำหรับแต่ละองค์ประกอบ E ของรัฐคุณสามารถกำหนด typeclass HasE ที่ต้องการฟังก์ชัน getE ที่ส่งคืนค่าของ E. Monad ของรัฐสามารถ ทำตัวอย่างของ typeclasses เหล่านี้ทั้งหมด จากนั้นในการทำงานจริงของคุณแทนที่จะต้องใช้ State Monad ของคุณอย่างชัดเจนคุณต้องใช้ Monad ใด ๆ ที่เป็นของ typeclasses สำหรับองค์ประกอบที่คุณต้องการ ที่ จำกัด สิ่งที่ฟังก์ชั่นสามารถทำได้กับโมนาที่ใช้อยู่ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการนี้ให้ดู Michael Snoyman'sโพสต์ในรูปแบบการออกแบบ ReaderT

คุณอาจทำซ้ำสิ่งนี้ใน C # ขึ้นอยู่กับว่าคุณกำหนดสถานะที่ถูกส่งผ่านไปได้อย่างไร หากคุณมีสิ่งที่ชอบ

public class MyState
{
    public int MyInt {get; set; }
    public string MyString {get; set; }
}

คุณสามารถกำหนดอินเตอร์เฟสIHasMyIntและIHasMyStringด้วยวิธีการGetMyIntและGetMyStringตามลำดับ ระดับรัฐนั้นดูเหมือนว่า:

public class MyState : IHasMyInt, IHasMyString
{
    public int MyInt {get; set; }
    public string MyString {get; set; }
    public double MyDouble {get; set; }

    public int GetMyInt () 
    {
        return MyInt;
    }

    public string GetMyString ()
    {
        return MyString;
    }

    public double GetMyDouble ()
    {
        return MyDouble;
    }
}

วิธีการของคุณอาจต้องใช้ IHasMyInt, IHasMyString หรือ MyState ทั้งหมดตามความเหมาะสม

จากนั้นคุณสามารถใช้ข้อ จำกัด where บนคำจำกัดความของฟังก์ชันเพื่อให้คุณสามารถส่งผ่านวัตถุสถานะ แต่สามารถไปที่ string และ int เท่านั้นไม่ใช่ double

public static T DoSomething<T>(T state) where T : IHasMyString, IHasMyInt
{
    var s = state.GetMyString();
    var i = state.GetMyInt();
    return state;
}

ฉันคิดว่าคุณน่าจะเรียนรู้เกี่ยวกับ Redux หรือ Elm ได้ดีและพวกเขาจัดการกับคำถามนี้อย่างไร

โดยพื้นฐานแล้วคุณมีฟังก์ชั่นบริสุทธิ์ที่ใช้ทั้งสถานะและการกระทำที่ผู้ใช้ดำเนินการและส่งกลับสถานะใหม่

ฟังก์ชั่นนั้นจะเรียกฟังก์ชันบริสุทธิ์อื่น ๆ ซึ่งแต่ละฟังก์ชันจัดการกับสถานะเฉพาะ ฟังก์ชั่นเหล่านี้อาจไม่ทำอะไรเลย แต่กลับสู่สถานะเดิมโดยไม่ขึ้นอยู่กับการกระทำ

หากต้องการเรียนรู้เพิ่มเติม Google Elm Architecture หรือ Redux.js.org

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

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

C # ยังไม่พร้อมที่จะใช้งานได้ตามที่คุณต้องการ