หนึ่งคลาสต่อกฎไฟล์ใน. NET [ปิด]

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

อีกข้อที่ฉันได้ยินตลอดเวลาคือ "แม้แต่ Microsoft ก็ไม่ทำเช่นนั้น

ฉันทามติทั่วไปเกี่ยวกับเรื่องนี้คืออะไร? มีกรณีที่ควรหลีกเลี่ยงสิ่งนี้หรือไม่?

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

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

1. ทำให้โค้ดย่อยและบำรุงรักษาง่ายขึ้น
2. ทำให้โซลูชันน่ารำคาญน้อยลง (เลื่อนดูไฟล์ที่ไม่จำเป็นนับไม่ถ้วน) และช้าลง
3. ทีมนักพัฒนานั้นโอเคกับการฝึกเขียนโค้ดในท้องถิ่น

ตัวอย่างที่ดีมาก ๆ ว่าทำไมฉันถึงต้องการหลาย ๆ คลาสต่อไฟล์:

สมมติว่าฉันมีคลาสข้อยกเว้นแบบกำหนดเองไม่กี่โหลแต่ละอันมี 4 ไลเนอร์ฉันสามารถมีไฟล์แยกกันสำหรับแต่ละคนหรือฉันสามารถจัดกลุ่มข้อยกเว้นและมีไฟล์ต่อกลุ่ม สำหรับฉันสิ่งที่ดูเหมือนว่ามีเหตุผล / วิธีปฏิบัติมากที่สุดคือการจัดกลุ่มพวกเขาและมีเพียงไม่กี่ไฟล์เพราะมันมีประสิทธิภาพมากขึ้นเวลา / การเข้ารหัสที่ชาญฉลาด (ฉันไม่ต้องคลิกขวา -> เพิ่มคลาสเปลี่ยนชื่อ 50 ครั้ง) มันช่วยให้การแก้ปัญหาน้อยลงและทำงานได้ดีขึ้น

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

บางครั้งฉันจัดกลุ่มมากกว่าหนึ่งคลาสภายในไฟล์หากมีการเชื่อมโยงกันอย่างแน่นหนาและอย่างน้อยหนึ่งคลาสมีขนาดเล็กมาก

'แนวปฏิบัติที่ดีที่สุด' ทั่วไปคือต้องมีหนึ่งไฟล์ต่อชั้นเรียน

นอกเหนือจากการถกเถียงและมุ่งเน้นไปที่ Windows .NET ด้วย Visual Studio IDE และการเติบโตของโครงการซอฟต์แวร์มันมีเหตุผลในบริบทนี้ที่จะมีหนึ่งคลาสต่อไฟล์

โดยทั่วไปแล้วสำหรับการอ้างอิงแบบมองเห็นไม่มีอะไรเต้นหนึ่งคลาสต่อไฟล์ จริงๆ.

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

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

class BicycleWheel {
    class WheelSpoke {
    }
}

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

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

เหตุผลที่ดีมากมาย ...

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

ฉันก็เชื่อว่าควรมีหนึ่งประเภทรวมอยู่ในไฟล์เดียว

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

RelayCommand     

และ

RelayCommand<T>

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

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

ไม่ว่าเนื้อหาจะมีน้ำหนักเบาแค่ไหนฉันคิดว่าหนึ่งคลาส / อินเตอร์เฟส / ฯลฯ ต่อไฟล์เป็นสิ่งจำเป็น

ถ้าฉันกำลังทำงานกับโซลูชันขนาดใหญ่ใน Visual Studio ฉันต้องการให้สามารถดูไฟล์และไม่ต้องเจาะเข้าไปด้านในเพื่อดู แม้จะมีเครื่องมือนำทางเช่น ReSharper ฉันต้องการแมป 1: 1

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

ฉันพบว่าการจัดกลุ่มคลาสด้วยเป็นคลาสมาตรฐานจากโรงงานในไฟล์เดียวกันมีประโยชน์มาก

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

ดังนั้นประเด็นก็คือควรใช้ดุลยพินิจ !!!

ในการแก้ปัญหาที่ใหญ่กว่าฉันคิดว่ามันมีประโยชน์มากที่จะมีหนึ่งคลาสต่อไฟล์ ทำให้ง่ายต่อการค้นหารหัสที่คุณต้องการใช้งาน

เครื่องมือ StyleCop สำหรับ C # มีกฎมาตรฐานที่ไม่จำเป็นต้องมีคลาสระดับบนสุดมากกว่าหนึ่งคลาสในเนมสเปซเดียว

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

บางครั้งหนึ่งคลาสต่อไฟล์แต่ ...

เมื่อหลายชั้นเรียนที่เกี่ยวข้อง stricly มากกว่าหนึ่งชั้นในแฟ้มแหล่งที่มาเดียวกันคือ IMHO, ดีกว่าทุ่มเทแฟ้มแหล่งที่มาสั้น ๆ ในแต่ละระดับ แหล่งข้อมูลสามารถอ่านได้และมีขนาดกะทัดรัด (และการใช้ #region แหล่งข้อมูลเดียวกันสามารถจัดโครงสร้างได้มากกว่าเดิม)

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

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

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

กล่าวคือ

• ในวันจันทร์ฉันทำการเปลี่ยนแปลงคลาสของฉัน x และ y ในไฟล์ y.css
• ในวันอังคารฉันแยกคลาส x ลงในไฟล์ของตัวเอง x.css เพราะมันใหญ่ขึ้นเรื่อย ๆ
• ในวันพุธเจ้านายของฉันต้องการเห็นสิ่งที่ฉันเปลี่ยนในชั้นเรียน x ในวันจันทร์ดังนั้นเขาจึงดูประวัติของ x.css เฉพาะ x.css เท่านั้นที่ไม่แสดงประวัติก่อนที่จะมีการเปลี่ยนแปลงในวันอังคาร

เป็นปัญหาหรือไม่? :)
ชั้นเรียนขนาดเล็กจริง ๆ เช่นเดียวกับ enums สามารถใช้ร่วมกับผู้อื่นได้ มีกฎหนึ่งข้อที่ต้องปฏิบัติดังนี้: รวบรวมเฉพาะคลาสที่มีบางสิ่งที่เหมือนกัน

เป็นการพูดนอกเรื่อง - ในหนึ่งในโครงการของฉันฉันมีไฟล์ที่มี 150 ชั้นภายใน ไฟล์นี้มีรหัส 10,000 บรรทัด แต่มันสร้างขึ้นอัตโนมัติดังนั้นมันจึงเป็นที่ยอมรับได้อย่างสมบูรณ์ :)

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

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

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

• EventArgs.cs ที่มีEventArgsคลาสย่อยใด ๆเนื่องจากโดยปกติแล้วจะมีรหัส 5-10 บรรทัดเท่านั้น แต่โดยทั่วไปจะมีการใช้งานโดยคลาสที่แตกต่างกันหลายคลาส หรือฉันอาจใส่EventArgsคลาสในไฟล์เดียวกับคลาสที่ประกาศเหตุการณ์
• Delegates.cs ที่มีผู้รับมอบสิทธิ์ที่ใช้ตลอดทั้งโครงการเนื่องจากโดยปกติแล้วจะมีเพียง 1 บรรทัดเท่านั้น อีกทางเลือกคือการวางไว้ในไฟล์เดียวกันกับคลาสที่ตีแผ่ / สิ้นเปลือง
• Enums.cs ที่มีenums ที่ใช้ทั่วทั้งโครงการ (หากมีการenumใช้คลาสเพียงคลาสเดียวฉันมักจะใช้privateในคลาสนั้น)

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

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

การตอบสนองดูเหมือนจะหมุนรอบข้อยกเว้นของผู้คนต่อกฎดังนั้นนี่คือของฉัน: ฉันเก็บคลาสและคลาส 'เพื่อน' เมตาดาต้าของพวกเขาร่วมกันเมื่อใช้แพ็คเกจ DataAnnotations ใน. NET3.5 SP1 ไม่เช่นนั้นจะอยู่ในไฟล์แยกกันเสมอ คุณรู้ว่าส่วนใหญ่เวลา ยกเว้นเมื่อไม่ได้

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

หรือคลาสที่แยกต่างหากเพื่อให้มีวิธีการขยายสำหรับคลาสหลักนั้น

One case could be:เมื่อชั้นเรียนของคุณร่วมกันในรูปแบบmodule / unitที่ให้บริการชั้นหลักบางอย่างเช่นhelper classesฉลาดอื่น ๆไม่มี

ดูที่ซอร์สโค้ดโครงการASP.NET MVC 2.0 มันปฏิบัติตามกฎนี้อย่างเคร่งครัด

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

ฉันจะไม่ทำตามแนวทางปฏิบัติของ MS เนื่องจากไม่ใช่แนวปฏิบัติที่ดีที่สุด!

อีกจุดหนึ่งที่ฉันไม่เคยเห็นใครพูดถึงคือเมื่อคุณพัฒนาโดยใช้หนึ่งคลาสต่อกฎไฟล์คุณสามารถเห็นได้ว่าคลาสใดที่เฉพาะเจาะจงใช้อยู่

ตัวอย่างเช่น: คุณอาจมีสองคลาสโดยที่หนึ่งคลาสใช้ Linq และอีกคลาสหนึ่งไม่มี

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

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

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

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

มีข้อยกเว้นสำหรับกฎนี้ (อินเตอร์เฟส + การนำไปใช้งาน, enums, ... ) แต่มันเป็นจุดเริ่มต้นที่ดีกว่าตรงกันข้ามซึ่งโดยทั่วไปแล้วจะช่วยให้นักพัฒนารุ่นเยาว์สามารถรวมคลาสที่ไม่เกี่ยวข้องทั้งหมดไว้ในไฟล์เดียวกันได้

One-class-per-file เป็นกฎที่ชัดเจนไม่ต้องตีความ

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

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

ฉันอยากรู้ว่าคำตอบใดของคุณแตกต่างกันไปขึ้นอยู่กับว่าคุณเป็น: (1) พัฒนาแอพ Windows Forms, เว็บแอป, ห้องสมุดหรืออะไรก็ตาม; หรือ (2) ใช้ Visual Studio หรือไม่ ในการใช้ VS จะปรากฏว่าหนึ่งคลาสต่อกฎไฟล์จะมีความหมายหนึ่งคลาสต่อโครงการ VS เนื่องจากข้อสรุปในเธรดอื่นดูเหมือนว่าโซลูชัน VS / โครงการควรถูกมิร์เรอร์ในการตั้งชื่อไดเร็กทอรี / โครงสร้างไฟล์ อันที่จริงแล้วการแสดงผลของฉันคือการแสดงความเห็นร่วมที่จะมีชื่อโปรเจ็กต์ = แอสเซมบลีชื่อ = (ซ้อน) ชื่อเนมสเปซซึ่งทั้งหมดนี้จะถูกมิร์เรอร์ในการตั้งชื่อไดเรกทอรี / ไฟล์และโครงสร้าง หากสิ่งเหล่านั้นเป็นแนวทางที่ถูกต้อง (หรือกฎ) กลไกการจัดระเบียบแบบออโธกอนอลดูเหมือนจะยังคงถูกซิงค์อยู่

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

รายการรหัสหนึ่งรายการต่อไฟล์ใช่

ทุกสิ่งทุกอย่างคือการทุจริตต่อหน้าที่และเป็นสัญญาณบ่งบอกถึงความเป็นเหยื่อของ RAD

ทันทีที่เริ่มการพัฒนาซอฟต์แวร์ที่เหมาะสม (IoC, รูปแบบการออกแบบ, DDD, TDD, ฯลฯ ... ) และออกจาก "omg ให้ทำสิ่งนี้ได้ฉันไม่รู้เลยว่า แต่ฉันได้รับเงิน" สนามเด็กเล่นใครจะเห็นว่า กฎนี้มีความสำคัญจริงๆ