เหตุใดผู้คนจึงต่อต้านแท็ก #region ในวิธีการอย่างมาก

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

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

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

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

คิด?

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

อาร์กิวเมนต์ "ฉันต้องการสิ่งนี้เฉพาะที่นี่" นั้นแย่การวางอย่างสุภาพ เทคนิคที่คุณอธิบายมักจะถูกเรียกว่าเทคนิคหัวข้อและมักขมวดคิ้ว

1. คุณไม่สามารถทดสอบภูมิภาคได้ แต่คุณสามารถทดสอบวิธีการแยกได้
2. ภูมิภาคคือความคิดเห็นไม่ใช่องค์ประกอบของวากยสัมพันธ์ ในกรณีที่เลวร้ายที่สุดการซ้อนกันของภูมิภาคและบล็อกของคุณขัดแย้งกัน คุณควรพยายามแสดงความหมายของโครงสร้างของคุณด้วยองค์ประกอบทางไวยากรณ์ของภาษาที่คุณใช้
3. หลังจากปรับโครงสร้างเป็นเมธอดแล้วไม่มีใครต้องการการพับเพื่ออ่านข้อความอีกต่อไป อาจมีการดูซอร์สโค้ดในเครื่องมือใด ๆ ที่ไม่มีการพับเช่นเทอร์มินัลไคลเอ็นต์อีเมลมุมมองเว็บสำหรับ VCS หรือ diff-viewer ของคุณ
4. หลังจากเปลี่ยนไปใช้วิธีการใหม่อย่างน้อยวิธีการที่ได้นั้นก็ดีพอ ๆ กับภูมิภาคและมันง่ายกว่าที่จะเคลื่อนย้ายชิ้นส่วนแต่ละชิ้นไปรอบ ๆ
5. หลักการความรับผิดชอบเดี่ยวชี้ให้เห็นว่าหน่วยงานใดควรมีหนึ่งงานและหนึ่งงานเท่านั้น งานของวิธีการ "หลัก" คือการเขียนวิธีการ "ผู้ช่วย" เพื่อให้ได้ผลลัพธ์ที่ต้องการ วิธีการ "ผู้ช่วย" แก้ปัญหาแยกง่าย ๆ ในการแยก คลาสที่มีเมธอดทั้งหมดเหล่านี้ควรทำตามภารกิจเดียวเท่านั้นและมีเมธอดที่เกี่ยวข้องกับงานนั้นเท่านั้น ดังนั้นวิธีการช่วยเหลืออย่างใดอย่างหนึ่งเป็นของเข้าไปในขอบเขตของคลาสหรือรหัสไม่ควรจะเป็นในชั้นเรียนในสถานที่แรก แต่อย่างน้อยในวิธีการที่ทั่วโลกบางส่วนหรือดีกว่ายังควรได้รับการฉีด

ที่เกี่ยวข้องเพิ่มเติม: ความคิดของ Jeff Atwoods เกี่ยวกับการพับโค้ด

ไม่ใช่ภูมิภาคในวิธีการที่เป็นปัญหา แต่ในกรณีที่มีความต้องการ (หรือแม้แต่การใช้งาน) เพื่อวางภูมิภาคในวิธีการ

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

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

ไม่นั่นไม่ดีพอ แยกออกเป็นภูมิภาคทั้งหมดที่คุณต้องการ แต่ฉันยังคงส่ายหัวแค่คิดเกี่ยวกับมัน

หากคุณแบ่งเป็นวิธีการที่คุณได้รับประโยชน์มากมาย:

• ความเข้าใจที่ชัดเจนยิ่งขึ้นเกี่ยวกับสิ่งที่เกิดขึ้นแม้ว่าจะผ่านชื่อของวิธีการ และคุณมีความผิดที่วิธีการที่ไม่สามารถได้รับการบันทึกอย่างเต็มที่ - เพิ่มบล็อกเอกสาร (ตี///) และป้อนคำอธิบายพารามิเตอร์ชนิดกลับและยังexception, example, remarksโหนดในรายละเอียดสถานการณ์เหล่านั้น นั่นคือสิ่งที่จะไปนั่นคือสิ่งที่มันมีไว้สำหรับ!
• ไม่มีผลข้างเคียงหรือปัญหาการกำหนดขอบเขต คุณอาจบอกว่าคุณประกาศตัวแปรทั้งหมดของคุณในขอบเขตย่อยด้วย{}แต่ฉันต้องตรวจสอบทุกวิธีเพื่อให้แน่ใจว่าคุณไม่ได้ 'โกง'? นี่dodgyObjectฉันใช้ที่นี่เพียงเพราะใช้ในภูมิภาคนี้หรือมาจากที่อื่นใช่หรือไม่ ถ้าฉันอยู่ในวิธีการของตัวเองฉันจะสามารถเห็นได้อย่างง่ายดายว่ามันถูกส่งผ่านมาให้ฉันหรือไม่ว่าฉันจะสร้างมันเอง (หรือมากกว่าคุณสร้างมันขึ้นมา)
• บันทึกเหตุการณ์ของฉันบอกฉันว่ามีข้อผิดพลาดเกิดขึ้นในระบบใช่ฉันอาจสามารถค้นหารหัสที่ละเมิดด้วยหมายเลขบรรทัดได้ แต่การรู้ชื่อเมธอด (โดยเฉพาะอย่างยิ่งถ้าฉันตั้งชื่อถูกต้อง) ทำให้ฉันมีข้อบ่งชี้ เกิดอะไรขึ้นและเกิดข้อผิดพลาดอะไรขึ้น "โอ้TurnThingsUpsideDownวิธีการล้มเหลว - มันอาจจะล้มเหลวในขณะที่เปลี่ยนสิ่งเลวร้าย" ดีกว่า "โอ้DoEverythingวิธีการล้มเหลว - อาจเป็น 50 สิ่งที่แตกต่างกันและฉันจะต้องขุดหาเวลาหนึ่งชั่วโมงเพื่อหามัน" .

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

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

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

"แต่ชั้นเรียนของฉันจะมีวิธีการสาธารณะเพียงวิธีเดียวเท่านั้น!"

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

ชั้นเรียนของคุณสามารถโทรหาทั้งสามวิธีในทางกลับกันและส่งคืนผลลัพธ์ สิ่งหนึ่ง.

เป็นโบนัสตอนนี้วิธีการของคุณสามารถทดสอบได้เพราะไม่ใช่วิธีส่วนตัวอีกต่อไป

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

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

อะไร? คุณไม่ได้ใช้การฉีดพึ่งพาหรือไม่ คุณอาจยังไม่เห็นความจำเป็นเพราะคุณไม่ได้ปฏิบัติตามหลักการความรับผิดชอบเดียว เมื่อคุณเริ่มต้นคุณจะพบว่าวิธีที่ง่ายที่สุดในการให้การอ้างอิงในแต่ละคลาสนั้นคือการใช้ DI container

แก้ไข :

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

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

หากคุณกังวลเกี่ยวกับคนที่เห็นโครงสร้างของวิธีการ (และคุณปฏิเสธที่จะปรับโครงสร้างใหม่) ให้เพิ่มความคิดเห็นแบนเนอร์เช่นนี้:

//
// ---------- COMPUTE SOMETHING OR OTHER ----------
//

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

ฉันคิดว่าตัวอย่างที่คุณให้ในการโต้แย้งของคุณนั้นน้อยกว่า YAGNI (คุณไม่ต้องการมัน) และอีกมากมายเกี่ยวกับการเขียนรหัสคุณภาพที่เหมาะสมซึ่งรักษาได้ง่าย

ในหลักสูตรการเขียนโปรแกรมแรกสุดที่เราได้เรียนรู้ว่าหากวิธีการหนึ่ง ๆ มีความยาว 700 LOC มันอาจใหญ่เกินไปและแน่นอนว่าจะเป็นความเจ็บปวดครั้งใหญ่ในการลองและดีบัก

ประการที่สองถ้าฉันเขียนวิธี A, B และ C ที่ใช้ภายในวิธี D เท่านั้นฉันสามารถทดสอบหน่วย AB และ C ได้อย่างอิสระโดยไม่ขึ้นกับ D ทำให้การทดสอบหน่วยที่แข็งแกร่งมากขึ้นในทั้ง 4 วิธี

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

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

กฎส่วนบุคคลของฉันคือถ้าวิธีหนึ่งยาวกว่าหนึ่งหน้าจอให้พูด 40 บรรทัดมันยาวเกินไป ถ้าคลาสยาวเกิน 500 บรรทัดมันใหญ่เกินไป ฉันทำผิดกฎเหล่านี้บางครั้งบางครั้งถึงหลายตัว แต่โดยทั่วไปฉันรู้สึกเสียใจภายในปี

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

การทำลายฟังก์ชันที่มีความยาวตามข้อกำหนดนี้มีประโยชน์อย่างน้อยสองประการ:

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

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

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

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

ที่นี่เราจะไปอีกครั้ง ... มีหัวข้ออื่น ๆ อีกมากมายที่นี่สำหรับโปรแกรมเมอร์ซึ่งสิ้นสุดในการสนทนาเดียวกัน

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

อย่างไรก็ตาม ...

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

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

แม้ว่าฉันจะยอมรับว่าโดยปกติจะเป็นการดีกว่าที่จะ refactor code มากกว่าที่จะใช้#regionแต่ก็ไม่สามารถทำได้

เพื่อสนับสนุนคำแถลงนั้นขอยกตัวอย่าง

class Foo : IComparable
{
  private String name;
  private int foo;
  private Bar bar;

  public int CompareTo(Foo other)
  {
#region Ascending on name
     if (this.name < other.name) return -1;
     if (this.name > other.name) return 1;
#endregion
#region Usual order on bar
     int compBar = bar.compareTo(other.bar);
     if (compBar != 0) return compBar;
#endregion
#region Descending on foo
     if (this.foo > other.foo) return -1;
     if (this.foo < other.foo) return 1;
#endregion
     return 0; // equal
  }

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

อย่างไรก็ตามข้อยกเว้นเหล่านั้นหายาก มักจะเป็นไปได้ที่จะ refactor เหมือนคำตอบอื่น ๆ ที่พูด

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

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