ความสำคัญของ Data Object ต่อ การลด dependency ของ Source Code
สวัสดีครับ,
ห่างหายกันไปนานอีกแล้วนะครับ
ยุ่งเหมือนเคยครับ เพราะทำบริษัทใหม่
แต่วันนี้ ก็มีเหตุ เพราะไล่ legacy code
แล้วมีเรื่องน่าสนใจอยู่ 1 อย่างเลยเอามาเล่าให้ฟัง
.
จริงๆ เราอาจจะเคยได้ยินคำว่า Data Object กันมาบ้าง
ถ้าเป็น Programmer ยุค 90 ก็จะรู้จักตัวนี้ดี
Data Access Object (DAO) กับ Data Object (DO)
เป็นตัวที่ popular มากช่วงนั้น
.
.
รูปที่หาได้เพราะขี้เกียจวาด ก็จะเป็นรูปประมาณนี้
จริงๆ Data Object (ในรูปเรียก Transfer Object)
มันก็คือตัวแทน fields ใน Database นั่นแหละ
หรือพูดง่ายๆว่า map Database row มาเป็น Object ใน Object-Oriented
ตาม concept ของ O-R Mapping (Object-Relation Mapping)
.
แต่เราไม่ได้ท้าวความกันตรงนั้น และไม่ได้ให้ความสนใจเท่าไหร่หรอก
แค่ให้รู้ว่า Data Object เป็น “ตัวอม” Data ซึ่งเราต้องการ
.
แล้ว Data Object มันสัมพันธ์กับการลด Dependency ของ Source Code ยังไง?
สมมุติ เรามี Data จาก API อยู่ชุดนึงที่อยากหยิบมาแสดง
คือเรามี Product หลายๆตัว แต่ละตัวมี
ราคาต่อหน่วย (Price) และปริมาณ (Quantity)
เราก็สามารถหยิบ ไปเป็น list แล้วแสดงได้เลย
ซึ่งเราก็จะมี Data Object อยู่ 1 ตัวใน Code ฝั่ง View เรา
อาจจะชื่อ Data Object ตัวนั้นว่า Product[]
.
หน้าตา View อาจจะเป็นแบบนี้ (คิดว่าเป็นโปรแกรมออกใบแจ้งหนี้)
.
ถ้าทำแบบนี้ ชีวิตเราก็ง่าย เพราะ Logic การคุณ Price x Quantity ทำได้ในหน้า View
และเราก็สามารถปั่นจอนี้ออกมาได้ “เร็วส์”
โดยเรามี Data Object แค่ตัวเดียวคือ Product[]
.
เวลาทำ ปุ่มConfirm เราสามารถ reuse Data Object เดิมชื่อ Product[]
นำ Data กลับไป Update หลังบ้านได้เลย
.
แต่…
โปรแกรมเราจะเริ่มพังทันที ถ้าาาาาา……
วันนึง Requirement ดังมาเป็นแบบนี้
พอเรามีช่องให้ User Input Discount ขึ้นมา
เพื่อลดราคาแล้ว confirm กลับหลังบ้าน
ซึ่งทำให้เราไม่สามารถ reuse Data Object Product[] ตัวเดิมของเราได้
เพราะมันมี field discount เพิ่มมาอีก field
.
ตอนนี้เราอยู่บนทาง 2 แพร่งแล้วครับ เราจะเลือกทาง A คือ
Modify Data Object ตัวเดิมของเราที่ชื่อ Product[]
ให้มี field เพิ่มเป็น discount แล้วโยนกลับไปกลับมาใน flow
(ขาส่งมาจาก API ก็ให้ discount เป็น 0 ตลอด)
.
หรือ ทาง B คือ
.
เราคิดว่าทาง A หรือทาง B จะ Maintain Code
เพื่อรองรับ Requirement ได้มากกว่าครับ?
.
แน่นอนครับว่าต้องเป็นทาง B แต่….
Maintainability แปรผกผัน (trade-off) กับ Performance เสมอๆ
ดังนั้นถ้าเราอยากให้โปรแกรมมันมี Preformance ดี เราก็จะเลือกทาง A
แต่ถ้าเราจะทำเพื่อรองรับ change ในอนาคตเราก็จะเลือกทาง B
.
ซึ่งทาง B นี้ใช้เทคนิคว่า Data Object ของเรามีหลายตัว
และแต่ละตัว map ไป-มา หากันได้
เช่น ใน Constructor ของ ReviewedProduct ก็สามารถรับ InquiryProduct ได้
และทำให้ InquiryProduct ที่ต้องเปลี่ยนตาม API ของหลังบ้านนั้น
เป็นอิสระจาก ReviewedProduct ที่ต้องเกิด Action ขึ้นหลัง User ทำ interact กับจอแล้ว เช่น confirm หรือใส่ discount และกด confirm
.
ดังนั้นการแยก Data Object ออกจากกันให้ดี
ทำให้ Software เรา maintain เพื่อรองรับ Requirement ในอนาคตได้มากขึ้นครับ
.
