คำถามติดแท็ก single-responsibility

หลักการความรับผิดชอบเดี่ยวระบุว่าแต่ละโมดูลในระบบควรรับผิดชอบต่อคุณสมบัติหรือฟังก์ชันการทำงานเดียวหรือการรวมฟังก์ชันการทำงานที่เชื่อมโยงกัน อีกวิธีที่ใช้กันทั่วไปคือการบอกว่าแต่ละโมดูลควรมีเหตุผลเดียวที่จะเปลี่ยน

6
การบันทึกถัดจากการใช้งานเป็นการละเมิด SRP หรือไม่
เมื่อคิดถึงการพัฒนาซอฟต์แวร์ที่คล่องตัวและหลักการทั้งหมด (SRP, OCP, ... ) ฉันถามตัวเองว่าจะจัดการการบันทึกอย่างไร การบันทึกถัดจากการใช้งานเป็นการละเมิด SRP หรือไม่ ฉันจะบอกว่าyesเพราะการใช้งานควรจะสามารถทำงานได้โดยไม่ต้องเข้าสู่ระบบ ดังนั้นฉันจะใช้การบันทึกในวิธีที่ดีกว่าได้อย่างไร ฉันได้ตรวจสอบรูปแบบบางอย่างและได้ข้อสรุปว่าวิธีที่ดีที่สุดที่จะไม่ละเมิดหลักการในแบบที่ผู้ใช้กำหนด แต่เพื่อใช้รูปแบบใด ๆ ที่ทราบว่าละเมิดหลักการก็คือใช้รูปแบบมัณฑนากร สมมติว่าเรามีส่วนประกอบจำนวนมากโดยไม่มีการละเมิด SRP จากนั้นเราต้องการเพิ่มการบันทึก องค์ประกอบ A องค์ประกอบ B ใช้ A เราต้องการบันทึกสำหรับ A ดังนั้นเราจึงสร้างส่วนประกอบอีก D ที่ตกแต่งด้วย A ทั้งสองใช้อินเตอร์เฟส I อินเตอร์เฟส I component L (บันทึกองค์ประกอบของระบบ) องค์ประกอบ A ใช้ I component D ใช้ I, ตกแต่ง / ใช้ A, ใช้ …

6
การสืบทอดหลายรายการละเมิดหลักการความรับผิดชอบแบบเดี่ยวหรือไม่?
หากคุณมีคลาสที่สืบทอดมาจากคลาสที่แตกต่างกันสองคลาสนี่หมายความว่าคลาสย่อยของคุณทำสิ่งต่าง ๆ โดยอัตโนมัติ (อย่างน้อย) 2 อย่างสิ่งหนึ่งจากคลาสซุปเปอร์แต่ละอัน? ฉันเชื่อว่าไม่มีความแตกต่างหากคุณมีการสืบทอดหลายอินเตอร์เฟส แก้ไข: เพื่อความชัดเจนฉันเชื่อว่าหากคลาสย่อยหลายคลาสละเมิด SRP จากนั้นใช้หลายอินเทอร์เฟซ (ไม่ใช่ตัวทำเครื่องหมายหรืออินเทอร์เฟซพื้นฐาน (เช่นที่เปรียบเทียบได้)) ละเมิด SRP ด้วย

4
หลักการความรับผิดชอบเดี่ยวใช้กับฟังก์ชันได้หรือไม่
อ้างอิงจากโรเบิร์ตซี. มาร์ติน SRP ระบุว่า: ไม่ควรมีเหตุผลมากกว่าหนึ่งข้อในการเปลี่ยนชั้นเรียน อย่างไรก็ตามในClean Codeในหนังสือของเขาบทที่ 3: ฟังก์ชั่นเขาแสดงบล็อคของรหัสต่อไปนี้: public Money calculatePay(Employee e) throws InvalidEmployeeType { switch (e.type) { case COMMISSIONED: return calculateCommissionedPay(e); case HOURLY: return calculateHourlyPay(e); case SALARIED: return calculateSalariedPay(e); default: throw new InvalidEmployeeType(e.type); } } แล้วสหรัฐฯ: มีปัญหาหลายอย่างกับฟังก์ชั่นนี้ อย่างแรกคือมันมีขนาดใหญ่และเมื่อมีการเพิ่มประเภทพนักงานใหม่ก็จะเพิ่มขึ้น ประการที่สองมันชัดเจนมากกว่าสิ่งหนึ่ง ประการที่สามมีการละเมิด Single รับผิดชอบหลักการ (SRP) เพราะมีมากกว่าเหตุผลหนึ่งที่ทำให้มันมีการเปลี่ยนแปลง [เน้นเหมือง] ก่อนอื่นฉันคิดว่า SRP ถูกกำหนดไว้สำหรับคลาส …

5
SRP (หลักการความรับผิดชอบเดี่ยว) มีวัตถุประสงค์หรือไม่
พิจารณานักออกแบบ UI สองคนที่ต้องการออกแบบการออกแบบที่“ ดึงดูดผู้ใช้” "การดึงดูดผู้ใช้" เป็นแนวคิดที่ไม่ได้มีวัตถุประสงค์และอยู่ในใจของนักออกแบบเท่านั้น ดังนั้นผู้ออกแบบสามารถยกตัวอย่างเช่นสีแดงในขณะที่นักออกแบบ B เลือกสีน้ำเงิน นักออกแบบ A สร้างเลย์เอาต์ที่แตกต่างอย่างสิ้นเชิงจากดีไซเนอร์ B และอื่น ๆ ฉันอ่านเกี่ยวกับ SRP (Single Responsibility Principle) และสิ่งที่ฉันเข้าใจคือการวิเคราะห์เชิงอัตวิสัยหรือการแยกความรับผิดชอบที่อาจแตกต่างจากนักออกแบบ OO ถึงผู้ออกแบบ OO คนอื่น ฉันถูกไหม? กล่าวอีกนัยหนึ่งเป็นไปได้หรือไม่ที่จะมีตัววิเคราะห์เชิงวัตถุสองตัวที่ยอดเยี่ยมและผู้ออกแบบที่มาพร้อมกับการออกแบบที่แตกต่างกันสองแบบสำหรับหนึ่งระบบโดยยึดตามหลักการ SRP

5
MVC: คอนโทรลเลอร์ทำลายหลักการความรับผิดชอบเดี่ยวหรือไม่?
หลักการความรับผิดชอบเดี่ยวระบุว่า "คลาสควรมีเหตุผลประการเดียวคือการเปลี่ยนแปลง" ในรูปแบบ MVC งานของผู้ควบคุมจะเป็นสื่อกลางระหว่างมุมมองและรูปแบบ มันมีอินเทอร์เฟซสำหรับมุมมองเพื่อรายงานการกระทำของผู้ใช้บน GUI (เช่นการอนุญาตให้ดูการโทรcontroller.specificButtonPressed()) และสามารถเรียกวิธีการที่เหมาะสมในตัวแบบเพื่อจัดการข้อมูลหรือเรียกใช้การดำเนินการ (เช่นmodel.doSomething()) . ซึ่งหมายความว่า: คอนโทรลเลอร์จำเป็นต้องรู้เกี่ยวกับ GUI เพื่อเสนอมุมมองอินเทอร์เฟซที่เหมาะสมเพื่อรายงานการกระทำของผู้ใช้ นอกจากนี้ยังจำเป็นต้องรู้เกี่ยวกับตรรกะในรูปแบบเพื่อที่จะสามารถเรียกใช้วิธีการที่เหมาะสมในรูปแบบ นั่นหมายความว่ามีสองเหตุผลในการเปลี่ยนแปลง : การเปลี่ยนแปลงใน GUI และการเปลี่ยนแปลงในตรรกะธุรกิจ หากมีการเปลี่ยนแปลง GUI เช่นมีการเพิ่มปุ่มใหม่ตัวควบคุมอาจต้องเพิ่มวิธีการใหม่เพื่อให้มุมมองรายงานผู้ใช้กดปุ่มนี้ และหากตรรกะทางธุรกิจในรูปแบบการเปลี่ยนแปลงผู้ควบคุมอาจต้องเปลี่ยนเพื่อที่จะเรียกใช้วิธีการที่ถูกต้องในรูปแบบ ดังนั้นการควบคุมมีสองเหตุผลที่เป็นไปได้ที่จะมีการเปลี่ยนแปลง มันทำลาย SRP หรือไม่

7
ฉันควร refactor ฟังก์ชั่นขนาดใหญ่ที่ส่วนใหญ่ประกอบด้วย regex หนึ่งหรือไม่ [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันเพิ่งเขียนฟังก์ชันที่ครอบคลุมประมาณ 100 บรรทัด ได้ยินว่าคุณอาจถูกล่อลวงให้บอกฉันเกี่ยวกับความรับผิดชอบเดี่ยวและกระตุ้นให้ฉันไปปรับโครงสร้าง นี่คือสัญชาตญาณของฉันเช่นกัน แต่นี่คือปัญหา: ฟังก์ชันทำสิ่งหนึ่ง มันดำเนินการจัดการสตริงที่ซับซ้อนและร่างกายฟังก์ชั่นประกอบด้วยส่วนใหญ่ของหนึ่ง verbose regex แยกออกเป็นหลายบรรทัดที่มีเอกสาร ถ้าฉันแยก regex ออกเป็นหลาย ๆ ฟังก์ชั่นฉันรู้สึกว่าฉันจะสูญเสียความสามารถในการอ่านได้เนื่องจากฉันเปลี่ยนภาษาได้อย่างมีประสิทธิภาพและจะไม่สามารถใช้ประโยชน์จากคุณสมบัติบางอย่างของ regex นี่คือคำถามของฉัน: เมื่อพูดถึงการจัดการสตริงที่มีการแสดงออกปกติร่างกายของฟังก์ชั่นขนาดใหญ่ยังคงมีรูปแบบการต่อต้านหรือไม่? ดูเหมือนว่ากลุ่มการดักจับที่ตั้งชื่อไว้นั้นมีจุดประสงค์คล้ายกันมากกับฟังก์ชั่น โดยวิธีการที่ฉันมีการทดสอบสำหรับทุกการไหลผ่าน Regex

4
รูปแบบความรับผิดชอบเดี่ยวควรมีรูปแบบเฉพาะสำหรับชั้นเรียนอย่างไร
ตัวอย่างเช่นสมมติว่าคุณมีโปรแกรมเกมคอนโซลซึ่งมีวิธีอินพุต / เอาต์พุตทุกชนิดเข้าและออกจากคอนโซล มันจะเป็นสมาร์ทเพื่อให้พวกเขาทั้งหมดในครั้งเดียวinputOutputชั้นเรียนหรือทำลายพวกเขาลงไปเรียนที่เฉพาะเจาะจงมากขึ้นเช่นstartMenuIO, inGameIO, playerIO, gameBoardIOฯลฯ ดังกล่าวว่าแต่ละชั้นจะมีประมาณ 1-5 วิธี? และเมื่อทราบเหมือนกันถ้ามันจะดีกว่าที่จะทำลายพวกเขาลงมันจะเป็นสมาร์ทที่จะวางไว้ในIOnamespace จึงทำให้เรียกพวกเขาเล็ก ๆ น้อย ๆ มากขึ้นอย่างละเอียดเช่น: IO.inGameฯลฯ ?

4
ชั้นเรียนขนาดใหญ่ที่มีความรับผิดชอบเดียว
ฉันมีCharacterคลาสline 2,500 ที่: ติดตามสถานะภายในของตัวละครในเกม โหลดและยืนยันสถานะนั้น จัดการคำสั่งที่เข้ามา ~ 30 (โดยปกติ = ส่งต่อคำสั่งไปยังGameแต่คำสั่งแบบอ่านอย่างเดียวบางคำสั่งจะตอบกลับทันที) รับสายประมาณ 80 สายจากGameการกระทำที่ต้องทำและการกระทำที่เกี่ยวข้องของผู้อื่น ดูเหมือนว่าฉันCharacterมีความรับผิดชอบเดียว: การจัดการสถานะของตัวละคร, การไกล่เกลี่ยระหว่างคำสั่งที่เข้ามาและเกม มีความรับผิดชอบอื่น ๆ อีกสองสามอย่างที่ถูกทำลายไปแล้ว: Characterมีสิ่งOutgoingที่เรียกร้องให้สร้างการอัพเดตขาออกสำหรับแอปพลิเคชันไคลเอนต์ CharacterมีTimerแทร็กใดที่อนุญาตให้ทำอะไรต่อไป คำสั่งที่เข้ามาจะถูกตรวจสอบกับสิ่งนี้ ดังนั้นคำถามของฉันคือเป็นที่ยอมรับหรือไม่ที่จะมีชั้นเรียนขนาดใหญ่ภายใต้ SRP และหลักการที่คล้ายกัน? มีวิธีปฏิบัติที่ดีที่สุดในการทำให้ยุ่งยากน้อยลงหรือไม่ (เช่นอาจแบ่งวิธีเป็นไฟล์แยกกัน) หรือฉันขาดอะไรบางอย่างไปและมีวิธีที่ดีมากที่จะแยกมันออกมา? ฉันรู้ว่านี่เป็นอัตนัยและต้องการความคิดเห็นจากผู้อื่น นี่คือตัวอย่าง: class Character(object): def __init__(self): self.game = None self.health = 1000 self.successful_attacks = 0 self.points = 0 self.timer = Timer() …

4
เมื่อติดตาม SOLID การอ่านและการเขียนไฟล์มีความรับผิดชอบแยกกันสองอย่างหรือไม่?
ฉันเพิ่งเริ่มสำรวจ SOLID และฉันไม่แน่ใจว่าการอ่านจากไฟล์และการเขียนไปยังไฟล์เป็นความรับผิดชอบเดียวกันหรือไม่ เป้าหมายเป็นไฟล์ประเภทเดียวกัน ฉันต้องการอ่านและเขียน. pdf ในใบสมัครของฉัน แอปพลิเคชันอยู่ใน Python หากสร้างความแตกต่าง

3
ทำงานผ่านหลักการความรับผิดชอบเดี่ยว (SRP) ใน Python เมื่อการโทรมีราคาแพง
บางจุดฐาน: การเรียกใช้เมธอด Python นั้น "แพง" เนื่องจากเป็นลักษณะที่ตีความได้ ในทางทฤษฎีถ้ารหัสของคุณก็พอง่ายที่จะหมดสภาพรหัสงูใหญ่มีผลกระทบเชิงลบที่นอกเหนือจากการอ่านและนำมาใช้ใหม่ ( ซึ่งเป็นกำไรที่ยิ่งใหญ่สำหรับนักพัฒนาไม่มากสำหรับผู้ใช้ ) หลักการความรับผิดชอบเดี่ยว (SRP) ช่วยให้สามารถอ่านโค้ดง่ายต่อการทดสอบและบำรุงรักษา โครงการมีพื้นหลังแบบพิเศษที่เราต้องการให้สามารถอ่านโค้ดการทดสอบและประสิทธิภาพของเวลาได้ ตัวอย่างเช่นโค้ดเช่นนี้ซึ่งเรียกใช้หลายวิธี (x4) จะช้ากว่าวิธีต่อไปนี้ซึ่งเป็นวิธีเดียว from operator import add class Vector: def __init__(self,list_of_3): self.coordinates = list_of_3 def move(self,movement): self.coordinates = list( map(add, self.coordinates, movement)) return self.coordinates def revert(self): self.coordinates = self.coordinates[::-1] return self.coordinates def get_coordinates(self): return self.coordinates ## …

5
มีประโยชน์กับ mini-refactor code โดยหวังว่าจะปรับปรุงคุณภาพหรือเป็นเพียง“ การเคลื่อนย้ายโค้ดไปรอบ ๆ ” โดยไม่มีประโยชน์มาก?
ตัวอย่าง ฉันเจอรหัสเสาหินที่ทำ "ทุกอย่าง" ในที่เดียว - โหลดข้อมูลจากฐานข้อมูลแสดงมาร์กอัพ HTML ทำหน้าที่เป็นเราเตอร์ / คอนโทรลเลอร์ / การกระทำ ฉันเริ่มใช้การย้ายรหัสฐานข้อมูล SRP ไปยังไฟล์ของตัวเองโดยให้การตั้งชื่อที่ดีขึ้นสำหรับสิ่งต่าง ๆ และมันก็ดูดี แต่แล้วฉันก็เริ่มสงสัยว่าทำไมฉันถึงทำแบบนี้ ทำไมต้องรีแฟคเตอร์ จุดประสงค์คืออะไร? มันไร้ประโยชน์หรือเปล่า? ประโยชน์คืออะไร โปรดทราบว่าฉันส่วนใหญ่ออกจากไฟล์เสาหินตามที่เป็นอยู่ แต่ refactored เฉพาะส่วนเล็ก ๆ ที่เกี่ยวข้องกับพื้นที่ที่ฉันต้องทำงานบางอย่าง รหัสเดิม: เพื่อเป็นตัวอย่างที่เป็นรูปธรรมฉันได้พบข้อมูลโค้ดนี้ - มันโหลดข้อมูลจำเพาะของผลิตภัณฑ์โดยใช้รหัสผลิตภัณฑ์ที่รู้จักหรือโดยรหัสรุ่นที่ผู้ใช้เลือก: if ($verid) $sql1 = "SELECT * FROM product_spec WHERE id = " . clean_input($verid); else $sql1 = "SELECT …

5
วิธีหลีกเลี่ยงการละเมิด SRP ในชั้นเรียนเพื่อจัดการแคช?
หมายเหตุ:ตัวอย่างโค้ดเขียนด้วย c # แต่นั่นไม่ควรสำคัญ ฉันใส่ c # เป็นแท็กเพราะหาแท็บไม่ได้อีก นี่คือเกี่ยวกับโครงสร้างรหัส ฉันอ่าน Clean Code และพยายามเป็นโปรแกรมเมอร์ที่ดีขึ้น ฉันมักจะพบว่าตัวเองกำลังดิ้นรนเพื่อทำตามหลักการความรับผิดชอบเดียว (ชั้นเรียนและฟังก์ชั่นควรทำเพียงสิ่งเดียว) โดยเฉพาะอย่างยิ่งในฟังก์ชั่น บางทีปัญหาของฉันคือ "สิ่งหนึ่ง" ไม่ชัดเจน แต่ก็ยัง ... ตัวอย่าง: ฉันมีรายการ Fluffies ในฐานข้อมูล เราไม่สนใจว่าปุยคืออะไร ฉันต้องการชั้นเรียนเพื่อกู้คืนความผิดปกติ อย่างไรก็ตาม fluffies สามารถเปลี่ยนแปลงได้ตามตรรกะบางอย่าง คลาสนี้จะส่งคืนข้อมูลจากแคชหรือรับข้อมูลล่าสุดจากฐานข้อมูลทั้งนี้ขึ้นอยู่กับตรรกะบางอย่าง เราสามารถพูดได้ว่ามันจัดการกับความฟู่ฟ่าและนั่นคือสิ่งหนึ่ง เพื่อให้ง่ายสมมติว่าข้อมูลที่โหลดนั้นดีสำหรับหนึ่งชั่วโมงจากนั้นจะต้องโหลดใหม่ class FluffiesManager { private Fluffies m_Cache; private DateTime m_NextReload = DateTime.MinValue; // ... public Fluffies GetFluffies() { …

3
IValidatableObject vs Single Responsibility
ฉันชอบจุดที่เพิ่มความสามารถของ MVC ช่วยให้มุมมองแบบจำลองใช้ IValidatableObject และเพิ่มการตรวจสอบความถูกต้องที่กำหนดเอง ฉันพยายามควบคุมให้ตัวควบคุมของฉันคงอยู่เพราะการใช้รหัสนี้เป็นเพียงตรรกะการตรวจสอบเท่านั้น: if (!ModelState.IsValid) return View(loginViewModel); ตัวอย่างเช่นโมเดลมุมมองล็อกอินใช้ IValidatableObject รับวัตถุ ILoginValidator ผ่านการสร้างคอนสตรัค: public interface ILoginValidator { bool UserExists(string email); bool IsLoginValid(string userName, string password); } ดูเหมือนว่า Ninject การฉีดอินสแตนซ์ในมุมมองแบบจำลองไม่ใช่วิธีปฏิบัติทั่วไปจริง ๆ อาจเป็นรูปแบบการต่อต้านหรือไม่ นี่เป็นวิธีที่ดีหรือไม่? มีดีกว่าไหม

5
การทำซ้ำรหัสกับวิธีที่รับผิดชอบหลายอย่าง
ฉันพยายามปฏิบัติตาม Single Responsibility Principle (SRP) และไม่ใช้ Code ซ้ำ อย่างไรก็ตามมักจะมีสถานที่ที่มีการทำซ้ำรหัสที่ไม่มีอะไรมากไปกว่าบล็อคโค้ดของการเรียกใช้ที่สามารถต้านทานการแตกออกเป็นอย่างน้อยแปลความหมายเต็มวิธีการชื่อ: DoAction1(); DoAction2(); if (value) DoAction3(); DoAction4(); เป็นวิธีที่ดีที่สุดในการแยกรหัสดังกล่าวเป็นวิธีการและวิธีการตั้งชื่อมันได้อย่างไร

6
ดิ้นรนกับหลักการความรับผิดชอบเดี่ยว
ลองพิจารณาตัวอย่างนี้: ฉันมีเว็บไซต์ ช่วยให้ผู้ใช้สามารถโพสต์ (สามารถเป็นอะไรก็ได้) และเพิ่มแท็กที่อธิบายโพสต์ ในรหัสฉันมีสองคลาสที่แสดงถึงการโพสต์และแท็ก ให้เรียกชั้นเรียนเหล่านี้และPostTag Postดูแลการสร้างโพสต์การลบโพสต์อัปเดตโพสต์ ฯลฯ Tagดูแลการสร้างแท็กการลบแท็กอัปเดตแท็ก ฯลฯ มีการดำเนินการหนึ่งอย่างที่ขาดหายไป การเชื่อมโยงแท็กกับโพสต์ ฉันกำลังดิ้นรนกับผู้ที่ควรดำเนินการนี้ มันสามารถเข้ากันได้ดีในระดับเดียวกัน ในอีกด้านหนึ่งPostคลาสอาจมีฟังก์ชันที่ใช้Tagเป็นพารามิเตอร์จากนั้นเก็บไว้ในรายการของแท็ก บนมืออื่น ๆ ที่Tagชั้นจะมีฟังก์ชั่นที่ใช้เวลาที่Postเป็นพารามิเตอร์และการเชื่อมโยงไปยังTagPost ด้านบนเป็นเพียงตัวอย่างของปัญหาของฉัน จริง ๆ แล้วฉันกำลังเจอกับหลายคลาสที่คล้ายกันทั้งหมด มันสามารถเข้ากันได้ดีกับทั้งคู่ ขาดฟังก์ชั่นการใช้งานจริงลงในทั้งสองคลาสการประชุมหรือสไตล์การออกแบบที่มีอยู่เพื่อช่วยฉันแก้ปัญหานี้ ฉันสมมติว่าจะต้องมีบางสิ่งที่ขาดไปจากการเลือก? บางทีการใส่ไว้ในทั้งสองคลาสเป็นคำตอบที่ถูกต้องหรือไม่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.