วิธีการ C # ที่สามารถคงที่ควรเป็นแบบคงที่หรือไม่?
วันนี้เราคุยกันเรื่องนี้และฉันก็อยู่ในรั้ว ลองนึกภาพคุณมีวิธีการยาว ๆ ที่คุณปรับโครงสร้างใหม่ไม่กี่บรรทัด วิธีการใหม่อาจใช้ตัวแปรท้องถิ่นสองสามตัวจากเมธอดหลักและส่งคืนค่า ซึ่งหมายความว่าอาจเป็นแบบคงที่
คำถามคือควรเป็นแบบคงที่หรือไม่? ไม่คงที่ตามการออกแบบหรือทางเลือกเพียงเพราะธรรมชาติของมันไม่ได้อ้างอิงค่าอินสแตนซ์ใด ๆ
คำตอบ:
มันขึ้นอยู่กับ. วิธีการคงที่มี 2 ประเภท:
ในฐานรหัสขนาดเล็กถึงขนาดกลางคุณสามารถใช้สองวิธีนี้แทนกันได้
หากคุณมีเมธอดที่อยู่ในประเภทแรก (สามารถเป็นแบบคงที่) และคุณจำเป็นต้องเปลี่ยนเพื่อเข้าถึงสถานะคลาสมันค่อนข้างตรงไปตรงมาเพื่อดูว่าเป็นไปได้หรือไม่ที่จะเปลี่ยนวิธีการแบบคงที่เป็นวิธีอินสแตนซ์
อย่างไรก็ตามในฐานรหัสขนาดใหญ่จำนวนไซต์การโทรที่แท้จริงอาจทำให้การค้นหาดูว่าเป็นไปได้หรือไม่ที่จะแปลงวิธีการแบบคงที่เป็นวิธีที่ไม่คงที่ซึ่งมีราคาแพงเกินไป หลายครั้งผู้คนจะเห็นจำนวนการโทรและพูดว่า "โอเค ... ฉันไม่ควรเปลี่ยนวิธีนี้ แต่ควรสร้างวิธีใหม่ที่ตอบสนองสิ่งที่ฉันต้องการ"
ที่สามารถส่งผลอย่างใดอย่างหนึ่ง:
ทั้งสองสิ่งนั้นเลวร้าย
ดังนั้นคำแนะนำของฉันคือถ้าคุณมีฐานรหัสมากกว่า 200K LOC ฉันจะทำให้เมธอดคงที่ก็ต่อเมื่อเป็นวิธีที่ต้องคงที่
การปรับโครงสร้างใหม่จากไม่คงที่เป็นแบบคงที่นั้นค่อนข้างง่าย (เพียงแค่เพิ่มคีย์เวิร์ด) ดังนั้นหากคุณต้องการสร้างแบบคงที่ให้เป็นแบบคงที่จริงในภายหลัง (เมื่อคุณต้องการฟังก์ชันภายนอกอินสแตนซ์) คุณก็สามารถทำได้ อย่างไรก็ตามการเปลี่ยนโครงสร้างแบบผกผันการเปลี่ยน can-be-static ให้เป็นวิธีอินสแตนซ์นั้นมีราคาแพงกว่ามาก
ด้วยฐานรหัสขนาดใหญ่จะเป็นการดีกว่าที่จะเกิดข้อผิดพลาดในด้านความสะดวกในการขยายแทนที่จะเป็นด้านความบริสุทธิ์เชิงอุดมคติ
ดังนั้นสำหรับโปรเจ็กต์ใหญ่ ๆ อย่าทำให้สิ่งต่างๆนิ่งเว้นแต่คุณจะต้องการให้เป็น สำหรับโครงการขนาดเล็กเพียงแค่ทำในสิ่งที่คุณชอบมากที่สุด
ฉันจะไม่ทำให้มันเป็นสมาชิกแบบคงที่สาธารณะของคลาสนั้นนั้น เหตุผลก็คือการทำให้เป็นแบบคงที่แบบสาธารณะคือการพูดอะไรบางอย่างเกี่ยวกับประเภทของคลาส: ไม่เพียง แต่ "ประเภทนี้รู้วิธีทำพฤติกรรมนี้" แต่ยัง "เป็นความรับผิดชอบของประเภทนี้ในการแสดงพฤติกรรมนี้" และอัตราต่อรองคือพฤติกรรมที่ไม่มีความสัมพันธ์ที่แท้จริงกับประเภทใหญ่อีกต่อไป
นั่นไม่ได้หมายความว่าฉันจะไม่ทำให้มันคงที่เลย ถามตัวเองอย่างนี้: วิธีการใหม่ที่สมเหตุสมผลอาจอยู่ที่อื่นได้หรือไม่ หากคุณสามารถตอบว่า "ใช่" ได้คุณอาจต้องการทำให้เป็นแบบคงที่ (และย้ายด้วย) แม้ว่าจะไม่เป็นความจริง แต่คุณก็ยังทำให้มันคงที่ได้ อย่าทำเครื่องหมายไว้publicเพียงแค่ไม่ได้ทำเครื่องหมาย
internalเป็นเรื่องของความสะดวกสบายอย่างน้อยคุณสามารถทำเครื่องหมาย โดยทั่วไปจะหลีกเลี่ยงความจำเป็นในการย้ายเมธอดหากคุณไม่สามารถเข้าถึงประเภทที่เหมาะสมกว่าได้โดยง่าย แต่ยังคงให้สามารถเข้าถึงได้ในกรณีที่จำเป็นในลักษณะที่จะไม่แสดงเป็นส่วนหนึ่งของอินเทอร์เฟซสาธารณะสำหรับผู้ใช้ในชั้นเรียนของคุณ .
ไม่จำเป็น.
การย้ายวิธีการสาธารณะจากแบบคงที่ไปเป็นแบบไม่คงที่เป็นการเปลี่ยนแปลงที่ไม่ชัดเจนและจำเป็นต้องมีการเปลี่ยนแปลงกับผู้โทรหรือผู้บริโภค หากวิธีการดูเหมือนเป็นวิธีการอินสแตนซ์ แต่ไม่ได้ใช้สมาชิกอินสแตนซ์ใด ๆ ฉันขอแนะนำให้ใช้วิธีการอินสแตนซ์เพื่อใช้เป็นมาตรการในการพิสูจน์ในอนาคต
ใช่. เหตุผลที่ "มันสามารถคงที่" คือมันไม่ทำงานกับสถานะของวัตถุที่มันถูกเรียก ดังนั้นจึงไม่ใช่วิธีการอินสแตนซ์ แต่เป็นวิธีการคลาส หากสามารถทำสิ่งที่จำเป็นต้องทำโดยไม่เคยเข้าถึงข้อมูลสำหรับอินสแตนซ์ก็ควรเป็นแบบคงที่
ใช่มันควร มีเมตริกต่างๆของการมีเพศสัมพันธ์ที่วัดว่าคลาสของคุณขึ้นอยู่กับสิ่งอื่น ๆ อย่างไรเช่นคลาสอื่น ๆ วิธีการ ฯลฯ การสร้างวิธีการแบบคงที่เป็นวิธีที่จะรักษาระดับของการมีเพศสัมพันธ์ให้ต่ำลงเนื่องจากคุณสามารถมั่นใจได้ว่าวิธีการคงที่ไม่ได้อ้างอิงใด ๆ สมาชิก.
ฉันคิดว่ามันจะทำให้อ่านได้ง่ายขึ้นถ้าคุณทำเครื่องหมายว่าคงที่ ... จากนั้นคนที่เข้ามาจะรู้ว่ามันไม่ได้อ้างอิงตัวแปรอินสแตนซ์ใด ๆ โดยไม่ต้องอ่านฟังก์ชันทั้งหมด ...
โดยส่วนตัวแล้วฉันเป็นแฟนตัวยงของการไร้สัญชาติ วิธีการของคุณจำเป็นต้องเข้าถึงสถานะของคลาสหรือไม่? หากคำตอบคือไม่ (และอาจเป็นไม่ได้มิฉะนั้นคุณจะไม่พิจารณากำหนดให้เป็นวิธีการคงที่) ใช่แล้วไปเลย
การไม่เข้าถึงรัฐจะปวดหัวน้อยกว่า เช่นเดียวกับที่ควรซ่อนสมาชิกส่วนตัวที่คลาสอื่นไม่ต้องการจึงเป็นความคิดที่ดีที่จะซ่อนรัฐจากสมาชิกที่ไม่ต้องการ การเข้าถึงที่ลดลงอาจหมายถึงข้อบกพร่องน้อยลง นอกจากนี้ยังทำให้เธรดง่ายขึ้นเนื่องจากง่ายกว่ามากในการรักษาความปลอดภัยให้กับเธรดของสมาชิกแบบคงที่ นอกจากนี้ยังมีการพิจารณาประสิทธิภาพเนื่องจากรันไทม์ไม่จำเป็นต้องผ่านการอ้างอิงถึงสิ่งนี้เป็นพารามิเตอร์สำหรับวิธีการแบบคงที่
แน่นอนข้อเสียคือหากคุณเคยพบว่าวิธีการคงที่ก่อนหน้านี้ของคุณจะต้องเข้าถึงสถานะด้วยเหตุผลบางประการคุณต้องเปลี่ยนมัน ตอนนี้ฉันเข้าใจแล้วว่านี่อาจเป็นปัญหาสำหรับ API สาธารณะดังนั้นหากนี่เป็นวิธีการสาธารณะในคลาสสาธารณะบางทีคุณควรคิดถึงผลกระทบของสิ่งนี้สักหน่อย ถึงกระนั้นฉันไม่เคยเผชิญกับสถานการณ์ในโลกแห่งความจริงที่สิ่งนี้ทำให้เกิดปัญหา แต่บางทีฉันอาจจะโชคดี
ใช่ไปเพื่อมันโดยทั้งหมด
วิธีการคงที่เร็วกว่าวิธีที่ไม่คงที่ดังนั้นใช่ควรเป็นแบบคงที่หากทำได้และไม่มีเหตุผลพิเศษในการปล่อยให้เป็นแบบคงที่
ฉันแปลกใจที่มีเพียงไม่กี่คนที่กล่าวถึงการห่อหุ้มที่นี่ในความเป็นจริง วิธีการอินสแตนซ์จะเข้าถึงฟิลด์คุณสมบัติและวิธีการ (อินสแตนซ์) ส่วนตัวทั้งหมดโดยอัตโนมัติ นอกเหนือจากการป้องกันทั้งหมดที่สืบทอดมาจากคลาสพื้นฐาน
เมื่อคุณเขียนโค้ดคุณควรเขียนเพื่อให้คุณเปิดเผยให้น้อยที่สุดเท่าที่จะเป็นไปได้และเพื่อให้คุณเข้าถึงได้น้อยที่สุด
ใช่มันอาจเป็นเรื่องสำคัญที่จะต้องทำให้โค้ดของคุณเร็วขึ้นซึ่งจะเกิดขึ้นหากคุณทำให้วิธีการของคุณเป็นแบบคงที่ แต่โดยปกติแล้วสิ่งที่สำคัญกว่านั้นคือการทำให้โค้ดของคุณไม่สามารถสร้างจุดบกพร่องได้มากที่สุดเช่นกัน วิธีหนึ่งในการบรรลุเป้าหมายคือให้โค้ดของคุณเข้าถึง "ของส่วนตัว" ให้น้อยที่สุด
สิ่งนี้อาจดูเหมือนไม่เกี่ยวข้องในตอนแรกเนื่องจากเห็นได้ชัดว่า OP กำลังพูดถึงการปรับโครงสร้างใหม่ซึ่งไม่สามารถผิดพลาดได้ในสถานการณ์นี้และสร้างจุดบกพร่องใหม่ ๆ อย่างไรก็ตามโค้ดที่ถูกรีแฟคเตอร์นี้จะต้องได้รับการดูแลในอนาคตและแก้ไขซึ่งทำให้โค้ดของคุณมีการโจมตีที่ใหญ่กว่า surface "เกี่ยวกับข้อบกพร่องใหม่หากมีการเข้าถึงสมาชิกอินสแตนซ์ส่วนตัว โดยทั่วไปแล้วฉันคิดว่าข้อสรุปในที่นี้คือ"ใช่ส่วนใหญ่วิธีการของคุณควรเป็นแบบคงที่"เว้นแต่จะมีเหตุผลอื่นใดที่ทำให้ไม่คงที่ และนี่เป็นเพียงเพราะ "ใช้การห่อหุ้มและการซ่อนข้อมูลได้ดีขึ้นและสร้างรหัสที่" ปลอดภัยกว่า "...
การทำบางสิ่งให้คงที่เพียงเพราะคุณทำได้ไม่ใช่ความคิดที่ดี วิธีการคงที่ควรเป็นแบบคงที่เนื่องจากการออกแบบไม่ใช่เนื่องจากเหตุการณ์ที่เกิดขึ้น
เช่นเดียวกับที่ Michael กล่าวการเปลี่ยนแปลงในภายหลังจะทำลายรหัสที่ใช้อยู่
จากที่กล่าวมาดูเหมือนว่าคุณกำลังสร้างฟังก์ชันยูทิลิตี้ส่วนตัวสำหรับคลาสซึ่งในความเป็นจริงคงที่โดยการออกแบบ
หากคุณสามารถ refactor สองสามบรรทัดออกมาและวิธีที่ได้ผลลัพธ์อาจเป็นแบบคงที่อาจเป็นข้อบ่งชี้ว่าเส้นที่คุณดึงออกมาจากวิธีการนั้นไม่ได้อยู่ในคลาสที่มีเลยและคุณควรพิจารณาย้ายไปที่ ชั้นเรียนของตนเอง
ขึ้นอยู่กับ แต่โดยทั่วไปฉันไม่ทำให้วิธีการเหล่านั้นคงที่ โค้ดมีการเปลี่ยนแปลงอยู่เสมอและสักวันหนึ่งฉันอาจต้องการทำให้ฟังก์ชันนั้นเสมือนจริงและแทนที่มันในคลาสย่อย หรือบางวันอาจต้องอ้างอิงตัวแปรอินสแตนซ์ การเปลี่ยนแปลงเหล่านั้นจะทำได้ยากขึ้นหากต้องเปลี่ยนทุกไซต์การโทร
โดยส่วนตัวแล้วฉันไม่มีทางเลือกอื่นนอกจากทำให้มันคงที่ Resharper จะออกคำเตือนในกรณีนี้และ PM ของเรามีกฎ "No Warning from the Resharper"
ฉันขอแนะนำว่าวิธีที่ดีที่สุดในการคิดถึงเรื่องนี้คือ: หากคุณต้องการวิธีการคลาสที่จำเป็นต้องเรียกใช้เมื่อไม่มีอินสแตนซ์ของคลาสถูกสร้างอินสแตนซ์หรือคงสภาพโลกไว้บ้างก็เป็นความคิดที่ดี แต่โดยทั่วไปฉันขอแนะนำให้คุณเลือกที่จะทำให้สมาชิกไม่คงที่
คุณควรคิดถึงวิธีการและชั้นเรียนของคุณ:
ถ้าสองข้อสุดท้ายคือ 'ใช่' แสดงว่าเมธอด / คลาสของคุณน่าจะคงที่
ตัวอย่างที่ใช้มากที่สุดน่าจะเป็นMathคลาส ทุกภาษา OO หลักมีและวิธีการทั้งหมดจะคงที่ เนื่องจากคุณต้องสามารถใช้งานได้ทุกที่ทุกเวลาโดยไม่ต้องสร้างอินสแตนซ์
อีกตัวอย่างที่ดีคือReverse()วิธีการใน C #
นี่เป็นวิธีการคงที่ในArrayคลาส มันกลับลำดับอาร์เรย์ของคุณ
รหัส:
public static void Reverse(Array array)มันไม่ส่งคืนอะไรเลยอาร์เรย์ของคุณจะถูกย้อนกลับเนื่องจากอาร์เรย์ทั้งหมดเป็นอินสแตนซ์ของคลาส Array
ตราบเท่าที่คุณสร้างวิธีการใหม่แบบคงที่มันไม่ใช่การเปลี่ยนแปลงที่ทำลาย ในความเป็นจริง FxCop รวมคำแนะนำนี้ไว้เป็นหนึ่งในกฎ ( http://msdn.microsoft.com/en-us/library/ms245046(VS.80).aspx ) พร้อมข้อมูลต่อไปนี้:
หลังจากคุณทำเครื่องหมายวิธีการเป็นแบบคงที่คอมไพลเลอร์จะส่งไซต์การโทรที่ไม่ใช่เสมือนไปยังสมาชิกเหล่านี้ การปล่อยไซต์การเรียกที่ไม่ใช่เสมือนจะป้องกันการตรวจสอบที่รันไทม์สำหรับการเรียกแต่ละครั้งที่ทำให้แน่ใจว่าตัวชี้ออบเจ็กต์ปัจจุบันไม่เป็นค่าว่าง ซึ่งอาจส่งผลให้ประสิทธิภาพที่วัดได้เพิ่มขึ้นสำหรับโค้ดที่ไวต่อประสิทธิภาพ ในบางกรณีความล้มเหลวในการเข้าถึงอินสแตนซ์ออบเจ็กต์ปัจจุบันแสดงถึงปัญหาความถูกต้อง
ดังที่กล่าวไว้ความคิดเห็นแรกจาก David Kean สรุปข้อกังวลได้อย่างรวบรัดมากขึ้นโดยกล่าวว่านี่เป็นเรื่องที่ถูกต้องมากกว่าเกี่ยวกับการเพิ่มประสิทธิภาพ:
แม้ว่ากฎนี้จะถูกจัดประเภทเป็นปัญหาด้านประสิทธิภาพ แต่การปรับปรุงประสิทธิภาพของการสร้างเมธอดคงอยู่ที่ประมาณ 1% เท่านั้น แต่เป็นปัญหาด้านความถูกต้องมากกว่าที่อาจบ่งบอกถึงความไม่สมบูรณ์หรือข้อบกพร่องในสมาชิกจากความล้มเหลวในการใช้สมาชิกอินสแตนซ์อื่น ๆ การทำเครื่องหมายวิธีการแบบคงที่ ( ใช้ร่วมกันใน Visual Basic) ทำให้ชัดเจนในความตั้งใจที่จะไม่สัมผัสสถานะอินสแตนซ์
ฉันจะเปลี่ยนทุกอย่างที่ทำได้อย่างแน่นอนด้วยเหตุผลอื่น:
ฟังก์ชันคงที่เมื่อ JIT เรียกว่าไม่มีพารามิเตอร์ "this" นั่นหมายความว่าตัวอย่างเช่นฟังก์ชัน 3 พารามิเตอร์ที่ไม่คงที่ (เมธอดสมาชิก) จะถูกพุชด้วยพารามิเตอร์ 4 ตัวบนสแต็ก
ฟังก์ชันเดียวกันที่คอมไพล์เป็นฟังก์ชันคงที่จะถูกเรียกโดยใช้พารามิเตอร์ 3 ตัว สิ่งนี้สามารถเพิ่มการลงทะเบียนสำหรับ JIT และประหยัดพื้นที่สแต็ก ...
ฉันอยู่ในค่าย "only make private method static" การสร้างวิธีการสาธารณะสามารถแนะนำการมีเพศสัมพันธ์ที่คุณไม่ต้องการและอาจลดความสามารถในการทดสอบ: คุณไม่สามารถหยุดวิธีการคงที่สาธารณะได้
หากคุณต้องการทดสอบหน่วยวิธีที่ใช้วิธีการแบบคงที่สาธารณะคุณต้องทดสอบวิธีการคงที่เช่นกันซึ่งอาจไม่ใช่สิ่งที่คุณต้องการ
วิธีการคงที่โดยเนื้อแท้ซึ่งด้วยเหตุผลบางประการที่ทำให้ไม่คงที่เป็นเพียงสิ่งที่น่ารำคาญ เพื่อปัญญา:
ฉันโทรไปที่ธนาคารและขอยอดเงิน
พวกเขาขอหมายเลขบัญชีของฉัน
พอใช้. วิธีการอินสแตนซ์
ฉันโทรหาธนาคารของฉันและขอที่อยู่ทางไปรษณีย์
พวกเขาขอหมายเลขบัญชีของฉัน
WTF? ล้มเหลว - ควรเป็นวิธีการคงที่
ฉันมองโดยทั่วไปจากมุมมองการทำงานของฟังก์ชันบริสุทธิ์ จำเป็นต้องเป็นวิธีการอินสแตนซ์หรือไม่? หากไม่เป็นเช่นนั้นคุณอาจได้รับประโยชน์จากการบังคับให้ผู้ใช้ส่งผ่านตัวแปรและไม่รบกวนสถานะของอินสแตนซ์ปัจจุบัน (คุณยังคงสภาพสับสนได้ แต่ประเด็นก็คือโดยการออกแบบจะไม่ทำเช่นนั้น) โดยทั่วไปฉันจะออกแบบวิธีการอินสแตนซ์ในฐานะสมาชิกสาธารณะและพยายามอย่างดีที่สุดเพื่อให้สมาชิกส่วนตัวคงที่ หากจำเป็น (คุณสามารถแยกออกเป็นคลาสอื่น ๆ ได้ง่ายขึ้นในภายหลัง
ในกรณีเหล่านี้ฉันมักจะย้ายเมธอดไปที่ไลบรารีแบบคงที่หรือ utils ดังนั้นฉันจะไม่ผสมแนวคิดของ "อ็อบเจ็กต์" กับแนวคิดของ "คลาส"