บทที่ 5: Bend, or Break — โค้งงอแทนที่จะหัก

ภาพรวม

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

---

Topic 28: Decoupling — การลด coupling

Tip 44: Decoupled Code Is Easier to Change — โค้ดที่ decoupled เปลี่ยนแปลงง่ายกว่า
Tip 45: Tell, Don't Ask — บอก อย่าถาม
Tip 46: Don't Chain Method Calls — อย่าต่อ method calls เป็นลูกโซ่
Tip 47: Avoid Global Data — หลีกเลี่ยง global data

Law of Demeter (LoD): method ของ object ควรเรียกใช้ method ของ:

• ตัวมันเอง
• parameters ที่ส่งเข้ามา
• objects ที่มันสร้างขึ้น
• component objects โดยตรง

ห้าม: เรียก method ของ object ที่ได้มาจากการเรียก method อื่น — แบบ a.b.c.d() — เพราะ chain แบบนี้ทำให้ทุกอย่าง coupled กันหมด

Global Data ร้ายกาจ: global data สร้าง coupling ที่มองไม่เห็นระหว่าง components — ทุกส่วนของโค้ดสามารถอ่าน/เขียนได้ ทำให้ตามหาจุดที่เปลี่ยนค่าได้ยาก และ testing แทบเป็นไปไม่ได้ ถ้าจำเป็นต้องใช้ — wrap ด้วย API

---

Topic 29: Juggling the Real World — การจัดการโลกความจริง

Tip 48: Events Are Messages — Events คือข้อความ

โลกเป็น asynchronous — เราไม่สามารถบังคับให้ทุกอย่างเกิดตามลำดับได้ สี่กลยุทธ์ในการจัดการ events:

1. Finite State Machines: ระบบอยู่ใน state เดียวตลอดเวลา — events ทำให้เกิดการเปลี่ยน state
2. The Observer Pattern: source of events (observable) ส่ง events ไปยัง list ของ listeners (observers) ที่ลงทะเบียนไว้ — ข้อเสียคือ coupling เพราะ observable ต้องรู้จัก observers
3. Publish/Subscribe (Pub/Sub): ลด coupling — publishers และ subscribers ไม่รู้จักกัน — ทุกคนเชื่อมต่อผ่าน channel — ข้อเสียคือตามหาว่าเกิดอะไรขึ้นในระบบยาก
4. Reactive Programming และ Streams: จัดการ events แบบ declarative — values เปลี่ยนแปลงตามเวลา — เหมาะกับ UI, external data sources, และ distributed systems

---

Topic 30: Transforming Programming — การเขียนโปรแกรมแบบแปลงสภาพ

Tip 49: Programming Is About Code, But Programs Are About Data — โค้ดคือเครื่องมือ แต่โปรแกรมคือข้อมูล
Tip 50: Don't Hoard State; Pass It Around — อย่ากักตุน state — ส่งมันต่อไป

คิดถึงโปรแกรมเป็นการไหลของข้อมูลผ่านการแปลงสภาพ (transformations) — แทนที่จะมี objects คุยกันไปมาเปลี่ยน state กันและกัน (ซึ่งสร้าง coupling) ให้นึกถึง:

data → transform → data → transform → data → ...

Pipeline operator (|>): ทำให้ chain ของ transformation อ่านง่ายราวกับเป็นภาษามนุษย์ — แต่ละ |> คือจุดที่ข้อมูลไหลจาก transformation หนึ่งไปสู่อีกอัน

Error handling ใน pipelines: ใช้ wrapper type (เช่น :ok/:error tuple ใน Elixir หรือ Maybe/Option ใน Haskell/F#) — เมื่อเกิด error, pipeline จะ short-circuit และส่ง error ต่อไปโดยไม่ execute ขั้นตอนที่เหลือ

การคิดแบบ transformational ลด coupling ได้มาก — function สามารถใช้ซ้ำได้ทุกที่ที่ parameters ของมันตรงกับ output ของ function ก่อนหน้า

---

Topic 31: Inheritance Tax — ภาษีมรดก

Tip 51: Don't Pay Inheritance Tax — อย่าจ่ายภาษีมรดก
Tip 52: Prefer Interfaces to Express Polymorphism — ใช้ interfaces แทน inheritance เพื่อ polymorphism
Tip 53: Delegate to Services: Has-A Trumps Is-A — ใช้ delegation แทน inheritance
Tip 54: Use Mixins to Share Functionality — ใช้ mixins เพื่อแชร์ฟังก์ชัน

Inheritance คือ coupling — เมื่อ parent class เปลี่ยน (แม้แต่ชื่อ instance variable) — child class ก็พัง และโค้ดที่ใช้ child class ก็พังตาม

สามทางเลือกแทน inheritance:

"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." — Joe Armstrong

---

Topic 32: Configuration — การตั้งค่า

Tip 55: Parameterize Your App Using External Configuration

ทำให้แอปพลิเคชันปรับตัวเข้ากับสภาพแวดล้อมที่มันทำงาน — โดยเก็บค่าที่อาจเปลี่ยนแปลงไว้นอกโค้ด

สิ่งที่ควรเก็บใน configuration:

• Credentials สำหรับ external services
• Logging levels และ destinations
• Port, IP address, machine names
• Environment-specific validation parameters
• Tax rates และ license keys
• Site-specific formatting

ควร wrap configuration ด้วย API — ไม่ใช่ global variable — เพื่อ decouple โค้ดจากรายละเอียดของการเก็บ configuration

Configuration-as-a-Service: ใช้ service API สำหรับ configuration — หลายแอปใช้ร่วมกัน, เปลี่ยนได้ globally, เปลี่ยนได้แบบ dynamic โดยไม่ต้อง restart

ข้อควรระวัง: อย่าทำทุกอย่างเป็น configurable — เคยมีบริษัทที่มี 40,000 configuration variables และกลายเป็น nightmare ในการ maintain