อาจมีการเปลี่ยนแปลงค่าคงที่เมื่อเวลาผ่านไป?

ในระหว่างขั้นตอนการพัฒนามีตัวแปรบางอย่างที่จำเป็นต้องได้รับการแก้ไขในการรันเดียวกัน แต่อาจจำเป็นต้องแก้ไขตลอดเวลา เช่น a booleanto signal debug mode ดังนั้นเราจึงทำสิ่งต่าง ๆ ในโปรแกรมที่ปกติแล้วเราจะไม่ทำ

มันเป็นสไตล์ที่ไม่ดีหรือไม่ที่มีค่าเหล่านี้ในค่าคงที่เช่นfinal static int CONSTANT = 0ใน Java? ฉันรู้ว่าค่าคงที่ยังคงเหมือนเดิมในช่วงรันไทม์ แต่มันควรจะเหมือนกันในระหว่างการพัฒนาทั้งหมดยกเว้นการเปลี่ยนแปลงที่ไม่ได้วางแผนไว้แน่นอน?

ฉันค้นหาคำถามที่คล้ายกัน แต่ไม่พบสิ่งใดที่ตรงกับของฉันอย่างแน่นอน

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

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

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

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

เพราะทั้งหมดนี้บางคนแนะนำไม่เคยเปลี่ยนค่าสุดท้ายคงที่เลย สำหรับห้องสมุดที่อาจมีการเผยแพร่อย่างกว้างขวางและปรับปรุงในรูปแบบที่ไม่รู้จักในเวลาที่ไม่รู้จักนี่เป็นแนวปฏิบัติที่ดี

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

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

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

// DO NOT CHANGE without consulting with the legal department!
// Get written consent form from them before release!
public const int LegalLimitInSeconds = ...

เป็นวิธีที่ดีกว่าในการสื่อสารกับตัวคุณในอนาคต

เราจำเป็นต้องแยกแยะค่าคงที่สองด้าน:

• ชื่อสำหรับค่าที่รู้จักในเวลาการพัฒนาซึ่งเราแนะนำเพื่อการบำรุงรักษาที่ดีขึ้นและ
• ค่าที่พร้อมใช้งานสำหรับคอมไพเลอร์

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

แต่ถ้าค่าของค่าคงที่เป็นที่รู้จักกันในเวลารวบรวมแล้วคอมไพเลอร์สามารถดำเนินการคำนวณด้วยค่านั้น ยกตัวอย่างเช่นภาษา Java มีแนวคิดของการแสดงออกอย่างต่อเนื่อง การแสดงออกอย่างต่อเนื่องคือการแสดงออกใด ๆ ที่ประกอบด้วยเพียงตัวอักษรของดั้งเดิมหรือสตริงการดำเนินการเกี่ยวกับการแสดงออกอย่างต่อเนื่อง (เช่นการหล่อการเพิ่มสตริงที่ต่อกัน) และตัวแปรคงที่ [ JLS §15.28 ] ตัวแปรคงที่คือfinalตัวแปรที่เริ่มต้นได้ด้วยนิพจน์คงที่ [JLS §4.12.4] ดังนั้นสำหรับ Java นี่คือค่าคงที่เวลาคอมไพล์:

public static final int X = 7;

สิ่งนี้กลายเป็นเรื่องที่น่าสนใจเมื่อมีการใช้ตัวแปรคงที่ในหน่วยการคอมไพล์หลายชุด พิจารณา:

• A.java:

  public class A { public static final int X = 7; }

• B.java:

  public class B { public static final int Y = A.X + 2; }

ตอนนี้เมื่อเราคอมไพล์ไฟล์เหล่านี้B.classไบต์จะประกาศฟิลด์Y = 9เพราะB.Yเป็นตัวแปรคงที่

แต่เมื่อเราเปลี่ยนA.Xตัวแปรเป็นค่าที่แตกต่าง (พูดX = 0) และคอมไพล์A.javaไฟล์ใหม่เท่านั้นก็B.Yยังคงหมายถึงค่าเก่า สถานะA.X = 0, B.Y = 9นี้ไม่สอดคล้องกับการประกาศในซอร์สโค้ด การแก้ไขข้อบกพร่องมีความสุข!

นี่ไม่ได้หมายความว่าค่าคงที่ไม่ควรเปลี่ยนแปลง ค่าคงที่นั้นดีกว่าตัวเลขเวทย์มนตร์ที่ปรากฏโดยไม่มีคำอธิบายในซอร์สโค้ด อย่างไรก็ตามค่าของค่าคงที่สาธารณะเป็นส่วนหนึ่งของประชาชน API สิ่งนี้ไม่เฉพาะกับ Java แต่เกิดขึ้นใน C ++ และภาษาอื่น ๆ ที่มีหน่วยการคอมไพล์แยกต่างหาก หากคุณเปลี่ยนค่าเหล่านี้คุณจะต้องคอมไพล์โค้ดที่ต้องพึ่งพาอีกครั้งทั้งหมดเช่นทำการคอมไพล์ใหม่ทั้งหมด

ขึ้นอยู่กับลักษณะของค่าคงที่พวกเขาอาจนำไปสู่ข้อสันนิษฐานที่ไม่ถูกต้องโดยนักพัฒนา หากมีการเปลี่ยนแปลงค่าเหล่านี้พวกเขาอาจก่อให้เกิดข้อผิดพลาด public static final int R = 4, W = 2, X = 1ตัวอย่างเช่นชุดของค่าคงที่อาจจะได้รับการแต่งตั้งเพื่อให้พวกเขาในรูปแบบรูปแบบบิตบางอย่างเช่น หากสิ่งเหล่านี้เปลี่ยนเป็นรูปแบบโครงสร้างที่แตกต่างกันเช่นR = 0, W = 1, X = 2นั้นรหัสที่มีอยู่เช่นboolean canRead = perms & Rจะไม่ถูกต้อง และแค่คิดว่าความสนุกที่จะตามมาคือInteger.MAX_VALUEการเปลี่ยน! ไม่มีการแก้ไขที่นี่เป็นสิ่งสำคัญที่ต้องจำไว้ว่าคุณค่าของค่าคงที่บางอย่างมีความสำคัญและไม่สามารถเปลี่ยนแปลงได้ง่ายๆ

แต่สำหรับค่าคงที่ส่วนใหญ่ที่เปลี่ยนพวกมันจะเป็นไปได้ตราบใดที่มีการพิจารณาข้อ จำกัด ข้างต้น ค่าคงที่ปลอดภัยที่จะเปลี่ยนเมื่อความหมายไม่ใช่ค่าเฉพาะเป็นสิ่งสำคัญ เช่นนี้จะเป็นกรณีสำหรับ tunables เช่นBORDER_WIDTH = 2หรือTIMEOUT = 60; // secondsหรือแม่แบบเช่นAPI_ENDPOINT = "https://api.example.com/v2/"- แม้ว่าเนื้อหาบางส่วนหรือทั้งหมดของผู้ที่ควรจะระบุไว้ในแฟ้มการกำหนดค่ามากกว่ารหัส

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

• ค่าคงที่ใช้พื้นที่ของแอปพลิเคชัน
• ธงคอมไพเลอร์ไม่
• รหัสที่ถูกปิดโดยค่าคงที่สามารถอัปเดตและเปลี่ยนแปลงด้วยเครื่องมือการเปลี่ยนโครงสร้างใหม่
• รหัสถูกปิดโดยธงคอมไพเลอร์ไม่สามารถ

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

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

คุณต้องประเมินกรณีการใช้งานและสาเหตุที่คุณต้องการเปลี่ยนค่าคงที่

ฉันไม่ได้เป็นแฟนของงบผ้าห่มง่าย ๆ แต่โดยทั่วไปเพื่อนร่วมงานอาวุโสของคุณถูกต้อง หากมีบางสิ่งที่ผูกพันกับการเปลี่ยนแปลงบ่อยครั้งอาจจำเป็นต้องเป็นรายการที่กำหนดค่าได้ ตัวอย่างเช่นคุณอาจโน้มน้าวให้เพื่อนร่วมงานของคุณมีค่าคงที่IsInDebugMode = trueเมื่อคุณต้องการป้องกันโค้ดบางอย่างจากการไม่ทำงาน อย่างไรก็ตามบางสิ่งอาจต้องเปลี่ยนบ่อยกว่าที่คุณปล่อยแอปพลิเคชัน หากเป็นกรณีนี้คุณต้องมีวิธีการเปลี่ยนค่าในเวลาที่เหมาะสม TaxRate = .065คุณสามารถใช้ตัวอย่างของการที่ อาจเป็นจริงในเวลาที่คุณรวบรวมรหัส แต่เนื่องจากกฎหมายใหม่สามารถเปลี่ยนแปลงได้ก่อนที่คุณจะปล่อยแอปพลิเคชันรุ่นถัดไปของคุณ นั่นคือสิ่งที่จำเป็นต้องได้รับการอัพเดตทั้งจากกลไกการจัดเก็บข้อมูลบางอย่าง (เช่นไฟล์หรือฐานข้อมูล)

const, #defineหรือfinalเป็นคำใบ้คอมไพเลอร์ (หมายเหตุว่า#defineไม่จริงคำใบ้แมโครและมีประสิทธิภาพมากขึ้นอย่างมีนัยสำคัญ) มันบ่งชี้ว่าค่าจะไม่เปลี่ยนแปลงไปจากการดำเนินการของโปรแกรมและการเพิ่มประสิทธิภาพต่างๆอาจทำได้

อย่างไรก็ตามในฐานะที่เป็นคอมไพเลอร์คำแนะนำคอมไพเลอร์ทำสิ่งที่โปรแกรมเมอร์ไม่อาจคาดหวังได้เสมอไป โดยเฉพาะอย่างยิ่งจะ javac แบบอินไลน์static final int FOO = 42;เพื่อให้ได้ทุกที่ที่FOOมีการใช้งานที่เกิดขึ้นจริง42รหัสไบต์รวบรวมจะอ่าน

นี่คือไม่ใหญ่เกินไปของความประหลาดใจจนกว่าจะมีคนเปลี่ยนค่าโดยไม่ต้อง recompiling อื่น ๆ หน่วยรวบรวม (ไฟล์ .java) - และ42(เห็นซากในรหัสไบต์? มันเป็นไปได้ที่จะปิดการใช้งาน javac ของ inlining ของตัวแปรสุดท้ายคงที่ )

การทำอะไรบางอย่างstatic finalหมายความว่ามันเป็นอย่างนั้นและตลอดไปจะเป็นเช่นนั้นและการเปลี่ยนแปลงมันเป็นเรื่องใหญ่จริงๆ - โดยเฉพาะอย่างยิ่งถ้ามันเป็นอย่างprivateนั้น

ค่าคงที่สำหรับสิ่งต่าง ๆ เช่นfinal static int ZERO = 0ไม่มีปัญหา final static double TAX_RATE = 0.55(นอกเหนือจากการเป็นเงินและทวีคูณนั้นไม่ดีและควรใช้ BigDecimal แต่ไม่ใช่แบบดั้งเดิมและไม่อินไลน์) เป็นปัญหาและควรได้รับการตรวจสอบด้วยความระมัดระวังอย่างยิ่งสำหรับการใช้งาน

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

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

ความสามารถในการเปลี่ยนแปลงระหว่างการรันเป็นหนึ่งในจุดที่สำคัญที่สุดในการกำหนดค่าคงที่ในซอร์สโค้ดของคุณ!

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

เป็นตัวอย่างที่ไม่พึงประสงค์: จะไม่มีเหตุผลที่จะมีค่าคงTRUEที่ซึ่งประเมินtrueเป็นภาษาที่มีtrueคำหลักจริง คุณจะไม่เคยประกาศแม้แต่ครั้งเดียวTRUE=falseยกเว้นว่าเป็นเรื่องตลกที่โหดร้าย

แน่นอนว่ายังมีการใช้ค่าคงที่อื่น ๆ เช่นการย่อโค้ด ( CO_NAME = 'My Great World Unique ACME Company') หลีกเลี่ยงการทำซ้ำ ( PI=3.141) ตั้งค่าอนุสัญญา ( TRUE=1) หรืออะไรก็ตาม แต่การมีตำแหน่งที่กำหนดเพื่อเปลี่ยนค่าคงที่นั้นเป็นหนึ่งในสิ่งที่โดดเด่นที่สุด