ฉันควรเลือกคุณสมบัติที่มีหรือไม่มีฟิลด์ส่วนตัวหรือไม่?

codebase ที่ฉันกำลังทำงานอยู่ในขณะนี้มีแบบแผนของการใช้เขตข้อมูลส่วนตัวและคุณสมบัติสาธารณะ ตัวอย่างเช่นคลาสส่วนใหญ่มีสมาชิกกำหนดไว้ดังนี้:

// Fields
private double _foo;
private double _bar;
private double _baz;

// Properties
public double Foo
{
    get{ return _foo; }
    set{ _foo = value; }
}

public double Bar
{
    get{ return _bar; }
    set{ _bar = value; }
}

public double Baz
{
    get{ return _baz; }
}

ฉันรู้ว่าสิ่งเหล่านี้สามารถเขียนใหม่ได้โดยไม่ต้องมีคุณสมบัติส่วนตัวภายใน:

public double Foo{ get; set; }
public double Bar{ get; set; }
public double Baz{ get; private set; }

ฉันต้องการป้อนข้อมูลเกี่ยวกับสิ่งนี้:

• มีเหตุผลที่ดีหรือไม่ที่จะชอบสไตล์ที่เก่ากว่าและชัดเจนมากกว่าสไตล์ที่ใหม่กว่ากระชับกว่าหรือไม่
• ฉันควรจะเขียนคลาสใหม่ใด ๆ โดยใช้สไตล์ที่กระชับหรือฉันควรจะพยายามจับคู่รหัสที่เก่ากว่าเพื่อความมั่นคงหรือไม่ ความสอดคล้องมีมูลค่าเพียงพอในกรณีนี้เพื่อจัดรูปแบบที่เก่ากว่าหรือไม่

มีสองสามกรณีที่ยังคงเรียกว่าสไตล์ "เก่า" ที่เรียกว่า:

ตอบ: ประเภทที่ไม่เปลี่ยนรูปโดยใช้ภาษาที่ไม่เปลี่ยนรูปแบบ readonlyปรับปรุงใน C # ค้างค่าที่หลังจากการก่อสร้าง ไม่มีทางที่จะเลียนแบบสิ่งนี้ได้ด้วยคุณสมบัติที่ดำเนินการโดยอัตโนมัติ (ยัง)

public sealed class FooBarBazInator
{
    private readonly double foo;

    public FooBarBazInator(double foo)
    {
        this.foo = foo;
    }

    public double Foo
    {
        get
        {
            return this.foo;
        }
    }
}

B: ผู้ได้รับ / setters ของคุณมีเหตุผลใด ๆ รหัส WPF และ Silverlight (และที่คล้ายกัน) ที่ผูกกับข้อมูลในคลาสของคุณจะดำเนินการINotifyPropertyChangedดังนี้:

public class FooBarBazInator : INotifyPropertyChanged
{
    private double foo;

    public event PropertyChangedEventHandler PropertyChanged;

    public double Foo
    {
        get
        {
            return this.foo;
        }

        set
        {
            this.foo = value;
            this.RaisePropertyChanged("Foo");
        }
    }

    private void RaisePropertyChanged(string propertyName)
    {
        var propertyChanged = this.PropertyChanged;

        if (propertyChanged != null)
        {
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

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

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

public double Bar
{
    get { return _baz; }
    set { _bar = value; }
}

ฉันคิดว่าข้อผิดพลาดแบบนี้อาจเกิดขึ้นได้อย่างง่ายดายและค่อนข้างยากที่จะมองเห็น

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

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

แม้ว่าคำถามจะค่อนข้างเก่า แต่ฉันก็คิดว่าจะเพิ่มคะแนนสองสามคะแนนซึ่งฉันอ่านจากหนังสือที่มีมูลค่าถึงที่นี่

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

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

มีเหตุผลที่ดีหรือไม่ที่จะชอบสไตล์ที่เก่ากว่าและชัดเจนมากกว่าสไตล์ที่ใหม่กว่ากระชับกว่าหรือไม่

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

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

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