Defensive Programming :: ทำไมต้องตรวจสอบค่า NULL ด้วย

ผมเคยเขียน blog อธิบายเรื่อง Defensive Programming ไว้แล้ว หนึ่งในเรื่องที่พูดไว้ก็มีหลายเรื่อง แต่มีเรื่องที่น่าสนใจก็คือ การตรวจสอบค่า NULL เราจะลดจำนวนการตรวจสอบลงได้หรือเปล่านะ ? วันนี้อ่านเจอ blog เรื่อง Why You Shouldn't Check Input Parameters for Validity อธิบายแนวทางหนึ่งของการตรวจสอบข้อมูล โดยนำแนวคิดของ Object-Oriented Programming และ Design Pattern มาใช้งาน ซึ่ง code ตัวอย่างเป็นภาษา Java ดังนั้น จึงทำการสรุปไว้ศึกษาหน่อย

ตัวอย่าง code เป็นระบบการ export file รายงาน

โดยมักจะเขียน code ใน method การ export ดังนี้ [gist id="c45429f2ec73c6ccdc33" file="Report.java"] คำอธิบาย จะเห็นได้ว่าทำการเขียน code ตรวจสอบ 2 เรื่องคือ

1. ตรวจสอบว่า file มันมีค่าเป็น NULL หรือไม่ ?
2. ตรวจสอบว่า มี file อยู่จริง ๆ หรือไม่ ?

สาเหตุที่ต้องทำการตรวจสอบ 2 ครั้ง เนื่องจาก ไม่แน่ใจว่าผู้ใช้งาน method export() นั้น ทำการส่งค่ามาหรือไม่ ? ไม่แน่ใจว่าผู้ใช้งาน method export() นั้น ทำการส่งค่าที่ถูกต้องมาหรือไม่ ? และทำให้เรามั่นใจว่า การทำงานจะไม่พังไป หรือบางครั้งอาจจะก่อให้เกิดปัญหาอย่างร้ายแรงต่อระบบอีกด้วย ซึ่งเป็นการเขียน code แบบ Defensive programming อย่างหนึ่ง ถามว่า มันไม่ดีหรืออย่างไร ? ตอบได้เลยว่า มันก็ดีนะ มันทำงานถูกต้อง แถมอ่านง่าย แถมเข้าใจง่าย

ลองมาคิดใหม่สิว่า ถ้าไม่อยากตรวจสอบค่าของ file เป็น NULL แบบตรง ๆ จะทำอย่างไรดี ?

จากบทความได้แนะนำให้ใช้ Decorator Pattern หรือ Wrapper Pattern โดยนำมาใช้เพื่อทำการตรวจสอบข้อมูลแทนซะเลย ถ้าอธิบายง่าย ๆ คือ การสร้าง wrapper class ขึ้นมานั่นเอง แสดงการทำงานดังรูป ซึ่งสามารถเขียน code ใหม่ได้ดังนี้ [gist id="c45429f2ec73c6ccdc33" file="NewReport.java"] ส่วนการเรียกใช้งาน ก็ทำการเรียกใช้งานแบบ composition โดยเริ่มจาก class NotNullReport หรือ Decorator class นั่นเอง ไม่ต้องมานั่งเขียน code ตรวจสอบกันอีกต่อไป เนื่องจากเราทำการซ่อนการทำงานไว้แล้วนั่นเอง ดังนี้ [gist id="c45429f2ec73c6ccdc33" file="CallReport.java"]

ผลที่ตามมาก็คืออะไรบ้าง ?

ผู้ใช้งาน Report ไม่ต้องมาตรวจสอบข้อมูลแบบยาว ๆ เยอะ ๆ อีกแล้ว จำนวน class เยอะขึ้น ซึ่ง developer หลาย ๆ คนกลัว !! สิ่งที่ได้กลับมาก็คือ ในแต่ละ class นั้นมีขนาดเล็ก ง่ายต่อการดูแลรักษามากขึ้น รวมทั้งเปิดโอกาสให้เราทำการ reuse code ได้ง่ายขึ้น สังเกตุได้จาก class DefaultReport มันคือ class หลักสำหรับขั้นตอน export file ซึ่งมี code เฉพาะการ export file เท่านั้น !! และนี่คืออีกวิธีการหนึ่งในการตรวจสอบข้อมูลที่น่าสนใจ ลองฝึกฝน และ ใช้งานกันดูครับ มันสนุกดีนะ