คำถามติดแท็ก properties

ใน C # รหัสต่อไปนี้ถูกต้อง interface I{ int property{get;set;} } ซึ่งไม่สมเหตุสมผลเลยสำหรับฉัน สิ่งนี้ดูเหมือนจะทำลายหนึ่งในหลักการที่สำคัญที่สุดของอินเทอร์เฟซ: ขาดสถานะ (กล่าวอีกนัยหนึ่งไม่มีฟิลด์) สถานที่ให้บริการไม่ได้สร้างเขตข้อมูลส่วนตัวโดยนัย? นั่นจะไม่เลวสำหรับอินเทอร์เฟซหรือไม่

47 c#  interfaces  properties 

ฉันมีชั้นเรียนสองreadonly intสาขา พวกเขาถูกเปิดเผยเป็นคุณสมบัติ: public class Thing { private readonly int _foo, _bar; /// <summary> I AM IMMUTABLE. </summary> public Thing(int foo, int bar) { _foo = foo; _bar = bar; } public int Foo { get { return _foo; } set { } } public int Bar { get { …

25 c#  object-oriented  immutability  properties 

ตัวอย่างเช่นคลาสที่ชอบ: class Dog { } //never mind that there's nothing in it... แล้วคุณสมบัติเช่น: Dog Dog { get; set; } ฉันได้รับแจ้งว่าถ้าฉันไม่สามารถสร้างชื่อที่จินตนาการได้มากกว่านี้ฉันต้องใช้: Dog DogObject { get; set; } มีความคิดเกี่ยวกับวิธีตั้งชื่อให้ดีกว่านี้อย่างไร?

25 c#  naming  properties 

ลองนึกภาพระบบที่มีเซิร์ฟเวอร์จำนวนมาก แต่ละรายการมีการตั้งค่าจำนวนมาก: บางอย่างเฉพาะกับเซิร์ฟเวอร์ เฉพาะบางภูมิภาค บางคนพบเห็นได้ทั่วทุกคน บางทีคุณอาจมีการจัดกลุ่มแบบกำหนดเองบางอย่างเช่นกลุ่มเซิร์ฟเวอร์นี้มีไว้สำหรับอ่านเท่านั้น เป็นต้น การปฏิบัติปัจจุบันที่ฉันมีอยู่ในใจเป็นโครงสร้างที่เรียบง่ายพร้อมความสามารถที่เหนือกว่า ให้ใช้เซิร์ฟเวอร์ของ Google เพื่อเป็นตัวอย่าง แต่ละรายการมีรายการการตั้งค่าที่จะโหลด ตัวอย่างเช่นเซิร์ฟเวอร์ลอนดอนอาจมี: rootsettings.properties, europesettings.properties, londonsettings.properties, searchengine.propertiesฯลฯ ที่แต่ละไฟล์มีชุดของคุณสมบัติและลำดับการโหลดช่วยให้คุณสามารถแทนที่คุณสมบัติได้ยิ่งคุณไปได้ไกลเท่าไหร่ ตัวอย่างเช่น: rootsettings.propertiesอาจมีaccessible=falseค่าเริ่มต้น แต่อยู่เหนือsearchengine.propertiesด้วยaccessible=true ปัญหาที่ฉันมีกับโครงสร้างนี้คือมันง่ายมากที่จะออกจากการควบคุม มันไม่ได้มีโครงสร้างเลยหมายความว่าคุณสามารถกำหนดคุณสมบัติใด ๆ ได้ทุกระดับและหลายรายการอาจล้าสมัย นอกจากนี้การเปลี่ยนระดับกลางจะเป็นไปไม่ได้เมื่อเครือข่ายโตขึ้นเนื่องจากตอนนี้คุณส่งผลกระทบต่อเซิร์ฟเวอร์จำนวนมาก ท้ายสุด แต่ไม่ท้ายสุดแต่ละอินสแตนซ์แต่ละรายการอาจต้องการคุณสมบัติพิเศษ 1 รายการซึ่งหมายความว่าแผนผังของคุณจะจบลงด้วยการกำหนดค่าสำหรับเซิร์ฟเวอร์แต่ละเครื่องอย่างไรก็ตามมันจึงไม่ใช่โซลูชันที่ดีที่สุด ฉันจะขอขอบคุณอย่างมากหากคุณมีข้อเสนอแนะ / แนวคิดเกี่ยวกับสถาปัตยกรรมการจัดการการกำหนดค่าที่ดีขึ้น

15 configuration  configuration-management  properties 

ฉันมีคลาส C # ที่แสดงประเภทเนื้อหาในระบบการจัดการเนื้อหาเว็บ เรามีฟิลด์ที่อนุญาตให้แก้ไขเนื้อหาเว็บเพื่อป้อนเทมเพลต HTML สำหรับวิธีการแสดงวัตถุ โดยพื้นฐานแล้วมันใช้ไวยากรณ์แฮนด์บาร์สำหรับการแทนที่ค่าคุณสมบัติวัตถุลงในสตริง HTML: <h1>{{Title}}</h1><p>{{Message}}</p> จากมุมมองการออกแบบคลาสฉันควรแสดงสตริง HTML ที่จัดรูปแบบ (พร้อมการแทนที่) เป็นคุณสมบัติหรือวิธีการหรือไม่ ตัวอย่างเช่นคุณสมบัติ: public class Example { private string _template; public string Title { get; set; } public string Message { get; set; } public string Html { get { return this.ToHtml(); } protected set { } …

13 c#  design-patterns  class-design  methods  properties 

ฉันมีปัญหาการออกแบบเกี่ยวกับคุณสมบัติ. NET interface IX { Guid Id { get; } bool IsInvalidated { get; } void Invalidate(); } ปัญหา: อินเตอร์เฟซนี้มีสองคุณสมบัติอ่านอย่างเดียวและId IsInvalidatedอย่างไรก็ตามความจริงที่ว่าพวกเขาเป็นแบบอ่านอย่างเดียวไม่สามารถรับประกันได้ว่าค่าของพวกเขาจะคงที่ สมมติว่ามันเป็นความตั้งใจของฉันที่จะทำให้ชัดเจนว่า ... Id แทนค่าคงที่ (ซึ่งอาจถูกแคชอย่างปลอดภัย) ในขณะที่ IsInvalidatedอาจเปลี่ยนค่าในช่วงอายุของIXวัตถุ (และไม่ควรแคช) ฉันจะปรับเปลี่ยนinterface IXเพื่อให้สัญญานั้นชัดเจนเพียงพอได้อย่างไร ความพยายามสามข้อของฉันในการแก้ปัญหา: อินเตอร์เฟสได้รับการออกแบบมาอย่างดี การปรากฏตัวของวิธีการที่เรียกว่าInvalidate()ช่วยให้โปรแกรมเมอร์ที่จะอนุมานว่ามูลค่าของทรัพย์สินที่มีชื่อคล้ายกันIsInvalidatedอาจได้รับผลกระทบจากมัน อาร์กิวเมนต์นี้มีไว้เฉพาะในกรณีที่เมธอดและคุณสมบัติมีชื่อคล้ายกัน เพิ่มส่วนต่อประสานนี้กับกิจกรรมIsInvalidatedChanged: bool IsInvalidated { get; } event EventHandler IsInvalidatedChanged; สถานะของ…Changedเหตุการณ์สำหรับIsInvalidatedสถานะที่คุณสมบัตินี้อาจเปลี่ยนค่าและการไม่มีเหตุการณ์ที่คล้ายกันสำหรับIdเป็นสัญญาว่าคุณสมบัตินั้นจะไม่เปลี่ยนค่าของมัน ฉันชอบโซลูชันนี้ แต่มีสิ่งเพิ่มเติมมากมายที่อาจไม่ได้ใช้เลย แทนที่คุณสมบัติIsInvalidatedด้วยเมธอดIsInvalidated(): bool IsInvalidated(); …

12 c#  design  .net  properties 

ฉันมาจากพื้นหลัง C ++ และหมดทุกอย่าง C # ในงานปัจจุบันของฉันและฉันเพิ่งอ่านคำถามมากมายเกี่ยวกับความแตกต่างระหว่างฟิลด์สาธารณะและคุณสมบัติและสิ่งที่แตกต่างและกลับมาในรูปแบบนี้ คำถามพื้นฐาน (เช่นโพสต์ SO นี้และคำถามที่เชื่อมโยงทั้งหมดที่เกี่ยวข้อง) คำถามทั้งหมดเหล่านี้ได้รับการแก้ไขในแง่ของความแตกต่างในทางปฏิบัติที่ได้รับการมีอยู่ของระบบทรัพย์สิน แต่ฉันคิดว่ามันเป็นการดีที่จะเข้าใกล้เรื่องนี้ในแง่ของสิ่งที่นักออกแบบของทุกภาษาที่ตัดสินใจสนับสนุนคุณสมบัติในครั้งแรก สถานที่กำลังคิด (ตรวจสอบรายชื่อในบทความ Wikipedia ที่นี่) OOP วิวัฒนาการมาจาก C ++ / Java เพื่อขยายสู่บทความ Wikipedia ที่น่าสนใจว่าเป็นตัวกลางระหว่างวิธีการและข้อมูลสมาชิกอย่างไร "นั่นคือคุณสมบัติจะอยู่ตรงกลางระหว่างรหัสสมาชิก (วิธีการ) และข้อมูลสมาชิก (ตัวแปรอินสแตนซ์) ของคลาสและคุณสมบัติให้ระดับการห่อหุ้มที่สูงกว่าเขตข้อมูลสาธารณะ" MSDNเพิ่มพื้นหลังเพิ่มเติม: "แม้ว่าคุณสมบัติจะคล้ายกันกับวิธีการทางเทคนิค แต่ก็แตกต่างกันมากในแง่ของสถานการณ์การใช้งานพวกเขาควรมองว่าเป็นสมาร์ทฟิลด์พวกเขามีการเรียกไวยากรณ์ของฟิลด์และความยืดหยุ่นของเมธอด" ฉันอยากจะรู้ว่ามันมาถึงแล้วในระดับปานกลางของการห่อหุ้มที่พิสูจน์แล้วว่ามีประโยชน์สำหรับการเขียนโปรแกรมโดยทั่วไป ฉันสมมติว่าแนวคิดนี้ไม่ได้เกิดขึ้นในการเขียนโปรแกรมภาษาแรกที่แสดงกระบวนทัศน์ OOP

12 object-oriented  programming-languages  properties 

เมื่อดูเมตาดาต้าของกล้องบางตัวบน Windows File Propertiesจะมี (พร้อมกับอีกสองสาม) Propertiesชื่อความยาวโฟกัสและความยาวโฟกัส 35 มม . ฉันกำลังพัฒนาซอฟต์แวร์ที่จะใช้ประโยชน์จากสองสิ่งPropertiesนี้ จนถึงตอนนี้ฉันได้สร้างPropertyชื่อFocalLengthสำหรับชื่อแรก แต่ฉันไม่สามารถหาชื่อที่เหมาะสมสำหรับชื่ออื่นได้ ฉันคิด_35MmFocalLengthหรือThirtyFiveMmFocalLengthแต่ฉันคิดว่าอาจมีข้อเสนอแนะที่ดีกว่า ความคิดใด ๆ

10 c#  naming-standards  properties 

JavaFX ได้จัดทำวัตถุออบเจ็กต์ใหม่จำนวนมากเช่นjavafx.beans.property.DoublePropertyที่อนุญาตให้คุณกำหนดฟิลด์ที่สามารถสังเกตและซิงโครไนซ์ได้โดยอัตโนมัติ ในตัวอย่าง JFX หลายรุ่นคลาส MVC มีจำนวนฟิลด์คุณสมบัติเหล่านี้ซึ่งสามารถผูกเข้ากับมุมมองโดยอัตโนมัติ อย่างไรก็ตามสิ่งนี้ดูเหมือนจะเป็นการกระตุ้นให้เราใส่คุณสมบัติ JFX ลงในวัตถุโดเมนของเรา (ถ้าคุณคิดว่าคลาส Model จะเป็นวัตถุโดเมน) ซึ่งทำให้ฉันแยกความกังวลได้ไม่ดี (เช่นการใส่รหัส GUI ในโดเมน ) มีใครเคยเห็นปัญหานี้ได้รับการแก้ไขใน 'ชีวิตจริง' และถ้าเป็นเช่นนั้นมันทำอย่างไร?

10 properties  javafx  domain-objects 

คำแนะนำทั่วไปสำหรับ C # คือการใช้คุณสมบัติเหนือเขตข้อมูลสาธารณะเสมอ สิ่งนี้สมเหตุสมผลโดยการเปิดเผยฟิลด์คุณจะเปิดเผยรายละเอียดการใช้งานมากมาย ด้วยคุณสมบัติคุณสามารถสรุปรายละเอียดดังกล่าวได้ดังนั้นจึงซ่อนตัวจากการใช้งานรหัสและการเปลี่ยนแปลงการใช้งานจะแยกออกจากการเปลี่ยนแปลงส่วนต่อประสาน อย่างไรก็ตามฉันสงสัยว่าบางครั้งมีข้อยกเว้นที่ถูกต้องสำหรับกฎนี้เมื่อจัดการกับreadonlyคำหลัก โดยการใช้คำหลักนี้กับเขตข้อมูลสาธารณะคุณจะรับประกันเพิ่มเติม: immutability นี่ไม่ได้เป็นเพียงรายละเอียดการนำไปปฏิบัติความไม่เปลี่ยนแปลงเป็นสิ่งที่ผู้บริโภคอาจสนใจการใช้readonlyเขตข้อมูลทำให้เป็นส่วนหนึ่งของสัญญาสาธารณะและสิ่งที่ไม่สามารถทำลายได้โดยการเปลี่ยนแปลงในอนาคตหรือการสืบทอดโดยไม่ต้องปรับเปลี่ยนส่วนต่อสาธารณะ นั่นคือสิ่งที่ทรัพย์สินไม่สามารถให้ได้ ดังนั้นการรับประกันการเปลี่ยนแปลงไม่ได้จึงเป็นเหตุผลที่ถูกกฎหมายในการเลือกreadonlyเขตข้อมูลเหนือทรัพย์สินในบางกรณี? (เพื่อความกระจ่างฉันไม่ได้พูดอย่างแน่นอนว่าคุณควรเลือกตัวเลือกนี้เสมอเพราะสนามไม่สามารถเปลี่ยนแปลงได้ในขณะนี้เฉพาะเมื่อมันมีความเหมาะสมในการเป็นส่วนหนึ่งของการออกแบบของชั้นเรียน ฉันส่วนใหญ่สนใจคำตอบที่เพ่งความสนใจไปที่ว่านี่อาจเป็นเหตุผลมากกว่ากรณีเฉพาะที่ไม่เช่นเมื่อคุณต้องการสมาชิกที่อยู่ในinterfaceหรือต้องการโหลดขี้เกียจ)

10 c#  immutability  properties 

หลังจากอ่านบทความชื่อ"รหัสบัญญัติ: วิธีปฏิบัติที่ดีที่สุดสำหรับการเข้ารหัส Objective-C" โดย Robert McNallyน้อยกว่าสองปีที่ผ่านมาเล็กน้อยฉันยอมรับการฝึกใช้คุณสมบัติสำหรับสมาชิกข้อมูลทุกคนในคลาส Objective-C ของฉัน ( บัญญัติที่ 3 ณ เดือนพฤษภาคม 2012) McNally แสดงเหตุผลเหล่านี้ในการทำเช่นนั้น (สิ่งที่ฉันให้ความสำคัญ): คุณสมบัติบังคับใช้ข้อ จำกัด การเข้าถึง (เช่นอ่านได้อย่างเดียว) คุณสมบัติบังคับใช้นโยบายการจัดการหน่วยความจำ (แข็งแรงอ่อนแอ) คุณสมบัติให้โอกาสในการใช้ setters และ getters แบบกำหนดเองอย่างโปร่งใส คุณสมบัติที่มี setters หรือ getters แบบกำหนดเองสามารถใช้เพื่อบังคับใช้กลยุทธ์ความปลอดภัยของเธรด การมีวิธีการเข้าถึงตัวแปรอินสแตนซ์เดียวช่วยเพิ่มความสามารถในการอ่านรหัส ฉันใส่คุณสมบัติส่วนใหญ่ของฉันในหมวดหมู่ส่วนตัวดังนั้นหมายเลข 1 และ 4 มักจะไม่ใช่ปัญหาที่ฉันเรียกใช้ ข้อโต้แย้งที่ 3 และ 5 นั้นนุ่มนวลกว่าและด้วยเครื่องมือที่เหมาะสมและความสอดคล้องอื่น ๆ พวกเขาอาจกลายเป็นไม่ใช่ประเด็นปัญหา ในที่สุดสำหรับฉันข้อโต้แย้งที่มีอิทธิพลมากที่สุดคือหมายเลข 2 การจัดการหน่วยความจำ ฉันทำสิ่งนี้มานับ …

9 programming-practices  objective-c  properties