Topic 7

Topic 7

โค้ด Ruby ใช้ร่วมจากโฟลเดอร์ en/ ของต้นฉบับ เพื่อให้สองภาษาผูกกับชุดทดสอบเดียวกัน

ภาพรวม

ทำไมหัวข้อนี้จึงสำคัญ

หัวข้อนี้คือหนึ่งในจุดที่ชัดที่สุดว่าความเป็น Ruby อยู่ตรงไหน แทนที่จะยึด class hierarchy หรือ interface แบบเป็นทางการ ผู้เรียนจะเริ่มออกแบบจากพฤติกรรมที่แชร์กัน และความคาด หวังเล็ก ๆ ระหว่าง objects

สิ่งที่ผมอยากให้คุณทำได้เมื่อจบหัวข้อนี้

เมื่อจบหัวข้อนี้ คุณควรจะ:

จุดที่ผมใช้ดูความเข้าใจ

ผมอยากให้คุณอธิบายได้ว่าทำไม service จึงพึ่งพาพฤติกรรม ไม่ใช่ exporter class แบบ เฉพาะเจาะจง

โน้ตสั้น

Duck typing คือหนึ่งในไอเดียการออกแบบที่ทรงอิทธิพลที่สุดของ Ruby แทนที่จะถามว่า "object นี้เป็น class อะไร" Ruby มักถามว่า "object นี้ทำสิ่งที่ผมต้องการได้ไหม"

สำหรับคนที่มาจาก Java เรื่องนี้อาจให้ความรู้สึกทั้งโล่งและเสี่ยง เป้าหมายของหัวข้อนี้ ไม่ใช่การปฏิเสธ interfaces แบบไม่ลืมหูลืมตา แต่คือการเห็นว่าเมื่อไร contract ด้าน พฤติกรรมที่เล็กมาก ก็ชัดพอโดยไม่ต้องเพิ่มโครงสร้างเกินจำเป็น

จุดที่ Ruby ทำได้ดีในหัวข้อนี้:

จุดที่ต้องระวังในหัวข้อนี้:

คำถามชวนคิด:

ตัวอย่างแบบลงมือดู

Example 1: Export service

การส่งออกรายงานเดียวกันเป็น CSV, JSON, XML-like markup หรือ payload สำหรับ API ภายนอก เป็นกรณีใช้งาน duck typing ที่สมจริงมาก

ReportService . new ( exporter : CsvExporter . new ). call ( rows ) ReportService . new ( exporter : JsonExporter . new ). call ( rows ) worked_examples.md ruby service นี้ไม่สนใจว่ามันได้รับ exporter class อะไร มันสนใจแค่ว่า object ตอบ export(rows) ได้หรือไม่

Example 2: พฤติกรรม logging ที่ใช้ร่วมกัน

mixins มีประโยชน์เมื่อ service หลายตัวต้องการพฤติกรรมเล็ก ๆ ร่วมกัน แต่ถ้าใช้ inheritance จะพูดความจริงของ domain ผิดไป

เหตุผลที่ตัวอย่างนี้มีประโยชน์:

โพยสั้น