เขตข้อมูลสาธารณะเปรียบเทียบกับคุณสมบัติอัตโนมัติ

เรามักจะบอกว่าเราควรปกป้องการห่อหุ้มด้วยวิธีการ getter และ setter (คุณสมบัติใน C #) สำหรับฟิลด์คลาสแทนที่จะเปิดเผยฟิลด์กับโลกภายนอก

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

public class Book
{
    private string _title;

    public string Title
    {
          get{ return _title;  }
          set{ _title = value; }
    }
}

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

จากนั้นมาพร้อม C # 3.0 และฉันเห็นว่าพวกเขาเพิ่มคุณสมบัติอัตโนมัติ:

public class Book
{
    public string Title {get; set;} 
}

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

public class Book
{
    public string Title;
}

ในคำถามที่เกี่ยวข้องฉันมีบางเวลาที่ผ่านมามีลิงก์ไปยังการโพสต์ในบล็อกของ Jeff อธิบายความแตกต่างบางอย่าง

คุณสมบัติเทียบกับตัวแปรสาธารณะ

• การสะท้อนแสงทำงานได้แตกต่างกันไปตามตัวแปรและคุณสมบัติดังนั้นหากคุณใช้การสะท้อนแสงจะใช้คุณสมบัติทั้งหมดได้ง่ายขึ้น
• คุณไม่สามารถ databind กับตัวแปร

• การเปลี่ยนตัวแปรเป็นคุณสมบัติเป็นการเปลี่ยนแปลงที่ไม่สิ้นสุด ตัวอย่างเช่น:

  TryGetTitle(out book.Title); // requires a variable

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

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

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

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

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

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

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

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

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

publicมีอะไรผิดปกติคือในการทำสนาม แต่จำไว้ว่าการสร้างgetter/setterด้วยprivateเขตข้อมูลนั้นไม่มีการห่อหุ้ม IMO ถ้าคุณไม่สนใจเกี่ยวกับคุณสมบัติอื่น ๆ ของคุณเช่นกันอาจจะทำให้มันPropertypublic

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

หากคุณไปกับแอตทริบิวต์สาธารณะคุณจะมีความยืดหยุ่นน้อยลง

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

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

POV ของฉันหลังจากทำวิจัยแล้ว

1. การตรวจสอบ
2. อนุญาตให้แทนที่ accessor เพื่อเปลี่ยนลักษณะการทำงานของคุณสมบัติ
3. วัตถุประสงค์ในการแก้ไขข้อบกพร่อง เราจะสามารถทราบได้ว่าเมื่อใดและจะมีการเปลี่ยนแปลงคุณสมบัติอย่างไรโดยการตั้งค่าเบรกพอยต์ใน accessor
4. เราสามารถตั้งค่าฟิลด์ได้เท่านั้น ตัวอย่างเช่นชุดสาธารณะ () และส่วนตัวรับ () นี่เป็นไปไม่ได้กับเขตข้อมูลสาธารณะ

มันทำให้เรามีความเป็นไปได้และความสามารถในการขยายได้มากขึ้น