นี่เป็นรูปแบบที่ดีหรือไม่: แทนที่ฟังก์ชั่นที่ยาวนานด้วยแลมบ์ดาเป็นชุด?

ฉันเพิ่งทำงานในสถานการณ์ต่อไปนี้

class A{
public:
    void calculate(T inputs);
}

ประการแรกAแสดงถึงวัตถุในโลกทางกายภาพซึ่งเป็นข้อโต้แย้งที่แข็งแกร่งที่ไม่แยกชั้นเรียนขึ้น ตอนนี้calculate()กลายเป็นฟังก์ชั่นที่ค่อนข้างยาวและซับซ้อน ฉันเข้าใจโครงสร้างที่เป็นไปได้สามประการ:

• เขียนเป็นกำแพงข้อความ - ข้อดี - ข้อมูลทั้งหมดอยู่ในที่เดียว
• เขียนprivateฟังก์ชั่นยูทิลิตี้ในชั้นเรียนและใช้พวกเขาในcalculateร่างกาย - ข้อเสีย - ส่วนที่เหลือของชั้นไม่ทราบ / ดูแล / เข้าใจเกี่ยวกับวิธีการเหล่านั้น

• เขียนcalculateวิธีดังต่อไปนี้:

  void A::calculate(T inputs){    
      auto lambda1 = () [] {};    
      auto lambda2 = () [] {};    
      auto lambda3 = () [] {};
  
      lambda1(inputs.first_logical_chunk);
      lambda2(inputs.second_logical_chunk);
      lambda3(inputs.third_logical_chunk);
  }
  

สิ่งนี้ถือได้ว่าเป็นการปฏิบัติที่ดีหรือไม่ดี? วิธีนี้เปิดเผยปัญหาหรือไม่? โดยรวมแล้วฉันควรพิจารณาว่านี่เป็นแนวทางที่ดีเมื่อฉันต้องเผชิญกับสถานการณ์เดียวกันอีกครั้งหรือไม่?

แก้ไข:

class A{
    ...
public:
    // Reconfiguration of the algorithm.
    void set_colour(double colour);
    void set_density(double density);
    void set_predelay(unsigned long microseconds);
    void set_reverb_time(double reverb_time, double room_size);
    void set_drywet(double left, double right);
    void set_room_size(double value);;

private:
    // Sub-model objects.
    ...
}

วิธีการเหล่านั้นทั้งหมด:

• รับค่า
• คำนวณค่าอื่น ๆ โดยไม่ต้องใช้สถานะ
• เรียก "วัตถุโมเดลย่อย" บางอย่างเพื่อเปลี่ยนสถานะ

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

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

ไม่นี่ไม่ใช่รูปแบบที่ดีโดยทั่วไป

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

ทำงาน lambdas ตามที่คุณได้เห็น แต่พวกเขาหมายถึงมากมากมากมากกว่าเพียงแค่การทำลายขึ้นฟังก์ชั่นเป็นบิตท้องถิ่น แลมบ์ดาทำ:

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

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

มันเหมือนใช้แบ็ค - โฮเพื่อทำสวนของคุณ คุณรู้ว่าคุณใช้มันเพื่อขุดรูเล็ก ๆ สำหรับดอกไม้ในปีนี้ แต่เพื่อนบ้านจะตื่นเต้น

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

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

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

void A::set_room_size(double value)
{
    {
        // Part 1: {description of part 1}
        ...
    }
    // ------------------------
    {
        // Part 2: {description of part 2}
        ...
    }
    // ------------------------
    {
        // Part 3: {description of part 3}
        ...
    }
}

ฉันคิดว่าคุณทำสมมติฐานที่ไม่ดี:

ประการแรก A หมายถึงวัตถุในโลกทางกายภาพซึ่งเป็นข้อโต้แย้งที่แข็งแกร่งสำหรับการไม่แยกชั้นขึ้น

ฉันไม่เห็นด้วยกับสิ่งนี้ ตัวอย่างเช่นถ้าฉันมีชั้นเรียนที่แสดงถึงรถยนต์ฉันต้องการแยกมันออกแน่นอนเพราะฉันต้องการชั้นเรียนขนาดเล็กเพื่อเป็นตัวแทนของยางรถยนต์

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

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

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

เพื่อสรุปผมไม่คิดว่านี่เป็นรูปแบบที่ดี

UPDATE

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