จุดของคุณสมบัติคืออะไร?

นี่คือข้อโต้แย้งบางประการสำหรับคุณสมบัติและข้อโต้แย้งของฉัน:

ใช้งานง่ายกว่าการเขียนวิธี getter และ setter

คู่ของ Getter และ setter เป็นกลิ่นของโค้ด การทำให้ง่ายต่อการเขียนสิ่งเหล่านี้ก็เหมือนกับการทำให้ล้มเหลวในการทดสอบคณิตศาสตร์โดยใช้แบบฟอร์ม Scantron และเติมใน 'C's ทั้งหมด วัตถุที่มีเพียงสถานะสำหรับการคงอยู่ไม่ควรใช้ getters / setters และควรสร้างวัตถุที่ไม่เปลี่ยนรูปในเวลาที่มีอยู่

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

พวกเขาให้ข้อบ่งชี้ประสิทธิภาพอย่างคร่าว ๆ กับผู้บริโภค

นี่คือสิ่งที่สามารถเปลี่ยนแปลงได้ในอนาคตสำหรับอสังหาริมทรัพย์ใด ๆ ก็ตาม สมมติว่าในรีลีส 1.0 การเข้าถึง PropertyX จะส่งคืนฟิลด์ ในรีลีส 1.5 หากฟิลด์เป็นโมฆะ PropertyX จะใช้รูปแบบวัตถุ Null เพื่อสร้างวัตถุ null ใหม่ ในรุ่น 2.0 ฟิลด์จะได้รับการตรวจสอบเพิ่มเติมโดยวิธี getter ใน PropertyX

เนื่องจากคุณสมบัติมีความซับซ้อนมากขึ้นการบ่งชี้ประสิทธิภาพของการใช้คุณสมบัติจึงดูเหมือนจะน้อยลงเรื่อย ๆ

มันดีกว่าทุ่งสาธารณะ

นี่เป็นเรื่องจริง แต่เป็นวิธีการ

พวกเขาเป็นตัวแทนด้านที่แตกต่างกันโดยพื้นฐานของวัตถุกว่าวิธีการและผู้บริโภคของวัตถุควรใส่ใจเกี่ยวกับเรื่องนี้

คุณแน่ใจหรือว่าข้อความทั้งสองข้างต้นเป็นจริง

พวกเขาพิมพ์ง่ายกว่าผู้ชาย

แน่นอนว่าการพิมพ์myObject.Lengthนั้นง่ายกว่าการพิมพ์myObject.Length()แต่ไม่สามารถแก้ไขได้ด้วยน้ำตาลประโยคเล็กน้อย

ทำไมต้องใช้วิธีการแทนคุณสมบัติ?

• ไม่รับประกันประสิทธิภาพ API จะยังคงเป็นจริงแม้ว่าวิธีการจะซับซ้อนมากขึ้น ผู้บริโภคจะต้องโปรไฟล์รหัสของพวกเขาหากพวกเขากำลังทำงานในปัญหาประสิทธิภาพการทำงานและไม่พึ่งพา word-of-API

• น้อยกว่าสำหรับผู้บริโภคที่จะคิดเกี่ยวกับ สถานที่ให้บริการนี้มี setter หรือไม่? วิธีการที่แน่นอนไม่ได้

• ผู้บริโภคกำลังคิดถึง OOP ที่เหมาะสม ในฐานะผู้บริโภค API ฉันสนใจที่จะโต้ตอบกับพฤติกรรมของวัตถุ เมื่อฉันเห็นคุณสมบัติใน API มันดูเหมือนเป็นสถานะมาก ในความเป็นจริงถ้าคุณสมบัติทำมากเกินไปพวกเขาไม่ควรจะเป็นคุณสมบัติด้วยซ้ำดังนั้นคุณสมบัติใน API เป็นสถานะที่ปรากฏแก่ผู้บริโภค

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

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

(ความคิดเหล่านี้มาถึงฉันหลังจากคิดถึง CQS)

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

คู่ของ Getter และ setter เป็นกลิ่นของโค้ด

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

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

ทัศนคติที่น่าสงสัยอย่างมาก หาก GUI ต้องการส่งออกข้อมูลที่ถือโดย a DataStuffManagerImplมันจำเป็นต้องได้รับหมายเลขนั้นจากอย่างใด (และไม่ใช่การยัดเยียดครึ่งหนึ่งของแอปพลิเคชันลงในคลาสวิดเจ็ตไม่ใช่ตัวเลือก)

เนื่องจากคุณสมบัติมีความซับซ้อนมากขึ้นการบ่งชี้ประสิทธิภาพของการใช้คุณสมบัติจึงดูเหมือนจะน้อยลงเรื่อย ๆ

[วิธีการมี] ไม่มีการรับรองประสิทธิภาพ API จะยังคงเป็นจริงแม้ว่าวิธีการจะซับซ้อนมากขึ้น ผู้บริโภคจะต้องโปรไฟล์รหัสของพวกเขาหากพวกเขากำลังทำงานในปัญหาประสิทธิภาพการทำงานและไม่พึ่งพา word-of-API

ในเกือบทุกกรณีลอจิกการตรวจสอบความถูกต้องและอื่น ๆ ทั้งหมดยังคงมีประสิทธิภาพ O (1) หรือมีค่าเป็นลบ ถ้าไม่คุณอาจไปไกลเกินไปและถึงเวลาเปลี่ยนแล้ว และgetX()วิธีการก็มักจะถือว่าถูกเช่นกัน!

แน่นอนว่าการพิมพ์ myObject.Length นั้นง่ายกว่าการพิมพ์ myObject.Length () แต่ไม่สามารถแก้ไขด้วยน้ำตาล syntactic เล็กน้อยได้หรือไม่

สรรพคุณคือน้ำตาลซินแทคติค

น้อยกว่าสำหรับผู้บริโภคที่จะคิดเกี่ยวกับ สถานที่ให้บริการนี้มี setter หรือไม่? วิธีการที่แน่นอนไม่ได้

"มีผู้ตั้งตัวให้ทะเยอทะยานนี้หรือไม่?" ความแตกต่างเดียวกัน

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

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

คู่ของ Getter และ setter เป็นกลิ่นของโค้ด

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

นี่คือสิ่งที่สามารถเปลี่ยนแปลงได้ในอนาคตสำหรับอสังหาริมทรัพย์ใด ๆ ก็ตาม สมมติว่าในรีลีส 1.0 การเข้าถึง PropertyX จะส่งคืนฟิลด์ ในรีลีส 1.5 หากฟิลด์เป็นโมฆะ PropertyX จะใช้รูปแบบวัตถุ Null เพื่อสร้างวัตถุ null ใหม่ ในรุ่น 2.0 ฟิลด์จะได้รับการตรวจสอบเพิ่มเติมโดยวิธี getter ใน PropertyX

เนื่องจากคุณสมบัติมีความซับซ้อนมากขึ้นการบ่งชี้ประสิทธิภาพของการใช้คุณสมบัติจึงดูเหมือนจะน้อยลงเรื่อย ๆ

ดูเหมือน API ที่ออกแบบมาไม่ดีฉันไม่เห็นว่าเป็นความผิดของไวยากรณ์คุณสมบัติ

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

หลักฐานของคุณผิด

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

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

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

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

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

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

เมื่อคุณใช้ไวยากรณ์ของคุณสมบัติ C # คอมไพเลอร์จะสร้างเมธอด getter และ setter อย่างเงียบ ๆ ด้วยเมทาดาทาที่บอกภาษาที่เข้าใจคุณสมบัติว่าเป็นคุณสมบัติการสร้างประโยคระดับเฟิร์สคลาสเพื่อปฏิบัติต่อพวกมัน นั่นคือความจริงแล้วน้ำตาล syntactic ที่คุณต้องการ บางภาษาที่สามารถทำงานบน CLR ไม่ได้ซ่อนรายละเอียดนี้จากคุณ (Boo ถ้าหน่วยความจำทำหน้าที่ฉันและการใช้งาน Lisp บางอย่าง) และคุณสามารถโทรหา getters และ setters อย่างชัดเจน

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

ตอนนี้คำถามที่กว้างขึ้นก็คือว่าวิธีการทะเยอทะยานและ Setter เป็นจริงสิ่งที่ดี มีการแลกเปลี่ยนกันอย่างชัดเจน ถ้าคุณมีวิธีการเปลี่ยนแปลงรหัสของคุณคือขนานน้อยโดยเนื้อแท้เพราะตอนนี้คุณต้องจัดการกับปัญหาการประสานด้าย และเป็นไปได้มากที่คุณจะเสี่ยงต่อการฝ่าฝืนกฎหมายของ Demeter โดยใช้วิธีการเปลี่ยนแปลง (ไม่ว่าจะเรียกว่าคุณสมบัติหรือวิธี getter / setter พวกมันเทียบเท่ากัน) เพราะมันสะดวกที่จะทำเช่นนั้น

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

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

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

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

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

account.setBalance(Account.getBalance()+deposit);

ชัดแจ้งน้อยกว่ามาก

account.Balance += deposit;

คุณมีมุมมองทางศาสนาที่ตรงกันข้ามกับฉัน :)

เมื่อฉันย้ายจาก Delphi ไปยัง Java การขาดคุณสมบัติก็ดูถูกฉันอย่างมาก ฉันเคยประกาศคุณสมบัติและชี้ไปที่ตัวแปรส่วนตัวโดยตรงหรือเขียน getter (ที่ได้รับการป้องกัน) และ setter แล้ว "ประปา" พวกเขาไปยังสถานที่ให้บริการ สิ่งนี้ห่อหุ้มคุณสมบัติและควบคุมว่าควรเข้าถึงในลักษณะที่ชัดเจนได้อย่างไร คุณสามารถมีคุณสมบัติแบบอ่านอย่างเดียวซึ่งคำนวณผลรวมเมื่อเข้าถึงและเรียกว่า "รวม" ไม่ใช่ "_getTotal ()" หรือ ballochs ที่คล้ายกัน นอกจากนี้ยังหมายความว่าคุณสามารถ จำกัด การเข้าถึงคุณสมบัติได้ด้วยการทำให้พวกเขาได้รับการปกป้องในคลาสฐานนามธรรมจากนั้นย้ายพวกเขาไปสู่สาธารณะหรือเผยแพร่ในคลาสย่อย

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

หนึ่งในเหตุผลที่คุณสมบัติถูกนำมาใช้ใน Java Beans Framework คือการอนุญาตให้รวมกับ IDE - คุณสามารถลากส่วนประกอบเหล่านั้นไปยัง IDE และแก้ไขคุณสมบัติโดยใช้ตัวแก้ไขคุณสมบัติ

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

ทุกวันนี้มีหลายกรณีที่คุณสมบัติการเข้าถึงและแก้ไขไม่ผ่านรหัสปกติ - เช่นขณะทำการดีบัก

อีกมุมหนึ่ง - พวกมันมาจาก VB จริงๆ โปรดจำไว้ว่าย้อนกลับไปในยุคมืดมนของศตวรรษที่ 20 เมื่อ. NET รู้สึกถึงความสำคัญอย่างหนึ่งคือมันง่ายสำหรับการแทนที่ VB เพื่อให้โปรแกรมเมอร์ VB ของคุณสามารถลากและวางสิ่งต่างๆลงบนเว็บฟอร์มได้ VB มีคุณสมบัติดังนั้นคุณจำเป็นต้องเก็บคุณสมบัตินั้นไว้เพื่อแปลสิ่งที่ถูกต้อง

มีวัตถุประสงค์อย่างน้อยสองประการสำหรับคุณสมบัติ:

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

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