ทำไมต้องใช้ ruby ​​attr_accessor, attr_reader และ attr_writer

Ruby มีวิธีที่สะดวกและสะดวกในการแบ่งปันตัวแปรอินสแตนซ์โดยใช้ปุ่มเช่น

attr_accessor :var
attr_reader :var
attr_writer :var

ทำไมฉันถึงเลือกattr_readerหรือattr_writerถ้าฉันสามารถใช้attr_accessor? มีบางอย่างที่เหมือนกับการแสดง (ซึ่งฉันสงสัย) ฉันคิดว่ามันมีเหตุผลมิฉะนั้นพวกเขาจะไม่ทำกุญแจแบบนั้น

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

class Person
  attr_accessor :age
  ...
end

ที่นี่ฉันเห็นว่าฉันทั้งสองสามารถอ่านและเขียนอายุได้

class Person
  attr_reader :age
  ...
end

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

แต่เกิดอะไรขึ้นเบื้องหลัง?

ถ้าคุณเขียน:

attr_writer :age

ที่ได้รับการแปลเป็น:

def age=(value)
  @age = value
end

ถ้าคุณเขียน:

attr_reader :age

ที่ได้รับการแปลเป็น:

def age
  @age
end

ถ้าคุณเขียน:

attr_accessor :age

ที่ได้รับการแปลเป็น:

def age=(value)
  @age = value
end

def age
  @age
end

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

คำตอบทั้งหมดข้างต้นถูกต้อง attr_readerและattr_writerสะดวกในการเขียนมากกว่าการพิมพ์วิธีที่พวกเขาจดชวเลข นอกเหนือจากนั้นพวกเขายังให้ประสิทธิภาพที่ดีกว่าการเขียนนิยามวิธีการด้วยตัวคุณเอง สำหรับข้อมูลเพิ่มเติมดูสไลด์ 152 เป็นต้นไปจากการพูดคุยนี้ ( PDF ) โดย Aaron Patterson

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

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

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

irb(main):024:0> class A
irb(main):025:1> attr_reader :a
irb(main):026:1> def initialize
irb(main):027:2> @a = {a:1, b:2}
irb(main):028:2> end
irb(main):029:1> end
=> :initialize
irb(main):030:0> a = A.new
=> #<A:0x007ffc5a10fe88 @a={:a=>1, :b=>2}>
irb(main):031:0> a.a
=> {:a=>1, :b=>2}
irb(main):032:0> a.a.delete(:b)
=> 2
irb(main):033:0> a.a
=> {:a=>1}
irb(main):034:0> a.a = {}
NoMethodError: undefined method `a=' for #<A:0x007ffc5a10fe88 @a={:a=>1}>
        from (irb):34
        from /usr/local/bin/irb:11:in `<main>'

อย่างที่คุณเห็นมีความเป็นไปได้ที่จะลบคู่คีย์ / ค่าออกจาก Hash @a เช่นเพิ่มคีย์ใหม่เปลี่ยนค่า eccetera แต่คุณไม่สามารถชี้ไปที่วัตถุใหม่เพราะเป็นตัวแปรอินสแตนซ์แบบอ่านอย่างเดียว

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