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

คำถามด่วน: คุณตัดสินใจใช้คุณสมบัติ (ใน C #) เมื่อใดและคุณตัดสินใจใช้วิธีการเมื่อใด

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

public void SetLabel(string text)
{
    Label.Text = text;
}

ในตัวอย่างLabelคือตัวควบคุมบนเพจ ASPX มีหลักการที่สามารถควบคุมการตัดสินใจ (ในกรณีนี้) ว่าจะทำวิธีนี้หรือคุณสมบัติ

ฉันจะยอมรับคำตอบที่กว้างและครอบคลุมที่สุด แต่นั่นก็สัมผัสกับตัวอย่างที่ฉันให้ไว้ด้วย

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

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

ใช่หากสิ่งที่คุณทำคือการรับและตั้งค่าให้ใช้คุณสมบัติ

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

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

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

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

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

วิธีการห่อหุ้มการดำเนินการ

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

ฉันใช้วิธีการเมื่อฉันสร้างการดำเนินการเช่นการดึงข้อมูลจากฐานข้อมูล การดำเนินการใด ๆ ที่มีชิ้นส่วนเคลื่อนไหวเป็นตัวเลือกสำหรับวิธีการ

ในตัวอย่างโค้ดของคุณฉันจะรวมไว้ในคุณสมบัติถ้าฉันต้องการเข้าถึงนอกมันที่มีคลาส

public Label Title 
{
   get{ return titleLabel;}
   set{ titleLabel = value;}
}

การตั้งค่าข้อความ:

Title.Text = "Properties vs Methods";

หากฉันเพียงตั้งค่าคุณสมบัติข้อความของป้ายกำกับนี่คือวิธีที่ฉันจะทำ:

public string Title 
{
   get{ return titleLabel.Text;}
   set{ titleLabel.Text = value;}
}

การตั้งค่าข้อความ:

Title = "Properties vs Methods";

หากคุณกำลังตั้งค่าคุณสมบัติจริงของวัตถุของคุณแสดงว่าคุณใช้คุณสมบัติ

หากคุณกำลังดำเนินงาน / ฟังก์ชันการทำงานคุณจะใช้วิธีการ

ในตัวอย่างของคุณเป็นคุณสมบัติที่แน่นอนที่ถูกกำหนด

อย่างไรก็ตามหากฟังก์ชันการทำงานของคุณคือ AppendToLabel คุณจะต้องใช้วิธีการ

ค้นหาผ่าน MSDN ฉันพบข้อมูลอ้างอิงเกี่ยวกับProperties vs Methodsที่ให้แนวทางที่ยอดเยี่ยมสำหรับการสร้างวิธีการ:

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

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

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

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

ลองนึกถึงคุณสมบัติเช่นแอตทริบิวต์ รถยนต์มีคุณลักษณะมากมาย สี MPG รุ่น ฯลฯ คุณสมบัติบางอย่างไม่สามารถตั้งค่าได้บางส่วนสามารถคำนวณได้

ในขณะเดียวกันวิธีการคือการกระทำ GetColor ควรเป็นคุณสมบัติ GetFile () ควรเป็นฟังก์ชัน กฎง่ายๆอีกประการหนึ่งคือถ้ามันไม่เปลี่ยนสถานะของวัตถุก็ควรเป็นฟังก์ชัน ตัวอย่างเช่น CalculatePiToNthDigit (n) ควรเป็นฟังก์ชันเนื่องจากไม่ได้เปลี่ยนสถานะของวัตถุทางคณิตศาสตร์ที่แนบมา

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

คุณสมบัติตามเงื่อนไขคือคุณลักษณะของวัตถุของคุณ วิธีการคือพฤติกรรมของวัตถุของคุณ

ฉลากเป็นแอตทริบิวต์และเหมาะสมกว่าที่จะทำให้เป็นคุณสมบัติ

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

รถ {สีรุ่นยี่ห้อ}

รถมีคุณลักษณะสีรุ่นและยี่ห้อดังนั้นจึงไม่สมเหตุสมผลที่จะมีเมธอด SetColor หรือ SetModel เนื่องจากเราไม่ได้ขอให้ Car กำหนดสีของตัวเอง

ดังนั้นหากคุณแมปเคสคุณสมบัติ / วิธีการกับวัตถุในชีวิตจริงหรือมองจากมุมมองเชิงสัญลักษณ์ความสับสนของคุณจะหายไปจริงๆ

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

ฉันชอบใช้คุณสมบัติสำหรับวิธีการเพิ่ม / ตั้งค่าด้วยพารามิเตอร์1ตัว หากพารามิเตอร์มีมากขึ้นให้ใช้วิธีการ

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

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

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

ใน. Net โลกมีความหมายอื่น ๆ ของการใช้ Properties:

• คุณสมบัติถูกใช้ใน Databinding ในขณะที่ get_ / set_ method ไม่ใช่วิธีการ
  
• คุณสมบัติผู้ใช้การทำให้เป็นอนุกรม XML เป็นกลไกตามธรรมชาติของการทำให้เป็นเซรุ่ม
  
• คุณสมบัติถูกเข้าถึงโดยตัวควบคุมPropertyGridและICustomTypeDescriptorภายในซึ่งสามารถใช้ได้อย่างมีประสิทธิภาพหากคุณกำลังเขียนไลบรารีแบบกำหนดเอง
  
• คุณสมบัติถูกควบคุมโดยแอตทริบิวต์เราสามารถใช้มันอย่างชาญฉลาดในการออกแบบซอฟต์แวร์ Aspect Oriented

ความเข้าใจผิด (IMHO) เกี่ยวกับการใช้งานคุณสมบัติ:

• ใช้เพื่อแสดงการคำนวณขนาดเล็ก: ControlDesigner.SelectionRulesของ get block ทำงานเป็น 72 บรรทัด !!
  
• ใช้เพื่อแสดงโครงสร้างข้อมูลภายในแม้ว่าคุณสมบัติจะไม่ได้แมปกับสมาชิกข้อมูลภายใน แต่ก็สามารถใช้เป็นคุณสมบัติได้หากเป็นแอตทริบิวต์ของคลาสของคุณ Viceversa แม้ว่าจะไม่แนะนำให้ใช้แอตทริบิวต์ของคุณสมบัติคลาสของคุณให้ส่งคืนอาร์เรย์เช่นสมาชิกข้อมูล (ใช้วิธีการแทนเพื่อส่งคืนสำเนาลึกของสมาชิก)

ในตัวอย่างนี้อาจมีการเขียนโดยมีความหมายทางธุรกิจเพิ่มเติมดังนี้

public String Title
{
    set { Label.Text = text; }
}

คุณสมบัติดีมากเพราะสามารถเข้าถึงได้ใน Visual Designer ของ Visual Studio หากพวกเขาสามารถเข้าถึงได้

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

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

ไม่ใช่แค่เรื่องอรรถศาสตร์ การใช้คุณสมบัติที่ไม่เหมาะสมเริ่มมีความแปลกประหลาดเกิดขึ้นใน Visual Studio Visual Designer

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

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

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

• การโทรซ้ำไปยัง setter (ด้วยค่าเดียวกัน) ไม่ควรให้ผลต่างจากการโทรครั้งเดียว

• get ไม่ควรส่งคืนการอ้างอิงไปยังโครงสร้างข้อมูลภายใน (ดูรายการ 23) วิธีการหนึ่งสามารถส่งคืนสำเนาลึกและสามารถหลีกเลี่ยงปัญหานี้ได้

* นำมาจากคำตอบของฉันสำหรับคำถามที่ซ้ำกัน

ง่ายๆแค่นี้เอง

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

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

ฉันมาจาก java an ฉันใช้ get .. set .. วิธีการสักระยะหนึ่ง

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

วันนี้ฉันมีวิธี SetAge (int age) ฉันจะมีวิธี SetAge (วันเดือนปีเกิด) ที่คำนวณอายุโดยใช้วันเกิด

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