Single-Responsibility Principle
A class should have only one reason to change.
คลาสในที่นี้ รวมถึง method หรือ module ด้วยนะ หรือ พูดรวมๆคือโค้ดทุกอย่างนั่นแหละ
เลยทำให้เราแปลออกมาได้ว่า "Class, Method, หรือ Module ต่างๆนั้น ควรจะมีแค่เหตุผลเดียวในการแก้ไข" นี่คือหัวใจของ SRP เลย หรือพูดง่ายๆอีกแบบว่า "ถ้าเราคิดเหตุผลที่จะทำให้เราต้องแก้โค้ดกลุ่มนั้นๆได้มากกว่า 1 เหตุผลแล้วละก็ แสดงว่าผิดกฎของ SRP"
SRP
เป็นหลักออกแบบตัวแรกที่ง่ายที่สุด แต่เป็นตัวที่เข้าใจและทำได้ยากที่สุดตัวนึง เพราะหลักตัวนี้มั นไม่ได้อยู่แค่ที่โค้ด แต่มันลงไปถึงระดับของ คน ซึ่งคนในที่นี้คือคนที่ทำให้เกิด Requirement Change
Requirement
คือสิ่งที่ลูกค้าต้องการ เช่นเวลาเราจะสร้างแอพออกมาซักตัว เราก็ต้องไปทำความเข้าใจก่อนว่าลูกค้าอยากจะได้แอพแบบไหน หรืออยากให้มันทำอะไรได้บ้าง
ถ้าโค้ดที่รับผิดชอบงานนั้นๆ มีเหตุผลที่ทำให้เราต้องไปแก้มากกว่า 1 เหตุผล แสดงว่าโค้ดพวกนั้นมันดูแลงานมากกว่า 1 เรื่อง เมื่อเกิด Requirement Change เราต้องไปแก้โค้ด และถ้าโค้ดนั้นมีเรื่องที่มันดูแลมากกว่า 1 เรื่อง เราจะมั่นใจได้ยังไงว่าเรื่องที่เราแก้จะไม่ไปกระทบกับอีกเรื่องที่มันไม่เกี่ยวข้องด้วย? และ จะมั่นใจได้ยังไงว่าเรื่องทั้ง 2 มันจะไม่ไปผูกกันโดยที่เราไม่ตั้งใจได้?
หลังๆมาพ่อใหญ่ Robert C.Marin ก็พบว่าหลายๆคนอ่านแล้วเข้าใจในนิยามแรกแล้วเข้าใจผิดกันเยอะมาก แกเลยนิยามหลักการนี้เป็นตัวที่ 2 ออกมาว่า
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
ซึ่งแปลออกมาได้ว่า
รวมของที่เกิดจาก requirement เดียวกันไปไว้ด้วยกัน และแยกของที่เกิดจากการเปลี่ยนแปลงจาก requirement อื่นไปรวมไว้ที่อื่น
เลยเป็นเหตุผลว่า นิยามแรกมันไม่ได้จำกัดความเพียงแค่คลาสเท่านั้น และมันต้องออกแบบโดยดูเนื้อหาของ Requirement ด้วย
สมมุติว่าเราเขียนโปรแกรมแล้วมีความต้องการเข้ามาจาก 2 ฝ่ายคือ ความต้องการของฝ่ายการตลาด กับ ความต้องการของฝ่ายบัญชี ซึ่งความต้องการของทั้ง 2 ฝ่ายนี้ในบางทีอาจจะเป็นเรื่องเดียวกันก็ได้ เช่น อยากได้หน้ ารายงานแบบเดียวกันเป๊ะๆทั้ง 2 ฝ่าย เราก็เลยทำหน้ารายงานให้
หน้ารายงานของทั้ง 2 ฝ่ายเราทำเป็นหน้าเดียวกัน เพราะทั้ง 2 ฝ่ายอยากได้แบบเดียวกันเป๊ะๆเลยนิน่า ก็ดูเหมือนจะไม่มีอะไรใช่ไหม แต่พอวันนึงฝ่ายบัญชีอยากให้เพิ่ มคอลัมน์เข้าไปในรายงานหน่อย เขาจะได้ดูผลสรุปได้ง่ายๆ พอเราแก้ให้เสร็จเขาก็ยิ้มสบายใจ แต่อีก 3 วันให้หลังฝ่ายการตลาดหน้ามุ่ยเดินถีบประตูมาหาเราทันที และโวยวายว่าทำไมรายงานมันมีคอลัมน์เพิ่มเข้ามาล่ะ ฝ่ายฉันไม่ได้อยากได้แบบนี้นะ! นี่คือตัวอย่างที่ละเมิดกฎของ SRP
ข้อควรระวัง
จะเห็นว่าเรื่อง SRP มันไม่ได้ลงไปแค่ในระดับโค้ดเท่านั้น แต่มันจะครอบคลุมไปถึงระดับ requirement ด้วย เช่นความต้องการของ Requirement Change จากกลุ่มเดียวกัน ก็ต้องมีโค้ดชุดนึงดูแลรับผิดชอบแยกออกไป
แทนที่เราจะทำหน้ารายงานเป็นหน้าเดียวกัน ให้เราแยกโค้ดและหน้ารายงานที่เหมือนกันเป๊ะๆออกเป็น 2 อัน แล้วพอฝ่ายบัญชีขอแก้ไขการแสดงผลก็จะมีแค่โค้ดที่รับผิดชอบ Requirement change ของฝั่งบัญชีเท่านั้นที่ถูกแก้ไข ไม่มีผลกระทบกับโค้ดที่ดูแล Requirement change ของฝ่ายการตลาด และในทางกลับกันถ้าฝ่ายการตลาดอยากเพิ่มอะไร มันก็จะไม่มีผลกระทบกับฝ่ายบัญชีเช่นกัน
ข้อควรระวัง
อย่าเมากาวเอา SRP ไปใช้แบบตะบี้ตะบัน ไม่งั้นเราจะทำงานออกมาได้ช้ากว่าปรกติ เช่น ในเคสตัวอย่างนี้ถ้าทีมเราไม่มีกำลังคนเหลือจริงๆ การรวมรายงานเป็นหน้าเดียวกันแม้อาจจะทำให้เป็นผลดีกว่าไปเสียเวลาเพิ่มโค้ดก็ได้ (แม้จะผิดหลัก SRP ก็ตาม) ดังนั้นจะใช้ SRP ต้องชั่งน้ำหนักด้วยว่าควระทำถึงระดับไหนและเมื่อไหร่ควรที่จะทำ
เป็นคำเรียกการออกแบบที่ไม่ดี เพราะโค้ดพวกนั้นเปราะบางมาก เราไปแก้ไขมันหน่อยก็พัง มีคนมาเรียกใช้ส่งข้อมูลไปไม่ดีก็พัง ซึ่งเราควรจะหลีกเลี่ยงการออกแบบโค้ดไม่ให้มันเปราะบาง (กาก) แบบนี้ให้มากที่สุด
Code smell
เป็นเทคนิกในการดูว่าโค้ดเรามีปัญหาหรือไม่ และจะหลีกเลี้ยงมันยังไง (ในอนาคตผมจะเขียนบทความเรื่อง code smell ไว้นะครับก็รอติดตามอ่านดูได้ที่สลัดผักนี่แหละ)
Last modified 3yr ago