ประวัติ ประโยชน์ และโครงสร้างของ Pattern

pattern มาจากไหน

ไอเดียการจดบันทึกวิธีแก้ปัญหาที่เกิดซ้ำ ๆ ไม่ได้เริ่มจากวงการซอฟต์แวร์ แต่มาจากสถาปนิกชื่อ Christopher Alexander ที่รวบรวมรูปแบบการจัดวางซึ่งนำกลับมาใช้ซ้ำได้สำหรับอาคารและเมือง ช่วงกลางทศวรรษ 1990 ผู้เขียนสี่คนที่รู้จักกันในนาม Gang of Four ยืมแนวทางนั้นมาใช้กับซอฟต์แวร์เชิง object แล้วตีพิมพ์แคตตาล็อก pattern ยี่สิบสามแบบ

สิ่งที่พวกเขาทิ้งไว้ให้วงการไม่ใช่ตัว pattern แต่ละตัวเท่าไหร่ แต่เป็นรูปแบบการอธิบาย คือวิธีตั้งชื่อปัญหา อธิบายโครงสร้างที่พิสูจน์มาแล้ว และชั่งน้ำหนักผลที่ตามมา พอนักพัฒนามีคำศัพท์ชุดเดียวกัน บทสนทนาเรื่อง design ก็สั้นลงมาก

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

ประโยชน์

คำศัพท์ร่วมกัน ทีมที่รู้จักแคตตาล็อกสามารถอธิบายการออกแบบที่ไม่ธรรมดาได้ในประโยคเดียว และเชื่อมั่นได้ว่าทุกคนนึกภาพสิ่งเดียวกัน
โครงสร้างที่พิสูจน์แล้ว แต่ละ pattern ผ่านการทดสอบความทนทานมาแล้วในหลายระบบ ดังนั้นคุณจึงได้รับวิธีแก้ปัญหาที่มีการบันทึกข้อพึงระวังไว้แล้วเป็นมรดก
การให้เหตุผลที่เร็วขึ้น พอจับได้ว่า “นี่คือปัญหาแบบ Observer” คุณก็ข้ามขั้นตอนคิดการจัดวางใหม่เอง แล้วกระโดดไปที่การปรับใช้ได้เลย

คำวิจารณ์

pattern ไม่ได้มาฟรี ๆ และการยก pattern ขึ้นเป็นเป้าหมายแทนที่จะเป็นเครื่องมือ ก็สร้างความเสียหายได้จริง

Over-engineering ความล้มเหลวที่พบบ่อยที่สุดคือการเอื้อมไปหยิบ pattern ก่อนที่ปัญหาจะสมเหตุสมผลให้ทำ — ห่อความต้องการบรรทัดเดียวด้วย interface สามอันกับ factory การเพิ่มชั้นทางอ้อมที่คุณไม่ต้องการก็เป็นแค่ต้นทุน
การแก้ขัดแทน feature ที่ภาษาไม่มี pattern คลาสสิกบางตัวมีไว้ปะช่องว่างของภาษาเป็นหลัก เช่น พอภาษามี first-class function แล้ว “behavioral” pattern หลายตัวก็หดเหลือแค่ callback ตัวเดียว
Cargo-culting การหยิบ pattern มาใช้เพราะดูดีมีระดับ ไม่ใช่เพราะแรงผลักดันตรงกัน สุดท้ายได้แค่พิธีกรรมที่ไม่มีประโยชน์

โครงสร้างของ pattern

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

flowchart LR
  I[Intent] --> Pr[Problem]
  Pr --> St[Structure]
  St --> Co[Consequences]
  Co --> D{Does it fit?}

field ที่ใช้อธิบายทุก pattern อ่านไล่จากบนลงล่าง

Intent — ประโยคเดียวที่บอกว่า pattern ทำอะไรให้สำเร็จ
Problem — สถานการณ์ที่เกิดซ้ำ ๆ พร้อมแรงผลักดันที่ขัดกันเอง (ความยืดหยุ่น, coupling, ประสิทธิภาพ) ซึ่งทำให้สถานการณ์นั้นแก้ยาก
Structure — บทบาทที่เข้าร่วมและความสัมพันธ์ระหว่างกัน มักวาดเป็น UML class diagram
Consequences — สิ่งที่คุณได้และสิ่งที่คุณจ่าย: ข้อแลกเปลี่ยนที่ตัดสินว่า pattern นั้นคุ้มค่าหรือไม่ในกรณีนี้

เมื่อไรควรเอื้อมไปหยิบมา

หยิบ pattern มาใช้ตอนที่คุณเจ็บกับปัญหาที่ชัดเจนและเกิดซ้ำ — ตรรกะการสร้างที่เขียนซ้ำหลายที่ บันได if/switch ที่แข็งทื่อผูกกับ type หรือ class ที่รู้เรื่องภายในของอีก class มากเกินไป ความเจ็บมาก่อนเสมอ แล้ว pattern ค่อยตามมาเป็นคำตอบ

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