ทราบว่ามีความคิดนี้การตรวจสอบสำหรับ Java เป็นอย่างดีก็จะเรียกว่าวิธีการอาจจะ 'คงที่' ,
การตรวจสอบนี้รายงานวิธีการใด ๆ ที่อาจทำให้คงที่ได้อย่างปลอดภัย วิธีการอาจเป็นแบบคงที่ถ้ามันไม่ได้อ้างอิงวิธีการแบบคงที่ใด ๆ ของชั้นเรียนและเขตข้อมูลที่ไม่คงที่และไม่ได้ถูกแทนที่ในชั้นย่อย ...
แม้ว่าจะเป็นรหัส Java การตรวจสอบนี้จะถูกปิดใช้งานตามค่าเริ่มต้น (โปรแกรมเมอร์สามารถเปิดใช้งานได้ตามดุลยพินิจ) เหตุผลที่เป็นไปได้มากที่สุดคือความถูกต้อง / ความมีประโยชน์ของการตรวจสอบดังกล่าวอาจถูกท้าทายโดยใช้แหล่งข้อมูลที่เชื่อถือได้สองแหล่ง
เริ่มต้นด้วยการสอน Java อย่างเป็นทางการค่อนข้าง จำกัด เมื่อวิธีการควรจะคงที่:
การใช้งานทั่วไปสำหรับวิธีการแบบคงที่คือการเข้าถึงเขตข้อมูลแบบคงที่
จากด้านบนอาจกล่าวได้ว่าการเปิดการตรวจสอบตามค่าเริ่มต้นนั้นไม่สอดคล้องกับการใช้งานตัวดัดแปลงแบบคงที่ที่แนะนำใน Java
นอกจากนี้ยังมีแหล่งข้อมูลอีกสองสามแห่งที่แนะนำให้ใช้แนวทางที่รอบคอบในการใช้ความคิดที่อยู่เบื้องหลังการตรวจสอบนี้หรือแม้แต่ทำให้หมดกำลังใจ
ดูตัวอย่างบทความ Java World - Mr. Happy Object สอนวิธีการคงที่ :
วิธีการใด ๆ ที่เป็นอิสระจากสถานะของอินสแตนซ์เป็นผู้สมัครที่ถูกประกาศว่าเป็นแบบคงที่
โปรดทราบว่าฉันพูดว่า "ผู้สมัครที่ได้รับการประกาศให้คงที่" แม้แต่ในตัวอย่างก่อนหน้านี้ไม่มีอะไรบังคับให้คุณประกาศinstances()ว่าเป็นแบบคงที่ การประกาศเป็นแบบคงที่จะทำให้การโทรสะดวกขึ้นเนื่องจากคุณไม่ต้องการอินสแตนซ์สำหรับเรียกใช้เมธอด บางครั้งคุณจะมีวิธีการที่ดูเหมือนจะไม่ขึ้นอยู่กับสถานะของอินสแตนซ์ คุณอาจไม่ต้องการทำให้วิธีการเหล่านี้คงที่ ในความเป็นจริงคุณอาจต้องการประกาศเป็นแบบคงที่หากคุณต้องการเข้าถึงโดยไม่ต้องดำเนินการใด ๆ
ยิ่งกว่านั้นแม้ว่าคุณจะสามารถประกาศวิธีการดังกล่าวเป็นแบบคงที่ แต่คุณอาจไม่ต้องการเนื่องจากปัญหาการสืบทอดที่มันแทรกเข้าในการออกแบบของคุณ ดู"การออกแบบเชิงวัตถุที่มีประสิทธิภาพ"เพื่อดูบางประเด็นที่คุณจะต้องเผชิญ ...
บทความที่บล็อกการทดสอบของ Google แม้จะไปไกลเท่าที่อ้างว่าวิธีการแบบคงที่เป็นความตายต่อการตรวจสอบได้ :
ให้ทำออกกำลังกายจิต สมมติว่าแอปพลิเคชันของคุณไม่มีอะไรเลยนอกจากวิธีการคงที่ (ใช่รหัสเช่นนั้นเป็นไปได้ที่จะเขียนมันเรียกว่าการเขียนโปรแกรมขั้นตอน) ตอนนี้จินตนาการกราฟโทรของแอปพลิเคชันนั้น หากคุณพยายามเรียกใช้เมธอด leaf คุณจะไม่มีปัญหาในการตั้งค่าสถานะและยืนยันปัญหามุมทั้งหมด เหตุผลก็คือเมธอด leaf ทำให้ไม่มีการโทรเพิ่มเติม ในขณะที่คุณเคลื่อนที่ห่างจากใบไม้และใกล้กับmain()วิธีรูทมันจะยากขึ้นและยากขึ้นในการตั้งค่าสถานะในการทดสอบของคุณและยากที่จะยืนยันสิ่งต่าง ๆ หลายสิ่งเป็นไปไม่ได้ที่จะยืนยัน การทดสอบของคุณจะมีขนาดใหญ่ขึ้นเรื่อย ๆ เมื่อคุณมาถึงmain()วิธีที่คุณไม่มีการทดสอบหน่วยอีกต่อไป (เนื่องจากหน่วยของคุณเป็นแอปพลิเคชันทั้งหมด) ตอนนี้คุณมีการทดสอบสถานการณ์ ลองนึกภาพว่าแอปพลิเคชันที่คุณพยายามทดสอบนั้นเป็นโปรแกรมประมวลผลคำ มีไม่มากที่คุณสามารถยืนยันจากวิธีการหลัก ...
บางครั้งวิธีการคงที่เป็นโรงงานสำหรับวัตถุอื่น ๆ สิ่งนี้จะทำให้ปัญหาการทดสอบดีขึ้นอีก ในการทดสอบเราใช้ความจริงที่ว่าเราสามารถโยงวัตถุแทนการอ้างอิงที่สำคัญด้วย mocks เมื่อnewโอเปอเรเตอร์ถูกเรียกเราไม่สามารถแทนที่เมธอดด้วยคลาสย่อย ผู้เรียกของโรงงานคงที่ดังกล่าวจะถูกผูกไว้อย่างถาวรกับชั้นคอนกรีตซึ่งวิธีการโรงงานแบบคงที่ผลิต ในคำอื่น ๆ ความเสียหายของวิธีการแบบคงที่อยู่ไกลเกินกว่าวิธีแบบคงที่ตัวเอง แต่การเดินสายกราฟวัตถุและรหัสการก่อสร้างเป็นวิธีคงที่ไม่ดีเป็นพิเศษเนื่องจากการเดินสายกราฟวัตถุเป็นวิธีที่เราแยกสิ่งต่าง ๆ สำหรับการทดสอบ ...
คุณเห็นจากข้างต้นดูเหมือนเป็นเรื่องธรรมดาที่การตรวจสอบที่กล่าวถึงถูกปิดโดยปริยายสำหรับ Java
นักพัฒนา IDE จะมีเวลาอธิบายยากมากว่าทำไมพวกเขาคิดว่ามันสำคัญมากที่จะต้องตั้งไว้เป็นค่าเริ่มต้นเทียบกับข้อเสนอแนะที่ได้รับการยอมรับและแนวทางปฏิบัติที่ดีที่สุด
สำหรับ Groovy สิ่งต่าง ๆ ค่อนข้างมาก ไม่มีข้อโต้แย้งใด ๆ ที่กล่าวมาข้างต้นนำไปใช้โดยเฉพาะอย่างยิ่งเกี่ยวกับความสามารถในการทดสอบดังที่อธิบายไว้เช่นในการเยาะเย้ยวิธีการคงที่ในบทความGroovyที่ Javalobby:
หากคลาส Groovy ที่คุณกำลังทำการทดสอบเรียกใช้วิธีการคงที่ในคลาส Groovy อื่นคุณสามารถใช้ ExpandoMetaClass ซึ่งช่วยให้คุณสามารถเพิ่มเมธอด constructors คุณสมบัติและเมธอดแบบไดนามิก ...
ความแตกต่างนี้มีแนวโน้มว่าทำไมการตั้งค่าเริ่มต้นสำหรับการตรวจสอบที่กล่าวถึงอยู่ตรงข้ามใน Groovy ในขณะที่จาวาเริ่มต้น "เปิด" จะเป็นแหล่งที่มาของความสับสนของผู้ใช้ใน Groovy การตั้งค่าตรงข้ามอาจสร้างความสับสนให้กับผู้ใช้ IDE
"เฮ้วิธีนี้ไม่ได้ใช้ฟิลด์อินสแตนซ์ทำไมคุณไม่เตือนฉันถึงเรื่องนี้" คำถามนั้นจะตอบได้ง่ายสำหรับ Java (ตามที่อธิบายข้างต้น) แต่สำหรับ Groovy ไม่มีคำอธิบายที่น่าสนใจ