ความซับซ้อนของตัวสร้างควรจะเป็น

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

คนอื่นคิดอย่างไร ฉันใช้ C # หากสร้างความแตกต่าง

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

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

คำถามของคุณประกอบด้วยสองส่วนแยกจากกันทั้งหมด:

ฉันควรโยนข้อยกเว้นจากตัวสร้างหรือฉันควรมีวิธีการล้มเหลว?

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

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

ฉันสามารถเข้าถึง "ส่วนอื่น ๆ ของระบบเช่น DB" จากตัวสร้าง

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

ฮึ.

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

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

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

คอนสตรัคเตอร์ - ความซับซ้อนของความซับซ้อนของวิธีการเป็นเรื่องของการอภิปรายเกี่ยวกับ stile ที่ดี บ่อยครั้งที่Class() {}มีการใช้Constructor ที่ว่างเปล่าด้วยวิธีการที่Init(..) {..}ซับซ้อนกว่า ท่ามกลางข้อโต้แย้งที่จะนำมาพิจารณา:

• ความเป็นไปได้ของการจัดลำดับชั้น
• ด้วยวิธีการแยก Init จากตัวสร้างคุณมักจะต้องทำซ้ำลำดับเดียวกันClass x = new Class(); x.Init(..);หลายครั้งบางส่วนในการทดสอบหน่วย อย่างไรก็ตามไม่ค่อยดีนักสำหรับการอ่าน บางครั้งฉันเพิ่งวางมันลงในหนึ่งบรรทัดของโค้ด
• เมื่อเป้าหมายการทดสอบหน่วยเป็นเพียงการทดสอบการกำหนดค่าเริ่มต้นของคลาสให้ดีกว่าที่จะมี Init ของตัวเองเพื่อทำสิ่งที่ซับซ้อนมากขึ้นให้เป็นหนึ่งเดียวโดยใช้ Asserts ระดับกลาง