การใช้เงื่อนไขนี้เป็นการป้องกันแบบแผนหรือไม่?

ฉันเห็นสิ่งนี้มากมายในระบบเดิมของเราในที่ทำงาน - ฟังก์ชั่นที่เป็นไปตามนี้:

bool todo = false;
if(cond1)
{
  ... // lots of code here
  if(cond2)
    todo = true;
  ... // some other code here
}

if(todo)
{
  ...
}

ฟังก์ชั่นนี้มีสองส่วน ส่วนแรกทำการประมวลผลบางอย่าง (อาจมีลูปผลข้างเคียงและอื่น ๆ ) และตามวิธีที่อาจตั้งค่าสถานะ "todo" ส่วนที่สองจะดำเนินการก็ต่อเมื่อมีการตั้งค่าสถานะ "todo"

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

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

ฉันไม่รู้เกี่ยวกับรูปแบบการต่อต้าน แต่ฉันจะแยกสามวิธีจากนี้

คนแรกจะทำงานบางอย่างและส่งกลับค่าบูลีน

ครั้งที่สองจะทำงานอะไรก็ตามที่ทำได้โดย "รหัสอื่น"

ที่สามจะทำงานเสริมถ้าบูลีนที่ส่งคืนเป็นจริง

วิธีการที่แยกอาจเป็นแบบส่วนตัวหากเป็นสิ่งสำคัญที่จะเรียกวิธีที่สองเท่านั้น (และเสมอ) หากวิธีแรกคืนค่าเป็นจริง

โดยการตั้งชื่อวิธีการที่ดีฉันหวังว่ามันจะทำให้รหัสชัดเจนขึ้น

บางสิ่งเช่นนี้

public void originalMethod() {
    bool furtherProcessingRequired = lotsOfCode();
    someOtherCode();
    if (furtherProcessingRequired) {
        doFurtherProcessing();
    }
    return;
}

private boolean lotsOfCode() {
    if (cond1) {
        ... // lots of code here
        if(cond2) {
            return true;
        }
    }
    return false;
}

private void someOtherCode() {
    ... // some other code here
}

private void doFurtherProcessing() {
    // Do whatever is needed
}

เห็นได้ชัดว่ามีการถกเถียงกันว่าจะให้ผลตอบแทนเร็วกว่าปกติหรือไม่ แต่เป็นรายละเอียดการนำไปปฏิบัติ (เช่นเดียวกับมาตรฐานการจัดรูปแบบโค้ด)

ประเด็นคือความตั้งใจของรหัสจะชัดเจนขึ้นซึ่งเป็นสิ่งที่ดี ...

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

ฉันคิดว่าความอัปลักษณ์นั้นเกิดจากความจริงที่ว่ามีรหัสจำนวนมากในวิธีการเดียวและ / หรือตัวแปรนั้นมีชื่อไม่ดี (ทั้งคู่มีกลิ่นรหัสที่ด้านขวาของตัวเอง - antipatterns เป็นนามธรรมและซับซ้อนกว่า IMO)

ดังนั้นหากคุณแยกรหัสส่วนใหญ่ออกเป็นวิธีที่ระดับต่ำกว่าตามที่ @Bill แนะนำส่วนที่เหลือจะสะอาด (สำหรับฉันอย่างน้อย) เช่น

bool registrationNeeded = installSoftware(...);
if (registrationNeeded) {
  registerUser(...)
}

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

calculateTaxRefund(isTaxRefundable(...), ...)

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

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

สมมติว่าส่วนที่สองของฟังก์ชั่นเรียงลำดับรายการสร้างโดยส่วนแรก ควรอ่านได้มากขึ้น:

bool requiresSorting = false;
if(cond1)
{
    ... // lots of code here
    if(cond2)
        requiresSorting = true;
    ... // some other code here
}

if(requiresSorting)
{
    ...
}

อย่างไรก็ตามข้อเสนอแนะของบิลก็ถูกต้องเช่นกัน นี่ยังอ่านได้ง่ายกว่า:

bool requiresSorting = BuildList(list);
if (requiresSorting)
    SortList(list);

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

มันขึ้นอยู่กับมันจริงๆ หากรหัสที่ป้องกันไว้todo(ฉันหวังว่าคุณจะไม่ใช้ชื่อนั้นเพราะจริง ๆ แล้วมันไม่ได้เป็นตัวช่วยจำรหัส!) เป็นแนวคิดในการล้างรหัสคุณก็จะมีรูปแบบการต่อต้านและควรใช้อย่างเช่น RAII หรือ C # usingสร้างเพื่อจัดการกับสิ่งต่าง ๆ แทน

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

คำตอบมากมายที่นี่จะมีปัญหาในการผ่านการตรวจสอบความซับซ้อน

ฉันคิดว่านี่เป็นส่วน "รูปแบบการต่อต้าน" ของสิ่งที่คุณกำลังดู ค้นหาเครื่องมือที่ใช้วัดความซับซ้อนของรหัสของคุณ - มีปลั๊กอินสำหรับ eclipse มันเป็นการวัดว่าโค้ดของคุณยากแค่ไหนในการทดสอบและเกี่ยวข้องกับจำนวนและระดับของโค้ดสาขา

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

ใช้ตัวอย่างของ pdr ด้านบนเนื่องจากเป็นตัวอย่างที่ดีฉันจะก้าวไปอีกขั้นหนึ่ง

เขามี:

bool requiresSorting = BuildList(list);
if (requiresSorting)
    SortList(list);

ดังนั้นฉันจึงรู้ว่าสิ่งต่อไปนี้จะได้ผล:

if(BuildList(list)) 
    SortList(list)

แต่ไม่ชัดเจน

ดังนั้นสำหรับคำถามเดิมทำไมไม่มี:

BuildList(list)
SortList(list)

และให้ SortList ตัดสินใจว่าต้องเรียงลำดับหรือไม่

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

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

เช่นเดียวกับโดเมนที่มีรูปแบบที่หลากหลายในกรณีนี้เพียงหนึ่งซับที่จะทำสิ่งที่ยิ่งใหญ่ภายในวัตถุ

หากการตั้งค่าสถานะเพียงครั้งเดียวให้ย้าย
...
รหัสขึ้นไปด้านหลัง
... / / รหัสอื่น ๆ ที่นี่
แล้วทำไปกับการตั้งค่าสถานะ

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

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

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

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

// Check individual fields for proper input

if(fieldsValidated) {
  // Perform cross-checks to see if input contains values which exist in the database

  if(valuesExist) {
    try {
      // Attempt insertion
      trx.commit();
    } catch (DatabaseException dbe) {
      trx.rollback();
      throw dbe;
    }
  } else {
    closeConnection(db);
    throwException();
  }
} else {
  closeConnection(db);
  throwException();
}

สิ่งนี้สามารถลดความซับซ้อนได้โดยแยกการตรวจสอบจากกระบวนการจริงของการดำเนินการดังนั้นคุณจะเห็นสิ่งต่อไปนี้มากขึ้น:

boolean proceed = true;
// Check individual fields for proper input

if(fieldsValidated) {
  // Perform cross-checks to see if input contains values which exist in the database

  if(!valuesExist) {
    proceed = false;
  }
} else {
  proceed = false;
}

// The moment of truth
if(proceed) {
  try {
    // Attempt insertion
    trx.commit();
  } catch (DatabaseException dbe) {
    trx.rollback();
    throw dbe;
  }
} else {
  if(db.isOpen()) {
    closeConnection(db);
  }
  throwException();
}

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

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

ตอนนี้ตัวอย่างเฉพาะของคุณสามารถเขียนใหม่เป็น:

if(cond1)
{
    ... // lots of code here
    ... // some other code here
    if (cond2)
    {
        ...
    }
}

อาจจะอ่านง่ายกว่า หรืออาจจะไม่ ขึ้นอยู่กับส่วนที่เหลือของรหัสที่คุณละเว้น เน้นที่การทำให้รหัสนั้นกระชับยิ่งขึ้น

แฟล็กท้องถิ่นที่ใช้สำหรับโฟลว์การควบคุมควรรับรู้เป็นรูปแบบของการgotoปลอมตัว หากมีการใช้การตั้งค่าสถานะภายในฟังก์ชั่นเท่านั้นก็สามารถกำจัดได้โดยการเขียนฟังก์ชั่นสองชุดโดยเขียนชื่อชุดหนึ่งเป็น "flag is true" และอีกชุดหนึ่งเป็น "flag is false" และเปลี่ยนทุกการดำเนินการที่ตั้งค่าสถานะ เมื่อมันชัดเจนหรือเคลียร์มันเมื่อมันถูกตั้งค่าด้วยการข้ามไปมาระหว่างฟังก์ชั่นทั้งสองเวอร์ชัน

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

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