SRP: คืออะไร หลักความรับผิดชอบเดียวในการพัฒนา

SRP (Single Responsibility Principle) คืออะไร?

SRP (Single Responsibility Principle) คือหลักความรับผิดชอบเดียว ซึ่งกล่าวว่า: แต่ละคลาสหรือโมดูลต้องมีเหตุผลในการเปลี่ยนแปลงเพียงหนึ่งเดียวเท่านั้น นี่ไม่ได้หมายความว่าคลาสต้องดำเนินการเพียงอย่างใดอย่างหนึ่ง แต่หมายถึงกลุ่มของการกระทำที่เกี่ยวข้องกันซึ่งรวมเป็นความรับผิดชอบเดียวต่อตัวแสดงหนึ่งตัว

Robert Martin ได้กำหนด SRP ใหม่ในแง่ของตัวแสดง: คลาสควรเปลี่ยนแปลงเฉพาะเมื่อคำขอของผู้มีส่วนได้ส่วนเสียหรือกลุ่มคนกลุ่มเดียว หากตัวแสดงสองตัวที่แตกต่างกันต้องการการเปลี่ยนแปลงในคลาสเดียวกัน แสดงว่าความรับผิดชอบถูกแบ่งอย่างไม่ถูกต้อง

ตัวอย่างเช่น คลาส Employee ที่คำนวณเงินเดือน (คำขอของแผนกบัญชี) และสร้างรายงาน (คำขอของผู้บริหาร) ละเมิด SRP การเปลี่ยนแปลงกฎการคำนวณอาจส่งผลกระทบต่อการสร้างรายงานและในทางกลับกัน

คำจำกัดความอย่างเป็นทางการของ SRP

โมดูล ต้องมีเหตุผลในการเปลี่ยนแปลงหนึ่งเดียวเท่านั้น เหตุผลในการเปลี่ยนแปลงถูกกำหนดโดยตัวแสดง — บุคคลหรือระบบที่เริ่มต้นความต้องการ หากความต้องการจากตัวแสดงที่แตกต่างกันนำไปสู่การเปลี่ยนแปลงในโมดูลเดียวกัน โมดูลนั้นละเมิด SRP

แนวคิดเกี่ยวกับตัวแสดงทำให้ SRP เป็นเครื่องมือในการวิเคราะห์สถาปัตยกรรมที่ใช้งานได้จริง ไม่ใช่คำแนะนำเชิงนามธรรม เมื่อออกแบบระบบ เพียงแค่ถามว่า: “ใครจะเป็นคนขอให้เปลี่ยนแปลงโค้ดนี้?” — หากคำตอบมีมากกว่าหนึ่งฝ่ายที่เกี่ยวข้อง ควรแบ่งแยกความรับผิดชอบ

หลักความรับผิดชอบเดียวทำงานอย่างไร

ความรับผิดชอบเดียว ถูกนำไปใช้โดยการจัดกลุ่มเมธอดที่เปลี่ยนแปลงด้วยเหตุผลเดียวกัน คลาสกลายเป็น “จุดรวบรวม” ของตรรกะที่เกี่ยวข้อง แทนที่จะเป็น “มีดพกสวิส” สำหรับทุกโอกาส ซึ่งช่วยให้เข้าใจโค้ดได้ง่ายขึ้น: นักพัฒนาเห็นคลาสและเข้าใจวัตถุประสงค์ของมันได้ทันที

กลไกการทำงานของ SRP ขึ้นอยู่กับกฎของ แกนการเปลี่ยนแปลงเดียว หากฟังก์ชันการทำงานสามารถเปลี่ยนแปลงได้ด้วยเหตุผลที่เป็นอิสระ ควรแยกออกไปเป็นคลาสต่างๆ การเชื่อมต่อระหว่างคลาสเหล่านี้สร้างขึ้นผ่านการรวมองค์ประกอบหรือการมอบหมาย

การละเมิด SRP ปรากฏในรูปแบบ “God Object” — คลาสที่มีเมธอดจำนวนมากที่ทำงานกับข้อมูลที่แตกต่างกัน คลาสแบบนี้ทดสอบได้ยาก — การทดสอบหนึ่งเมธอดต้องตั้งค่าสภาพแวดล้อมสำหรับเมธอดอื่นทั้งหมด การเปลี่ยนแปลงความรับผิดชอบหนึ่งอาจทำให้อีกอย่างพัง ทำให้โค้ดเปราะบาง

ในทางปฏิบัติ SRP ช่วยนักพัฒนาตอบคำถาม “โค้ดนี้อยู่ที่ไหน?” หากแต่ละความรับผิดชอบถูกแยกออกไปในคลาสของตัวเอง การค้นหาไฟล์ที่ถูกต้องใช้เวลาเพียงไม่กี่วินาที ในโปรเจกต์ Android ที่มีสถาปัตยกรรม MVVM UserViewModel รับผิดชอบเฉพาะสถานะหน้าจอผู้ใช้ และ UserRepository รับผิดชอบการดึงข้อมูล นักพัฒนาที่ค้นหาตรรกะแคชจะไปที่ UserCacheRepository ไม่ใช่ ViewModel การจัดระเบียบโค้ดแบบนี้ ช่วยให้สมาชิกทีมใหม่สามารถทำงานได้เร็วขึ้น และลดจำนวนข้อผิดพลาดระหว่างการปรับโครงสร้าง

ทำไม SRP ถึงสำคัญในการพัฒนาโมบายล์

การพัฒนาโมบายล์ มีข้อกำหนดพิเศษสำหรับการเป็นโมดูลาร์ของโค้ด Android Fragment หรือ iOS ViewController มักจะกลายเป็น “แม่เหล็ก” ดึงดูดตรรกะ: การจัดการการแตะ การเรียก API การวิเคราะห์คำตอบ การอัปเดต UI — ทั้งหมดอยู่ในคลาสเดียว SRP ต้องการแยกความรับผิดชอบเหล่านี้

ใน สถาปัตยกรรม Android SRP ถูกฝังอยู่ในคำแนะนำของ Google เกี่ยวกับ Jetpack: ViewModel รับผิดชอบสถานะหน้าจอ Repository รับผิดชอบข้อมูล UseCase รับผิดชอบตรรกะทางธุรกิจ ใน การพัฒนา iOS รูปแบบ MVVM และ Coordinator ปฏิบัติตามตรรกะเดียวกัน

การปฏิบัติตาม SRP ในโปรเจกต์โมบายล์ให้ประโยชน์ที่วัดได้: ขนาดคลาสลดลง 40-60% ใช้เวลาในการตรวจสอบโค้ดน้อยลง และลดข้อผิดพลาดแบบถดถอยเมื่อเพิ่มฟังก์ชันใหม่ โมดูลที่แยกออกจากกัน ง่ายต่อการครอบคลุมด้วยการทดสอบหน่วยและนำกลับมาใช้ในหน้าจออื่นๆ

ผลกระทบของ SRP ต่อการทดสอบ

การทดสอบหน่วย ของคลาสที่ปฏิบัติตาม SRP ต้องการวัตถุจำลองและการตั้งค่าน้อยกว่า หากคลาสมีความรับผิดชอบเดียว การพึ่งพาของมันมีจำกัด การทดสอบจะตรวจสอบพฤติกรรมหนึ่งอย่าง ไม่ใช่การรวมกันของหลายสถานการณ์ที่ไม่เกี่ยวข้องกัน

ตามรายงานของ Google Testing Blog (2023) คลาสที่มีความรับผิดชอบเดียวแสดง ความครอบคลุมการทดสอบสูงกว่า 35% เมื่อเทียบกับคลาสรวมรวบ นักพัฒนาเต็มใจที่จะเขียนทดสอบสำหรับโมดูลขนาดเล็กที่เข้าใจง่ายมากกว่า

ตัวอย่าง SRP ใน Android และ iOS

ลองดู คลาส Android ทั่วไปที่ละเมิด SRP — โหลดข้อมูล แยกวิเคราะห์คำตอบ และอัปเดต UI หลังจากการปรับโครงสร้าง ความรับผิดชอบแต่ละอย่างจะถูกแยกออกไปในคอมโพเนนต์ของตัวเอง

// การละเมิด SRP: หนึ่งคลาสทำทุกอย่าง
class BadUserProfileActivity {
    fun loadUser(userId: Int) {
        // คำขอ HTTP
        // การแยกวิเคราะห์ JSON
        // การอัปเดต UI
        // บันทึกลงฐานข้อมูล
    }
}

// หลังจากใช้ SRP
class UserRepository {
    fun getUser(userId: Int): User
}

class UserViewModel {
    private val repo: UserRepository
    fun loadUser(userId: Int) { }
}

class UserProfileFragment {
    fun render(user: User) { }
}

ตัวอย่างที่คล้ายกันใน iOS Swift โดยแยกชั้นเครือข่ายและการแสดงผล:

// การละเมิด SRP: ViewController จัดการข้อมูลและ UI
class BadProfileViewController: UIViewController {
    func viewDidLoad() {
        // คำขอ URLSession
        // ถอดรหัส JSON
        // อัปเดต label
    }
}

// หลังจากใช้ SRP
protocol UserServiceProtocol {
    func fetchUser(id: Int) async throws -> User
}

class ProfileViewModel {
    private let service: UserServiceProtocol
    func loadProfile(id: Int) { }
}

class ProfileViewController: UIViewController {
    func display(user: User) { }
}

การปรับโครงสร้าง SRP ไม่ได้ทำให้สถาปัตยกรรมซับซ้อน — แต่จัดสรรความรับผิดชอบใหม่ ปริมาณโค้ดอาจลดลงด้วยซ้ำโดยการกำจัดสิ่งที่ซ้ำซ้อน แต่ละคลาสใหม่มีวัตถุประสงค์ที่ชัดเจนและสามารถพัฒนาได้อย่างอิสระ

การรวมองค์ประกอบเป็นทางเลือกแทนการสืบทอด

การรวมองค์ประกอบ ช่วยรักษา SRP ในที่ที่การสืบทอดสร้างการเชื่อมโยงที่ไม่จำเป็น แทนที่จะมีซูเปอร์คลาสที่มีเมธอดจำนวนมาก ซับคลาสจะได้รับชุดของวัตถุเฉพาะทางผ่านคอนสตรัคเตอร์ แต่วัตถุแต่ละตัวรับผิดชอบฟังก์ชันการทำงานของตัวเอง

ในการพัฒนา Android รูปแบบ Decorator อนุญาตให้เพิ่มความรับผิดชอบโดยไม่ต้องแก้ไขคลาสดั้งเดิม ใน iOS สายโซ่ Middleware ในชั้นเครือข่ายแยกการบันทึก การแคช และการตรวจสอบสิทธิ์ออกเป็นโมดูลแยกต่างหาก

การละเมิด SRP ทั่วไปและผลกระทบ

การละเมิดที่พบบ่อยที่สุด คือ God Class: คลาสที่จัดการฐานข้อมูล ส่งการแจ้งเตือน สร้างรายงาน และประมวลผลการป้อนข้อมูลของผู้ใช้ คลาสแบบนี้กลายเป็นคอขวดของโปรเจกต์: การเปลี่ยนแปลงใดๆ ต้องทดสอบการถดถอยอย่างสมบูรณ์

ในการพัฒนาโมบายล์ การผสม ตรรกะทางธุรกิจ และ ตรรกะ UI ใน Activity Fragment หรือ ViewController นำไปสู่การละเมิด SRP เมื่อ onClickListener ตรวจสอบความถูกต้องของข้อมูล เรียก API และอัปเดตการมองเห็นของปุ่มพร้อมกัน — นี่คือการละเมิดโดยตรงต่อหลักความรับผิดชอบเดียว

ผลกระทบของการละเมิด SRP รวมถึง: ความยากในการพัฒนาแบบขนาน (ข้อขัดแย้งในไฟล์เดียว) การทดสอบหน่วยที่ยาก ต้นทุนสูงในการเปลี่ยนแปลง และความสามารถในการอ่านโค้ดที่ลดลง โปรเจกต์ที่มีการละเมิด SRP อย่างเป็นระบบต้องใช้ เวลาเพิ่มขึ้น 2-3 เท่า ในการเพิ่มฟังก์ชันใหม่

ตัวบ่งชี้การละเมิด SRP ในโค้ด

สามารถระบุการละเมิด SRP ได้จากสัญญาณทางอ้อม: คลาสมีมากกว่า 200 บรรทัด นำเข้าโมดูลจากชั้นแอปพลิเคชันที่แตกต่างกัน (UI + network + database) มีเมธอดสาธารณะมากกว่า 5 วิธีในหัวข้อที่แตกต่างกัน ตัววัดการเชื่อมแน่น (cohesion) เป็นตัวชี้วัดทางสถิติ: การเชื่อมแน่นต่ำของเมธอดภายในคลาสบ่งบอกถึงการละเมิด SRP

เพื่อค้นหาการละเมิด SRP ใช้ เครื่องมือวิเคราะห์แบบสแตติก: สำหรับ Android — Detekt กับกฎ TooManyFunctions สำหรับ iOS — SwiftLint กับกฎ file_length เครื่องมือเหล่านี้จะไฮไลต์คลาสที่เกินเกณฑ์ขนาดและความซับซ้อน

การปรับโครงสร้างคลาสที่ละเมิด SRP ทำโดย Extract Class หรือ Extract Delegate: กลุ่มของเมธอดที่เกี่ยวข้องกันถูกแยกออกไปยังคลาสแยกต่างหาก และคลาสเดิมมอบหมายการเรียกให้กับคลาสเหล่านั้น การใช้งานการปรับโครงสร้างเหล่านี้แบบค่อยเป็นค่อยไปจะเปลี่ยน God Class ให้เป็นชุดของโมดูลที่เชื่อมโยงกันต่ำ แต่ละโมดูลมีความรับผิดชอบเดียว วิธีการนี้ ช่วยให้ปรับปรุงสถาปัตยกรรมโดยไม่ต้องหยุดการพัฒนา — การปรับโครงสร้างทำแบบวนซ้ำ ทีละโมดูล