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

ดูเหมือนชัดเจนว่า "หลักการความรับผิดชอบเดี่ยว" ไม่ได้หมายความว่า "ทำเพียงสิ่งเดียวเท่านั้น" นั่นคือวิธีการที่ใช้ public Interface CustomerCRUD { public void Create(Customer customer); public Customer Read(int CustomerID); public void Update(Customer customer); public void Delete(int CustomerID); } บ็อบมาร์ตินกล่าวว่า "คลาสควรมีเหตุผลเดียวเท่านั้นที่จะเปลี่ยนแปลง" แต่นั่นเป็นเรื่องยากที่จะทำให้คุณคิดมากหากคุณเป็นโปรแกรมเมอร์ใหม่สำหรับ SOLID ฉันเขียนคำตอบสำหรับคำถามอื่นที่ฉันแนะนำว่าความรับผิดชอบเป็นเหมือนชื่องานและเต้นไปรอบ ๆ หัวเรื่องโดยใช้อุปมาอุปไมยในร้านอาหารเพื่ออธิบายประเด็นของฉัน แต่นั่นก็ไม่ได้เป็นชุดของหลักการที่บางคนสามารถใช้เพื่อกำหนดความรับผิดชอบของชั้นเรียนของพวกเขา แล้วคุณจะทำอย่างไร คุณจะกำหนดความรับผิดชอบอย่างไรในแต่ละชั้นเรียนและคุณกำหนดความรับผิดชอบอย่างไรในบริบทของ SRP

198 architecture  class-design  solid  single-responsibility 

ฉันพยายามปฏิบัติตาม Single Responsibility Principle (SRP) ให้มากที่สุดเท่าที่จะเป็นไปได้และคุ้นเคยกับรูปแบบที่แน่นอน (สำหรับ SRP เกี่ยวกับวิธีการ) อาศัยการมอบหมายอย่างมาก ฉันต้องการทราบว่าวิธีการนี้เป็นวิธีที่ดีหรือหากมีปัญหารุนแรงกับมัน ตัวอย่างเช่นในการตรวจสอบอินพุตให้กับ constructor ฉันสามารถแนะนำวิธีต่อไปนี้ ( Streamอินพุตเป็นแบบสุ่มอาจเป็นอะไรก็ได้) private void CheckInput(Stream stream) { if(stream == null) { throw new ArgumentNullException(); } if(!stream.CanWrite) { throw new ArgumentException(); } } วิธีนี้ (arguably) ทำมากกว่าหนึ่งอย่าง ตรวจสอบอินพุต โยนข้อยกเว้นที่แตกต่างกัน เพื่อให้เป็นไปตาม SRP ฉันจึงเปลี่ยนตรรกะเป็น private void CheckInput(Stream stream, params (Predicate<Stream> …

66 c#  single-responsibility 

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

64 solid  single-responsibility 

วันนี้ฉันมีข้อโต้แย้งกับใครบางคน ฉันอธิบายถึงประโยชน์ของการมีรูปแบบโดเมนที่หลากหลายซึ่งต่างจากแบบจำลองโดเมนแบบโลหิตจาง และฉันสาธิตจุดของฉันด้วยคลาสที่เรียบง่ายที่ดูเหมือนว่า: public class Employee { public Employee(string firstName, string lastName) { FirstName = firstName; LastName = lastname; } public string FirstName { get private set; } public string LastName { get; private set;} public int CountPaidDaysOffGranted { get; private set;} public void AddPaidDaysOffGranted(int numberOfdays) { // Do stuff …

63 c#  object-oriented  single-responsibility 

สรุปปัญหา: เรื่องสั้นสั้นฉันได้รับรหัสฐานและทีมพัฒนาที่ฉันไม่ได้รับอนุญาตให้แทนที่และการใช้ God Objects เป็นปัญหาใหญ่ ก้าวไปข้างหน้าฉันต้องการให้เราทำปัจจัยอีกครั้ง แต่ฉันได้รับการผลักดันกลับจากทีมที่ต้องการทำทุกอย่างกับ God Objects "เพราะมันง่ายกว่า" และนี่หมายความว่าฉันจะไม่ได้รับอนุญาตให้ทำปัจจัยอีกครั้ง ฉันผลักดันการอ้างอิงประสบการณ์การพัฒนาเป็นเวลาหลายปีว่าฉันเป็นเจ้านายคนใหม่ที่ได้รับการว่าจ้างให้รู้จักสิ่งเหล่านี้และอื่น ๆ บริษัท ภายนอกในต่างประเทศทำบัญชีตัวแทนฝ่ายขายและตอนนี้อยู่ในระดับผู้บริหารและการประชุมของฉัน เป็นวันพรุ่งนี้และฉันต้องการที่จะใช้กระสุนทางเทคนิคจำนวนมากเพื่อสนับสนุนการปฏิบัติที่ดีที่สุดเพราะฉันรู้สึกว่ามันจะถูกลงในระยะยาว (และโดยส่วนตัวฉันรู้สึกว่าเป็นสิ่งที่บุคคลที่สามเป็นห่วง) สำหรับ บริษัท ปัญหาของฉันมาจากระดับเทคนิคฉันรู้ดีในระยะยาว แต่ฉันมีปัญหากับระยะสั้นพิเศษและ 6 เดือนในขณะที่บางสิ่งที่ฉัน "รู้" ฉันไม่สามารถพิสูจน์ได้ด้วยการอ้างอิงและแหล่งอ้างอิงภายนอก ของคนคนหนึ่ง (Robert C. Martin หรือลุงลุง Bob) นั่นคือสิ่งที่ฉันถูกขอให้ทำเพราะฉันได้รับการบอกว่ามีข้อมูลจากบุคคลหนึ่งและมีเพียงคนเดียวเท่านั้น (Robert C Martin) ไม่ดีพอที่จะโต้แย้ง . คำถาม: มีแหล่งข้อมูลอะไรบ้างที่ฉันสามารถอ้างอิงได้โดยตรง (ชื่อเรื่อง, ปีที่พิมพ์, หมายเลขหน้า, คำพูด) โดยผู้เชี่ยวชาญที่รู้จักกันดีในสาขาที่กล่าวอย่างชัดเจนว่าการใช้ "พระเจ้า" วัตถุ / คลาส / ระบบนี้ไม่ดี …

56 object-oriented  class  object  single-responsibility 

ฉันกำลังทำงานกับทีมที่หัวหน้าทีมเป็นผู้สนับสนุนหลักการการพัฒนาที่มั่นคง อย่างไรก็ตามเขาขาดประสบการณ์จำนวนมากในการนำซอฟต์แวร์ที่ซับซ้อนออกจากประตู เรามีสถานการณ์ที่เขาใช้ SRP กับสิ่งที่เคยเป็นฐานรหัสที่ซับซ้อนอยู่แล้วซึ่งตอนนี้มีการแยกส่วนสูงมากและยากที่จะเข้าใจและตรวจแก้จุดบกพร่อง ตอนนี้เรามีปัญหาไม่เพียง แต่กับการกระจายตัวของรหัส แต่ยังรวมถึงการห่อหุ้มเป็นวิธีการภายในชั้นเรียนที่อาจเป็นส่วนตัวหรือได้รับการป้องกันได้รับการพิจารณาเพื่อเป็นตัวแทนของ 'เหตุผลในการเปลี่ยนแปลง' และได้รับการสกัด ไม่สอดคล้องกับเป้าหมายการห่อหุ้มของแอปพลิเคชัน เรามีตัวสร้างคลาสที่ใช้พารามิเตอร์อินเทอร์เฟซมากกว่า 20 ตัวดังนั้นการลงทะเบียน IoC และการแก้ปัญหาของเราจึงกลายเป็นสัตว์ประหลาดในตัวของมันเอง ฉันต้องการทราบว่ามี 'refactor อยู่ห่างจาก SRP' หรือไม่ที่เราสามารถใช้เพื่อช่วยแก้ไขปัญหาเหล่านี้ได้ ฉันได้อ่านแล้วว่ามันไม่ได้เป็นการละเมิด SOLID ถ้าฉันสร้างคลาสที่ว่างเปล่าแบบหยาบจำนวนมากที่ 'ห่อ' คลาสที่เกี่ยวข้องอย่างใกล้ชิดเพื่อให้เข้าถึงจุดรวมการทำงานของจุดเดียว (เช่นการเลียนแบบน้อย ใช้งานคลาสมากเกินไป SRP) นอกจากนั้นฉันไม่สามารถคิดถึงวิธีแก้ปัญหาที่จะช่วยให้เราสามารถดำเนินการต่อไปในการพัฒนาของเราในทางปฏิบัติในขณะที่ทำให้ทุกคนมีความสุข ข้อเสนอแนะใด ๆ

56 c#  wpf  inversion-of-control  single-responsibility 

ในช่วงไม่กี่ปีที่ผ่านมาเราได้ค่อยๆเปลี่ยนไปใช้โค้ดที่ดีขึ้นอย่างค่อยเป็นค่อยไปในเวลาไม่กี่ก้าว ในที่สุดเราก็เริ่มที่จะเปลี่ยนไปใช้สิ่งที่คล้ายกับ SOLID อย่างน้อยที่สุด แต่เรายังไม่ถึงจุดนั้น นับตั้งแต่ทำการสลับหนึ่งในข้อร้องเรียนที่ใหญ่ที่สุดจากนักพัฒนาคือพวกเขาไม่สามารถยืนทบทวนและตรวจสอบไฟล์หลายสิบไฟล์ซึ่งก่อนหน้านี้ทุกงานต้องการเพียงผู้พัฒนาที่สัมผัส 5-10 ไฟล์ ก่อนที่จะเริ่มสวิตช์สถาปัตยกรรมของเราได้รับการจัดระเบียบอย่างดีดังต่อไปนี้ (ให้สิทธิ์โดยมีหนึ่งหรือสองไฟล์ที่มีขนาดมากกว่าหนึ่งคำสั่ง): Solution - Business -- AccountLogic -- DocumentLogic -- UsersLogic - Entities (Database entities) - Models (Domain Models) - Repositories -- AccountRepo -- DocumentRepo -- UserRepo - ViewModels -- AccountViewModel -- DocumentViewModel -- UserViewModel - UI ไฟล์ฉลาดทุกอย่างเป็นเส้นตรงและกะทัดรัดอย่างเหลือเชื่อ เห็นได้ชัดว่ามีการทำสำเนารหัสจำนวนมากการมีเพศสัมพันธ์อย่างแน่นหนาและปวดหัวอย่างไรก็ตามทุกคนสามารถเข้าไปสำรวจและคิดออกได้ สามเณรที่สมบูรณ์ผู้ที่ไม่เคยเปิด Visual Studio …

49 c#  coding-style  dependency-injection  solid  single-responsibility 

ฉันสงสัยอยู่ตลอดว่าจะใช้กริยาที่ถูกต้องตามคำนามใน OOP หรือไม่ ฉันเจอบทความที่ยอดเยี่ยมนี้แต่ฉันก็ยังไม่เห็นด้วยกับประเด็นที่ทำ เพื่ออธิบายปัญหาที่เกิดขึ้นอีกเล็กน้อยรัฐบทความที่ว่ามีไม่ควรจะเป็นตัวอย่างเช่นFileWriterชั้น แต่เนื่องจากการเขียนคือการกระทำที่มันควรจะเป็นวิธีการFileของการเรียน คุณจะได้รับรู้ว่ามันมักจะขึ้นอยู่กับภาษาเนื่องจากโปรแกรมเมอร์ Ruby อาจต่อต้านการใช้FileWriterคลาส (Ruby ใช้วิธีFile.openการเข้าถึงไฟล์) ในขณะที่โปรแกรมเมอร์ Java ไม่ต้องการ มุมมองส่วนบุคคลของฉัน (และใช่ต่ำต้อยมาก) คือการทำเช่นนั้นจะทำลายหลักการความรับผิดชอบเดี่ยว เมื่อฉันตั้งโปรแกรมใน PHP (เพราะเห็นได้ชัดว่า PHP เป็นภาษาที่ดีที่สุดสำหรับ OOP ใช่มั้ย) ฉันมักจะใช้เฟรมเวิร์กประเภทนี้: <?php // This is just an example that I just made on the fly, may contain errors class User extends Record { protected $name; public …

42 object-oriented  solid  single-responsibility 

ฉันเพิ่งมาโดยปัญหาสถาปัตยกรรมที่ดูเหมือนเล็กน้อย ฉันมีพื้นที่เก็บข้อมูลอย่างง่ายในรหัสของฉันที่ถูกเรียกเช่นนี้ (รหัสเป็น C #): var user = /* create user somehow */; _userRepository.Add(user); /* do some other stuff*/ _userRepository.SaveChanges(); SaveChanges เป็น wrapper ง่ายๆที่ยอมรับการเปลี่ยนแปลงในฐานข้อมูล: void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); } หลังจากนั้นครู่หนึ่งฉันจำเป็นต้องใช้ตรรกะใหม่ที่จะส่งการแจ้งเตือนทางอีเมลทุกครั้งที่ผู้ใช้ถูกสร้างขึ้นในระบบ เนื่องจากมีการโทรเข้า_userRepository.Add()และออกSaveChangesจากระบบจำนวนมากฉันจึงตัดสินใจอัปเดตSaveChangesดังนี้: void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); foreach (var newUser …

40 architecture  single-responsibility  event 

ฉันมีวิธีที่อัปเดตข้อมูลพนักงานในฐานข้อมูล Employeeชั้นจะไม่เปลี่ยนรูปเพื่อ "ปรับปรุง" วัตถุหมายถึงจริงยกตัวอย่างวัตถุใหม่ ฉันต้องการให้Updateวิธีการส่งคืนอินสแตนซ์ใหม่Employeeด้วยข้อมูลที่อัปเดต แต่เนื่องจากตอนนี้ฉันสามารถพูดได้ว่าความรับผิดชอบของวิธีนี้คือการอัปเดตข้อมูลพนักงานและการดึงข้อมูลจากฐานข้อมูลเป็นEmployeeวัตถุใหม่มันละเมิดหลักการความรับผิดชอบเดี่ยวหรือไม่ มีการอัปเดตระเบียน DB เอง จากนั้นวัตถุใหม่จะถูกสร้างอินสแตนซ์เพื่อแสดงระเบียนนี้

37 single-responsibility 

ตามเอกสารของ Microsoft บทความ Wikipedia SOLID principe หรือสถาปนิกด้านไอทีส่วนใหญ่เราต้องตรวจสอบให้แน่ใจว่าแต่ละชั้นมีหน้าที่รับผิดชอบเพียงอย่างเดียว ฉันอยากจะรู้ว่าทำไมเพราะถ้าทุกคนดูเหมือนจะเห็นด้วยกับกฎนี้ดูเหมือนจะไม่มีใครเห็นด้วยกับเหตุผลของกฎนี้ บางคนกล่าวถึงการบำรุงรักษาที่ดีกว่าบางคนบอกว่าเป็นการทดสอบที่ง่ายหรือทำให้ชั้นเรียนมีความแข็งแกร่งมากขึ้นหรือมีความปลอดภัย อะไรถูกและจริงหมายถึงอะไร ทำไมจึงทำให้การบำรุงรักษาดีขึ้นการทดสอบง่ายขึ้นหรือรหัสมีเสถียรภาพมากขึ้น?

37 design-patterns  architecture  solid  single-responsibility 

หลักการความรับผิดชอบเดี่ยวอยู่บนพื้นฐานของหลักการทำงานร่วมกันสูง ความแตกต่างระหว่างทั้งสองคือคลาสที่มีความเหนียวแน่นสูงมีชุดของความรับผิดชอบที่เกี่ยวข้องอย่างมากในขณะที่คลาสที่ใช้ SRP มีความรับผิดชอบเพียงอย่างเดียว แต่เราจะตัดสินได้อย่างไรว่าคลาสใดมีคุณสมบัติของชุดความรับผิดชอบและมีความสอดคล้องสูงหรือมีความรับผิดชอบเพียงอย่างเดียวและสอดคล้องกับ SRP หรือไม่ กล่าวอีกนัยหนึ่งมันไม่ได้เป็นอัตวิสัยมากกว่าหรือน้อยกว่าเนื่องจากบางคนอาจมองว่าคลาสนั้นมีความละเอียดมาก (และจะเชื่อว่าคลาสนั้นเป็นไปตาม SRP) ในขณะที่คนอื่น ๆ อาจคิดว่ามันไม่ละเอียดเพียงพอ

34 design-patterns  single-responsibility  cohesion 

ต้องการปรับปรุงโพสต์นี้หรือไม่? ให้คำตอบโดยละเอียดสำหรับคำถามนี้รวมถึงการอ้างอิงและคำอธิบายว่าทำไมคำตอบของคุณถึงถูกต้อง คำตอบที่ไม่มีรายละเอียดเพียงพออาจแก้ไขหรือลบออกได้ คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่ผ่านมา เพื่อประโยชน์ของการโต้แย้งนี่คือตัวอย่างฟังก์ชั่นที่พิมพ์เนื้อหาของไฟล์ที่กำหนดทีละบรรทัด รุ่น 1: void printFile(const string & filePath) { fstream file(filePath, ios::in); string line; while (std::getline(file, line)) { cout << line << endl; } } ฉันรู้ว่าขอแนะนำให้ฟังก์ชั่นทำสิ่งหนึ่งที่ระดับหนึ่งของสิ่งที่เป็นนามธรรม สำหรับฉันแม้ว่าโค้ดด้านบนจะทำสิ่งหนึ่งและค่อนข้างปรมาณู หนังสือบางเล่ม (เช่น Clean Code ของ Robert C. Martin) ดูเหมือนจะแนะนำให้แบ่งรหัสด้านบนออกเป็นฟังก์ชันแยกต่างหาก …

21 c++  coding-style  single-responsibility 

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

20 design-patterns  single-responsibility 

a) ความแตกต่างระหว่างSRPและSoCคืออะไร? บางทีนั่นอาจจะSRPถูกนำไปใช้ในระดับชั้นในขณะที่SoCสามารถนำมาใช้ในระบบ , ระบบย่อย , โมดูล , ระดับหรือฟังก์ชั่นระดับ b) ถ้าคำตอบต่อa)ใช่แล้วSoC จะใช้คำพ้องความหมายสำหรับSRPในระดับชั้นเรียนหรือไม่? ขอขอบคุณ

19 design-patterns  single-responsibility