/ OOD

[365 วันแห่งโปรแกรม #day49] Design Pattern

วันที่สี่สิบเก้าของ ‪#‎365วันแห่งโปรแกรม ได้เวลาขึ้นเรื่องใหม่กันแล้วครับ เรื่องที่เราจะพูดถึงในวันนี้ก็คือ Design Pattern


Design Pattern

Design Pattern คือ reusable solution สำหรับแก้ปัญหาที่เกิดขึ้นบ่อยครั้งในขั้นตอนของ software design โดย Design Pattern นั้นถูกนำเสนอในรูปของแนวทางการรับมือกับปัญหาต่างๆ ไม่ใช่ implementation ของวิธีแก้ปัญหาดังนั้นเราต้องเรียนรู้ที่จะประยุกต์ใช้ Design Pattern นั้นๆ เอง

ทำไมต้องมี Design Pattern

เวลาออกแบบซอฟต์แวร์นั้นเราก็จะเจอปัญหาต่างๆ มากมาย ถ้าเราไม่รู้จัก Design Pattern เลย เราก็จะแก้ไม่ถูก แล้วก็ต้องเสียเวลากับปัญหาแต่ละอย่างนานมาก ในอุดมคติแล้วการออกแบบซอฟต์แวร์ต้องไม่มีปัญหาเชิงเทคนิคเลย แต่ที่มันมีก็เพราะภาษาโปรแกรมหรือ tools ที่ใช้มันยังไม่ดีพอ ถ้าภาษาโปรแกรมหรือ tools มีฟีเจอร์ที่ใช้รับมือกับปัญหาครบถ้วนเราก็คงไม่ต้องเรียนรู้ Pattern อะไรเลย

ข้อดีของการนำ Design Pattern ไปใช้

  • Design Pattern เป็น solution ที่ถูกพิสูจน์มาแล้วว่าสามารถนำไปแก้ปัญหานั้นๆ ได้จริง โดย Pattern เหล่านี้ถูกสร้างมาจากประสบการณ์ของโปรแกรมเมอร์จริงๆ ไม่ใช่นั่งเทียนเขียนขึ้น

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

  • Design Pattern นั้นขัดเจน เมื่อเราลองศึกษา Design Pattern ดูสักอัน จะพบว่ามันจะโครงสร้างหรือรูปแบบที่จะช่วยเราในการแก้ปัญหาต่างๆ ที่ชัดเจน ต่างจากพวก principle ที่ทำให้สับสนอยู่บ่อยๆ

อย่างไรก็ตามเราต้องไม่ลืมว่า Design Pattern ไม่าใช่ solution จริงๆ แต่เป็นแค่แนวทางเท่านั้น และ Pattern ไม่ใช่ทางออกของปัญหาทั้งหมด เราไม่สามารถเอามาแทนตำแหน่งนักออกแบบซอฟต์แวร์ได้

Design Pattern ไม่ดีอย่างไร?

มีคนกล่าวไว้ว่า Design Pattern นั้นเป็น technical debt (หนี้เชิงเทคนิค) จริงๆ ผมว่าควรแปลว่าภาระเชิงเทคนิคมากกว่า ก็อย่างที่บอกครับว่าเรามี Design Pattern ใช้เพราะภาษาโปรแกรมหรือ tools มันไม่ดีพอ และตัว Design Pattern ที่เข้ามาช่วยตรงนี้ก็ดันเป็นแค่คอนเซ็ปต์ของการแก้ปัญหาเท่านั้น ทำให้การที่จะเอามาใช้นั้นต้อง implement อะไรเพิ่มเติม ซึ่งตรงนี้แหละครับที่ผมบอกว่าเป็นภาระ ในอนาคตถ้าเราจะแก้อะไรหรือทำอะไรกับคลาสนี้ เราก็ต้องคำนึงถึงสิ่งที่ implement ไป พอโปรแกรมของเราใหญ่ขึ้นไปเรื่อยๆ ภาระเหล่านี้ก็จะเพิ่มขึ้นไปอีก (เหมือนเป็นดอกเบี้ย)

ในภาษาโปรแกรมสมัยใหม่มีความพยายามที่จะแก้เรื่อง technical debt ที่ว่านี้โดยการ implement Design Pattern เข้าไปในภาษาเลย โดยผ่านทาง annotation, keyword หรืออื่นๆ เช่น ใน singleton pattern ที่เราเรียนไปแล้ว ถ้าเราเขียนด้วยจาวา ก็ต้องกำหนด constructor เป็น private สร้างตัวแปร static และสร้าง method getInstance() ซึ่งยุ่งยากมากมาย แต่ในภาษาอย่าง Groovy กลับมี annotation @Singleton ให้ใช้เลย (ความจริงในจาวาก็รองรับ annotation แล้ว แต่อาจจะมีอะไรให้ใช้น้อย) ซึ่งความแตกต่างตรงนี้ทำให้ภาระของโปรแกรมเมอร์ลดลงไปมหาศาล

ประเภทของ Design Patterns

เราสามารถแบ่งกลุ่มของ Pattern ออกตามวัตถุประสงค์การใช้งานได้ดังนี้

  • Creational Patterns กลุ่มของ Pattern ที่ใช้ในการแก้ปัญหาเกี่ยวกับการสร้าง object

  • Structural Patterns กลุ่มของ Pattern ที่ใช้ในการแก้ปัญหาเกี่ยวกับความสัมพันธ์ระหว่างคลาส

  • Behavioral Patterns กลุ่มของ Pattern ที่ใช้ในการแก้ปัญหาเกี่ยวกับพฤติกรรมของ object และปฏิสัมพันธ์ระหว่าง object

  • Concurrency patterns กลุ่มของ Pattern ที่ใช้ในการแก้ปัญหาเกี่ยวกับ multi-threaded programming

Singleton Pattern ที่เราได้คุยกัะนไปเมื่อนานมาแล้วนั้นจัดอยู่ในกลุ่มของ Creational Patterns เพราะเกี่ยวข้องกับ life cycle ของ object ในบทความต่อๆ ไปเราจะเริ่มคุยกันเกี่ยวกับ Pattern ที่สำคัญๆ ครับ

References

Learning JavaScript Design Patterns

Design Patterns และความกากของภาษาโปรแกรม

แนะนำ Design Pattern [GoF]

Design Patterns คืออะไร ทำไมต้องใช้

Design Pattern คือ ปัญหา หรือ วิธีการแก้ปัญหา

Software design pattern

#‎day49 #365วันแห่งโปรแกรม ‪#‎โครงการ365วันแห่ง‬...