The Single-Responsibility Principle มันคืออะไรกันแน่?
สวัสดีครับ ในบทความนี้จะพาทุกท่านมารู้จักกับ Principle แรกใน SOLID นั่นก็คือ S
The Single-Responsibility Principle
“ Class ควรจะมีเพียงหน้าที่เดียวเท่านั้น ”
อ่านตรงนี้แล้วอาจจะงง Class ควรจะมีเพียงหน้าที่เดียวนี้คือหมายถึงมีแค่ Method เดียวหรอ 555+ (ตอนแรกผมก็คิดแบบนี้) งั้นอ่านข้อความต่อไป
“ มีเพียงเหตุผลเดียวเท่านั้น ที่เราจะต้องเปลี่ยนแปลง Code ใน Class นั้นๆ ”
อ่านตรงนี้อาจจะเข้าใจมากขึ้น แต่มันก็ยังไม่ชัดเจนอยู่ดี ??? ให้มาแต่นิยามใครมันจะเข้าใจหละ งั้นผมขอยกตัวอย่างเป็น Code ก็แล้วกันนะครับ 555+
มาเริ่มกันที่ Class Diagram อันนี้คือ Class Programmer นะครับ จะเห็นได้ว่า Object ของ Class นี้สามารถที่จะ Code (เขียนโปรแกรมได้) แล้วก็ Design UI (ออกแบบ User Interface ได้ด้วย)
เรามาดูในชีวิตจริงกันครับ
ผมเป็น Programmer
var krish = new Programmer()สมมุติผมทำงานอยู่ในบริษัทๆนึง วันนึงบอสในแผนก Software ต้องการให้ผมเขียนโปรแกรม
krish.code()ต่อมา บอสอีกแผนกนึงต้องการให้ผมออกแบบUI ให้กับ Website ใหม่ของบริษัท
krish.designUI()ตอนนี้ชีวิตราบรื่นดีครับ จนมีเทคโนโลยีใหม่เข้ามา บอสทั้ง 2 ส่งผมไปอบรม เพื่อพัฒนาสกิลทางด้าน Programming และ Designing ตอนนี้ Methods ของผมได้รับการอัพเกรดแล้วครับ ดังนี้ 555+
จะเห็นได้ว่า Programmer คนนี้ทำงานหนักมากครับ คือ
- มีหน้าที่ 2 อย่าง ทั้ง Code แล้วก็ Design ในเวลาเดียวกัน (2 Responsibilities)
- ทำงานให้กับบอส 2 คน (2 Responsibilities)
- ไม่พอยังต้องไปอบรม ไปเรียนเพื่อพัฒนาสกิลในทั้ง 2 ด้านนี้ด้วย (มี 2 เหตุผลที่ทำให้โปรแกรมเม่อร์คนนี้ต้องเปลี่ยนแปลงตัวเอง Code เก่งขึ้น กับ Design ให้ดีขึ้น)
สรุปคือบริษัทนี้จ้างโปรแกรมเม่อร์มาได้คุ้มมาก เอ้ยไม่ใช่!! 55+ สรุปคือบริษัทนี้กำลัง break กฎข้อนี้อยู่ครับ
ลองคิดดูครับคนคนเดียวทำงาน 2 อย่างในเวลาเดียวกัน เรียนรู้ 2 อย่างในเวลาเดียวกัน ผลลัพธ์คือพังครับ!!! (เว้นแต่ว่าเขาเป็นยอดมนุษย์ 555+) แล้วก็ผลงานที่ออกมามันจะไม่สุดสักทาง แล้วก็อาจจะใช้เวลานานกว่าครับ
คราวนี้เราจะแก้ปัญหาให้กับโปรแกรมเม่อร์คนนี้ แล้วก็บริษัทนี้ยังไงดีหละ ? คำตอบก็คืออออ จ้าง UI Designer มาไง
เอาหละครับคราวนี้โปรแกรมเมอร์ก็ทำหน้าที่ Code ไป ถ้าบริษัทต้องการจะ Design UI ก็ไปมอบหมายงานให้ Designer คนใหม่ที่จ้างมา จะเห็นได้ว่าตอนนี้แต่ละคนมีเพียงหน้าที่เดียวแล้ว ผลงานก็ออกมาดีครับ โปรแกรมเมอร์มีเวลาให้กับการ Code มีเวลาพัฒนาทักษะด้านนี้มากขึ้น ชีวิตแฮปปี้ครับ ดีไม่ดีได้กับ Designer ที่จ้างมาใหม่อีก (เอ้ยอันนี้ไม่ใช่แล้ว !!!)
สรุปคร่าวๆนะครับ เปรียบเทียบชีวิตโปรแกรมเม่อ ก่อนกับหลังการจ้าง UIDesigner คนใหม่ เข้ามา
เหมือนจะออกทะเลไปไกล 555+ หวังว่าคงจะเข้าใจ Concept ไม่มากก็น้อยนะครับ คราวนี้มาเปรียบกับการ Coding จริงๆมั่งครับ สมมติผมมี Class StatisticsCalculator ครับ ดังนี้
จะเห็นได้ว่า Class นี้มี 2 หน้าที่นะครับ คือ
- มีการคำนวณ(Business Logic) calStdDev() และ calMean()
- มีการแสดงผลการคำนวณ displayStdDevResult() และ displayMeanResult()
เท่ากับว่าถ้าคุณต้องการเปลี่ยนรูปแบบการแสดงผล หรือ เปลี่ยนสูตรในการคำนวณ คุณจะกลับมาแก้ไข Code ใน Class นี้
นี้แหละครับ คุณมี 2 เหตุผลในการเปลี่ยนแปลง Class นี้แล้ว อันนี้ก็คือ Break rule ข้อนี้นะครับผม
เราอาจจะแก้ปัญหาได้ด้วยวิธีนี้ (แบบ Simple ที่สุด)
จากตรงนี้จะเห็นได้ว่า ถ้าเราต้องการแก้กฎของการคำนวณสถิติ ก็ไปดูที่ Class StatisticsCalculator (มีเหตุผลเดียวเท่านั้นที่เราจะแก้ไข Class นี้)
StatisticsApp Injects คลาส StatisticsCalculator เข้ามา แล้วก็มี methods สำหรับการแสดงผลเป็นของตัวเอง ซึ่งถ้าจะแก้ไขการแสดงผลก็ให้มาดูที่ Class นี้
แต่ละ Class มีหน้าที่เดียวแล้วครับ : )
- อันนี้อาจจะไม่ใช่การแก้ไขปัญหาที่ดีที่สุดนะครับ เราอาจจะแบ่งเป็นมี Class นึงสำหรับการคำนวณโดยเฉพาะ อีก Class สำหรับการแสดงผลโดยเฉพาะ แล้วมี Class กลาง (Controller) Injects Object ของ 2 คลาสนี้เข้ามาครับ (MVC)
- หรือจะใช้ Design Patterns อันนี้ขอข้ามไปก่อนนะครับ ถ้ามีโอกาสจะมาเขียน Blog สอนทีละ Design Pattern เลย (เพราะตอนนี้ผมก็ยังไม่รู้เรื่องเลยครับ 55+)
- ข้อควรระวังคือ Needless Complexity ครับ คือควรจะแก้ปัญหาให้มัน Simple ที่สุด ไม่ใช่ใช้มันทุก Principles ทุก Patterns เลย แทนที่จะทำให้โปรแกรมมัน maintain ง่ายขึ้น กลับเป็นการเพิ่มความยุ่งยากให้มันซะงั้น
สุดท้ายก็ขอขอบคุณที่อ่านจนจบนะครับ มีอะไรติชม แนะนำได้เลยครับผม ขอบคุณมากครับ
Blog ต่อไปที่ผมจะเขียนก็จะเป็น O ใน SOLID นะครับ รอติดตามได้เร็วๆนี้ : )
สำหรับคนที่อยากรู้ว่าทำไมเราควรจะ Apply SOLID Principles ใน Software ของเรา ลองอ่านบทความของผมก่อนหน้านี้ดูนะครับ
“ Happiness Only Real When Shared ”
ปล. ที่เริ่มเขียน Blog เพราะไปดูหนังเรื่องนึงแล้วเจอ Quote นี้ ผมก็เลยจะลองดูครับว่ามันจริงหรือเปล่า
Reference:
Robert cecil martin. (2002). Agile Software Development, Principles, Patterns, and Practices. (1st ed.). England: Pearson.
Fanpage ครับ : https://www.facebook.com/imkrish.developer/
