[Design Pattern] Command Pattern in Depth

อันนี้น่าจะเป็น Pattern ที่ 4 ที่เขียนกันครับ

ทำไมต้องใช้ Command Pattern

• ต้องการเชื่อมของหลายๆสิ่งเข้าด้วยกันได้ เช่น Remote กับเครื่องใช้ไฟฟ้า แต่ละอย่างในบ้าน เช่น หลอดไฟ, พัดลม หรือ ทีวี ที่มีลักษณะการทำงานคล้ายๆกัน เช่น เปิด(ON) หรือป ปิด(OFF) เป็นต้น แต่ไม่อยากให้มันผูกแน่นกันจนเกินไป
• มาดูโจทย์ของเราดึงกว่า โดยผมรับ Requirement มาว่าให้ได้ออกแบบ Application ETradeStock อันนึงที่สามารถส่งคำสั่งไปที่ตลาดหุ้น SAT ซึ่งสำหรับ SAT มี API อยู่ 2 เจ้าครับ ได้แก่ DSC และ FWD
  • สิ่งที่ต้องการ คือ ทำอย่างไรก็ได้ให้ Application ของเรา สามารถส่งคำสั่งซื้อ-ขาย หลักทรัพย์ไปยังตลาดหุ้น SAT โดยที่ใช้ API ของ DSC และ FWD ได้ พร้อมทั้งรองรับการเพิ่ม API ได้ในอนาคตครับ

เมื่อไหร่ควรจะใช้

• ต้องการสร้างสื่อกลางระหว่าง Control (คนสั่ง) กับ Receiver(คนทำตาม) แต่ไม่อยากให้ Controller รู้จักกับ Receiver มากนัก (อารมณ์เหมือนพวกแก๊งมาเฟีย ลูกน้องไม่รู้หรอกว่าใครสั่ง แต่ต้องทำตาม) สิ่งที่ต้องทำ คือ เพิ่มสื่อตรงกลางขั้นมา ซึ่งมัน คือ คำสั่ง (Command)
• ต้องการเชื่อม Controller กับ Receiver แม้ว่าตัว Receiver ของแต่ละค่ายมันมี API เชื่อมต่างกันก็ตาม (ส่วนตัวมองว่าเป็น Special Case ของ Adapter Pattern นะ ตัว Command  == Adapter) เช่น
  • Event ระหว่าง Control ต่างๆ(คนสั่ง กับพวก Handler(คนทำตาม) มี่ Object Event มาเป็น Command
  • การเก็บ Log แม้ว่าจะเป็น Log ต่างๆค่ายกัน ถูกหุ้มด้วย Command แบบเดียวกัน
  • การ Implement ของ CallBack ในภาษากลุ่ม OOP
• จากโจทย์ตัวอย่างของ Application ETradeStock มาแยกดีกว่าว่าแต่ละ Object เป็นอย่างไร
  • Control - ETradeStock
  • Receiver - DSCTradeService, FWDTradeService
  • Command - อันนี้ เป็นสิ่งที่ต้องเพิ่มครับ โดยระละเอียดดูได้จาหัวข้อถัดไปครับ

Pattern มันเป็นอย่างไร - Class Diagram

• Template

• Class Diagram จากโจทยฺ์ - ที่ผมแยกเป็น 2 แบบ เพราะ ถ้า Class Diagram จริงๆ บางทีอาจจะละตัว Invoker ไปเป็น Method ได้ครับ

มุมมองตอน Runtime - Object Diagram

• Control >> Command >> Receiver

มุมมองลำดับการทำงาน - Sequence Diagram

• แบบที่ใส่ตัว Invoker

• แบบที่ไม่แสดงตัว Invoker