ในแอปพลิเคชันขนาดใหญ่ส่วนใหญ่ของเราเรามักจะมีเพียงไม่กี่ตำแหน่งสำหรับ "ค่าคงที่":
- หนึ่งคลาสสำหรับ GUI และค่าคงที่ภายใน (ชื่อแท็บหน้า, ชื่อกลุ่มกล่อง, ปัจจัยการคำนวณ, การแจกแจง)
- หนึ่งคลาสสำหรับตารางและคอลัมน์ฐานข้อมูล (ส่วนนี้เป็นรหัสที่สร้างขึ้น) พร้อมชื่อที่อ่านได้สำหรับพวกเขา (กำหนดด้วยตนเอง)
- คลาสหนึ่งสำหรับข้อความแอปพลิเคชัน (การบันทึกกล่องข้อความ ฯลฯ )
ค่าคงที่มักจะถูกแยกออกเป็นส่วนต่าง ๆ ในคลาสเหล่านั้น ในแอปพลิเคชัน C ++ ของเราค่าคงที่จะถูกกำหนดเฉพาะในไฟล์. h และค่าจะถูกกำหนดในไฟล์. cpp
ข้อดีอย่างหนึ่งก็คือสตริงทั้งหมด ฯลฯ อยู่ในจุดศูนย์กลางเดียวและทุกคนรู้ว่าจะต้องค้นหาสิ่งใดเมื่อต้องมีการเปลี่ยนแปลง
นี่เป็นสิ่งที่ผู้จัดการโครงการดูเหมือนจะเป็นอย่างที่ผู้คนเข้ามาและด้วยวิธีนี้ทุกคนสามารถเปลี่ยนแปลงสิ่งเล็ก ๆ น้อย ๆ ได้โดยไม่ต้องขุดเข้าไปในโครงสร้างของแอปพลิเคชัน
นอกจากนี้คุณสามารถเปลี่ยนชื่อของกลุ่มกล่อง / หน้าแท็บที่คล้ายกันได้อย่างง่ายดายในครั้งเดียว อีกแง่มุมหนึ่งคือคุณสามารถพิมพ์คลาสนั้นและมอบให้กับผู้ที่ไม่ใช่โปรแกรมเมอร์ซึ่งสามารถตรวจสอบคำอธิบายภาพว่าใช้งานง่ายหรือไม่และข้อความที่ส่งถึงผู้ใช้นั้นละเอียดเกินไปหรือสับสนเกินไป
อย่างไรก็ตามฉันเห็นข้อเสียบางอย่าง:
- ทุกชั้นเรียนจะถูกผนวกเข้ากับชั้นเรียนอย่างต่อเนื่อง
- การเพิ่ม / ลบ / เปลี่ยนชื่อ / ย้ายค่าคงที่ต้องมีการคอมไพล์ใหม่อย่างน้อย 90% ของแอปพลิเคชัน (หมายเหตุ: การเปลี่ยนค่าไม่ได้เป็นอย่างน้อยสำหรับ C ++) ในหนึ่งในโปรเจ็กต์ C ++ ของเราที่มีคลาส 1,500 คลาสซึ่งหมายถึงเวลาในการรวบรวมประมาณ 7 นาที (โดยใช้ส่วนหัวที่คอมไพล์แล้วโดยไม่มีเวลาประมาณ 50 นาที) และใช้เวลาเชื่อมโยงกับไลบรารีคงที่บางประมาณ 10 นาที
- การสร้างการเพิ่มประสิทธิภาพความเร็วด้วย Visual Studio Compiler ใช้เวลาสูงสุด 3 ชั่วโมง ฉันไม่รู้ว่าความสัมพันธ์ในชั้นเรียนขนาดใหญ่เป็นแหล่งที่มาหรือไม่
- คุณได้รับแรงผลักดันเข้าสู่สตริงการเข้ารหัสที่เข้ารหัสชั่วคราวยาก ๆ เพราะคุณต้องการทดสอบบางสิ่งอย่างรวดเร็วและไม่ต้องการที่จะรอ 15 นาทีสำหรับการทดสอบนั้น ทุกคนรู้ว่าเกิดอะไรขึ้นกับ "ฉันจะแก้ไขในภายหลัง" - ความคิด
- การนำคลาสไปใช้ในโครงการอื่นนั้นไม่ใช่เรื่องง่ายเสมอไป (ส่วนใหญ่เป็นเพราะข้อต่อแน่นอื่น ๆ แต่ค่าคงที่การจัดการไม่ได้ทำให้ง่ายขึ้น)
คุณจะเก็บค่าคงที่แบบนั้นอยู่ที่ไหน นอกจากนี้คุณจะโต้แย้งอะไรเพื่อโน้มน้าวผู้จัดการโครงการของคุณว่ามีแนวคิดที่ดีกว่าซึ่งสอดคล้องกับข้อได้เปรียบที่ระบุไว้ข้างต้น
อย่าลังเลที่จะให้คำตอบ C ++ ที่เจาะจงหรือเป็นอิสระ
PS: ฉันรู้ว่าคำถามนี้เป็นเรื่องส่วนตัว แต่ฉันไม่รู้สถานที่ที่ดีไปกว่าเว็บไซต์นี้สำหรับคำถามประเภทนี้
อัพเดทโครงการนี้
ฉันมีข่าวเรื่องเวลารวบรวม:
จากการโพสต์ของ Caleb และ gbjbaanb ฉันแบ่งไฟล์ค่าคงที่ของฉันออกเป็นไฟล์อื่น ๆ หลายไฟล์เมื่อฉันมีเวลา ในที่สุดฉันก็แยกโครงการของฉันออกเป็นหลายห้องสมุดซึ่งตอนนี้เป็นไปได้ง่ายขึ้นมาก การคอมไพล์ในโหมดการวางจำหน่ายแสดงให้เห็นว่าไฟล์ที่สร้างขึ้นอัตโนมัติซึ่งมีคำจำกัดความของฐานข้อมูล (ตารางชื่อคอลัมน์และอื่น ๆ - มากกว่า 8000 สัญลักษณ์) และการสร้างแฮชบางอย่างทำให้เกิดการคอมไพล์ครั้งใหญ่ในโหมดการเปิดตัว
การปิดใช้งานเครื่องมือเพิ่มประสิทธิภาพ MSVC สำหรับไลบรารีที่มีค่าคงที่ฐานข้อมูลทำให้เราสามารถลดเวลาการรวบรวมทั้งหมดของโครงการของคุณ (หลายแอปพลิเคชั่น) ในโหมดการปล่อยจาก 8 ชั่วโมงเป็นน้อยกว่าหนึ่งชั่วโมง!
เรายังไม่ทราบว่าทำไม MSVC จึงมีความยากลำบากในการปรับไฟล์เหล่านี้ แต่ตอนนี้การเปลี่ยนแปลงนี้ช่วยลดแรงกดดันได้มากเนื่องจากเราไม่ต้องพึ่งพาการสร้างในตอนกลางคืนเท่านั้น
ความจริงนั้น - และประโยชน์อื่น ๆ เช่นข้อต่อที่แน่นน้อยกว่าการใช้ซ้ำได้ดีขึ้นเป็นต้น - ยังแสดงให้เห็นว่าการใช้เวลาแยก "ค่าคงที่" นั้นไม่ใช่ความคิดที่เลวร้ายหลังจากทั้งหมด ;-)
Update2
เนื่องจากคำถามนี้ยังคงได้รับความสนใจ:
นี่คือสิ่งที่ฉันได้ทำในไม่กี่ปีที่ผ่านมา:
ใส่ค่าคงที่ตัวแปรและอื่น ๆ ทั้งหมดลงในขอบเขตที่เกี่ยวข้อง: ถ้าคุณใช้ค่าคงที่เฉพาะในวิธีการเดียวมันก็โอเคที่จะกำหนดมันในวิธีการนั้น ถ้าคลาสเดียวสนใจให้ปล่อยให้มันเป็นรายละเอียดการใช้งานส่วนตัวของคลาสนั้น เช่นเดียวกับเนมสเปซโมดูลโครงการขอบเขตของ บริษัท ฉันยังใช้รูปแบบเดียวกันสำหรับฟังก์ชั่นตัวช่วยและชอบ (สิ่งนี้อาจใช้ไม่ได้ 100% ถ้าคุณพัฒนากรอบงานสาธารณะ)
การทำเช่นนี้สามารถนำมาใช้ใหม่ได้เพิ่มขึ้นทดสอบได้และบำรุงรักษาในระดับที่คุณไม่เพียง แต่ใช้เวลาน้อยลงในการรวบรวม (อย่างน้อยใน C ++) แต่ยังมีเวลาน้อยลงในการแก้ไขข้อผิดพลาดซึ่งทำให้คุณมีเวลามากขึ้น ในขณะเดียวกันการพัฒนาคุณสมบัติเหล่านี้จะทำงานได้เร็วขึ้นเนื่องจากคุณสามารถใช้รหัสได้ง่ายขึ้น สิ่งนี้มีความได้เปรียบมากกว่าไฟล์ค่าคงที่ส่วนกลางใด ๆ ที่อาจมีขนาด
ดูโดยเฉพาะอย่างยิ่งหลักการแยกส่วนต่อประสานและหลักการความรับผิดชอบเดี่ยวหากคุณต้องการทราบข้อมูลเพิ่มเติม
ถ้าคุณเห็นด้วยตอบคำถามของ Caleb ตั้งแต่อัปเดตนี้เป็นเรื่องทั่วไปที่เขาพูด