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

ผู้คนใช้เทคนิคการปฏิบัติอะไรเพื่อตรวจสอบว่าชั้นเรียนมีการละเมิดหลักการความรับผิดชอบเดียวหรือไม่? ฉันรู้ว่าชั้นเรียนควรมีเหตุผลเดียวเท่านั้นที่จะเปลี่ยน แต่ประโยคนั้นค่อนข้างขาดวิธีที่ใช้งานได้จริงเพื่อนำไปใช้จริง วิธีเดียวที่ฉันพบคือใช้ประโยค"......... ควร ......... ตัวเอง" โดยที่ช่องว่างแรกคือชื่อคลาสและต่อมาคือชื่อเมธอด (รับผิดชอบ) อย่างไรก็ตามบางครั้งก็ยากที่จะเข้าใจว่าความรับผิดชอบนั้นละเมิด SRP จริงหรือไม่ มีวิธีเพิ่มเติมในการตรวจสอบ SRP หรือไม่ บันทึก: คำถามไม่ได้เกี่ยวกับความหมายของ SRP แต่เป็นวิธีการปฏิบัติหรือชุดของขั้นตอนในการตรวจสอบและใช้ SRP UPDATE ฉันได้เพิ่มคลาสตัวอย่างที่ละเมิด SRP อย่างชัดเจน มันจะดีถ้าคนสามารถใช้มันเป็นตัวอย่างเพื่ออธิบายวิธีที่พวกเขาเข้าใกล้หลักการความรับผิดชอบเดียว ตัวอย่างจากที่นี่

11 design  design-patterns  object-oriented  refactoring  single-responsibility 

ฉันใหม่สำหรับการเขียนโปรแกรมเชิงวัตถุและฉันไม่เข้าใจว่าจุดประสงค์หลักของอะไร ใช่ฉันอ่านว่ามันเป็น "จุดเริ่มต้น" ของโปรแกรม แต่สิ่งที่ฉันไม่เข้าใจคือสิ่งที่ควรจะเป็นในหลัก และความรับผิดชอบของมันคืออะไร? อาจเกิดขึ้นว่าสิ่งที่เขียนในหลักอาจถูกห่อหุ้มในวัตถุอื่น แต่คุณควรใช้วิธีการนี้มากแค่ไหน? นี่คือหลักแรกของฉันที่ฉันเขียนใน Java มันง่ายมาก แต่อาจทำให้คุณเข้าใจข้อสงสัยของฉันดีขึ้น ฉันมีสัตว์ที่เป็นนามธรรมซึ่งขยายโดย "Cat" และ "Dog" ฉันใช้หลักในการสร้างวัตถุบางอย่างและยังเป็น "ส่วนต่อประสาน" กับผู้ใช้ด้วยอย่างที่คุณเห็นฉันใช้คำสั่งแบบมีเงื่อนไขเพื่อ "ถามผู้ใช้" สิ่งที่เขาต้องการจะทำ คำถามของฉันเกิดขึ้นจากความจริงที่ว่าอินเทอร์เฟซสามารถถูกห่อหุ้มในวัตถุอื่นและไม่ให้ความรับผิดชอบหลัก public static void main(String[] args) { Scanner input = new Scanner(System.in); System.out.println("What type of animal do you want to create? \n dog cat"); String type = input.nextLine(); if …

10 java  object-oriented  programming-practices  single-responsibility  entry-point 

ฉันมีฐานสองชั้นOperationและTrigger. แต่ละคนมีจำนวนคลาสย่อยที่เชี่ยวชาญในการดำเนินการหรือทริกเกอร์บางประเภท สามารถเรียกเฉพาะTrigger OperationขณะสามารถเรียกโดยเฉพาะเจาะจงOperationTrigger ฉันต้องเขียนโค้ดที่แม็พOperationกับที่ได้รับTrigger(หรือกลับกัน) แต่ฉันไม่แน่ใจว่าจะใส่ไว้ที่ไหน ในกรณีนี้รหัสไม่ได้เป็นของชั้นหนึ่งหรือชั้นอื่น ๆ อย่างชัดเจน ดังนั้นในแง่ของหลักการความรับผิดชอบเดี่ยวฉันไม่แน่ใจว่าควรจะใช้รหัสใด ฉันเห็นตัวเลือกสามตัวที่ใช้งานได้ทั้งหมด ในขณะที่ 1 & 2 ดูเหมือนจะเป็นทางเลือกของซีแมนทิกส์ แต่ 3 หมายถึงแนวทางที่แตกต่างอย่างสิ้นเชิง bool Triggers(Operation o)ทริกเกอร์เช่น bool TriggeredBy(Trigger t)วิธีการใช้งานเช่น bool MappingExists(Trigger t, Operation o)ในระดับใหม่ทั้งหมดซึ่งจัดการการทำแผนที่เช่น ฉันจะตัดสินใจได้อย่างไรว่าจะวางรหัสการแมปที่ใช้ร่วมกันอย่างไรในหลักการความรับผิดชอบเดียว วิธีการจัดการความรับผิดชอบเดียวเมื่อมีการแบ่งปันความรับผิดชอบ? แก้ไข 1 ดังนั้นรหัสจริงจะเป็นแบบนี้ คุณสมบัติทั้งหมดที่มีอย่างใดอย่างหนึ่งstring, Guid, หรือcollection<string> enumโดยพื้นฐานแล้วพวกเขาเป็นเพียงตัวแทนของข้อมูลขนาดเล็ก แก้ไข 2 สาเหตุของการส่งคืนชนิดบูล ชั้นอื่นจะไปกินคอลเลกชันของและคอลเลกชันของTrigger Operationมันต้องการที่จะทราบว่าการทำแผนที่ที่มีอยู่ระหว่างและTrigger Operationมันจะใช้ข้อมูลนั้นเพื่อสร้างรายงาน

10 object-oriented  single-responsibility 

ฉันอ่านClean Codeและบทความออนไลน์มากมายเกี่ยวกับ SOLID เมื่อเร็ว ๆ นี้และยิ่งฉันอ่านมากเท่าไหร่ฉันก็ยิ่งรู้สึกว่าไม่รู้อะไรเลย สมมติว่าผมสร้างโปรแกรมประยุกต์บนเว็บโดยใช้ ASP.NET MVC 3. สมมติว่าผมมีUsersControllerกับCreateการกระทำเช่นนี้ public class UsersController : Controller { public ActionResult Create(CreateUserViewModel viewModel) { } } ในวิธีการกระทำนั้นฉันต้องการบันทึกผู้ใช้ไปยังฐานข้อมูลหากข้อมูลที่ป้อนนั้นถูกต้อง ตอนนี้ตามหลักการความรับผิดชอบเดี่ยววัตถุควรมีความรับผิดชอบเดียวและความรับผิดชอบนั้นควรถูกห่อหุ้มทั้งหมดโดยชั้นเรียน บริการทั้งหมดของ บริษัท ควรสอดคล้องกับความรับผิดชอบนั้น เนื่องจากการตรวจสอบความถูกต้องและการบันทึกลงในฐานข้อมูลเป็นความรับผิดชอบที่แยกกันสองอย่างฉันจึงควรสร้างคลาสแยกต่างหากเพื่อจัดการกับสิ่งเหล่านี้: public class UsersController : Controller { private ICreateUserValidator validator; private IUserService service; public UsersController(ICreateUserValidator validator, IUserService service) { this.validator = …

10 object-oriented-design  solid  single-responsibility 

ในช่วงหลายเดือนที่ผ่านมาฉันขอคนที่นี่ทางทิศตะวันออกเฉียงใต้และในเว็บไซต์อื่น ๆ เสนอคำวิจารณ์ที่สร้างสรรค์เกี่ยวกับรหัสของฉัน มีสิ่งหนึ่งที่โผล่ออกมาเกือบทุกครั้งและฉันก็ยังไม่เห็นด้วยกับคำแนะนำนั้น : P ฉันต้องการที่จะพูดคุยที่นี่และบางทีสิ่งต่าง ๆ จะชัดเจนสำหรับฉัน มันเกี่ยวกับหลักการความรับผิดชอบเดี่ยว (SRP) โดยทั่วไปฉันมีคลาสข้อมูลFontที่ไม่เพียง แต่มีฟังก์ชั่นสำหรับจัดการข้อมูล แต่ยังสำหรับการโหลด ฉันบอกว่าทั้งสองควรแยกจากกันฟังก์ชั่นการโหลดควรอยู่ในคลาสของโรงงาน ฉันคิดว่านี่เป็นความผิดพลาดของ SRP ... ชิ้นส่วนจากคลาสแบบอักษรของฉัน class Font { public: bool isLoaded() const; void loadFromFile(const std::string& file); void loadFromMemory(const void* buffer, std::size_t size); void free(); void some(); void another(); }; การออกแบบที่แนะนำ class Font { public: void some(); …

10 design  c++  single-responsibility 

ฉันเขียนโค้ดจำนวนมากที่เกี่ยวข้องกับสามขั้นตอนพื้นฐาน รับข้อมูลจากที่อื่น แปลงข้อมูลนั้น วางข้อมูลนั้นไว้ที่ใดที่หนึ่ง ปกติแล้วฉันจะใช้คลาสสามประเภท - โดยได้แรงบันดาลใจจากรูปแบบการออกแบบที่เกี่ยวข้อง โรงงาน - เพื่อสร้างวัตถุจากทรัพยากรบางอย่าง ผู้ไกล่เกลี่ย - เพื่อใช้โรงงานทำการเปลี่ยนแปลงจากนั้นใช้ผู้บังคับบัญชา ผู้บังคับบัญชา - เพื่อใส่ข้อมูลนั้นไปที่อื่น ชั้นเรียนของฉันมักจะมีขนาดค่อนข้างเล็กมักเป็นวิธีเดียว (สาธารณะ) เช่นรับข้อมูลแปลงข้อมูลทำงานทำงานบันทึกข้อมูล สิ่งนี้นำไปสู่การเพิ่มจำนวนชั้นเรียน แต่โดยทั่วไปก็ใช้งานได้ดี ที่ฉันต้องดิ้นรนคือเมื่อฉันมาทดสอบฉันลงเอยด้วยการทดสอบที่รัดกุม ตัวอย่างเช่น; โรงงาน - อ่านไฟล์จากดิสก์ Commander - เขียนไฟล์ลงดิสก์ ฉันไม่สามารถทำการทดสอบได้หากไม่มีอันอื่น ฉันสามารถเขียนรหัส 'ทดสอบ' เพิ่มเติมเพื่อทำดิสก์อ่าน / เขียนได้ แต่จากนั้นฉันก็ทำซ้ำตัวเอง เมื่อดูที่. Net คลาสFileจะใช้วิธีการที่แตกต่างกันโดยจะรวมความรับผิดชอบของโรงงานและผู้บังคับบัญชาเข้าด้วยกัน มันมีฟังก์ชั่นสำหรับการสร้างลบอยู่และอ่านทั้งหมดในที่เดียว ฉันควรมองหาที่จะทำตามตัวอย่างของ. Net และการรวมกันโดยเฉพาะอย่างยิ่งเมื่อจัดการกับทรัพยากรภายนอก - คลาสของฉันด้วยกันไหม? รหัสนั้นยังคงอยู่คู่กัน แต่มันมีความตั้งใจมากกว่า - มันเกิดขึ้นที่การใช้งานดั้งเดิมมากกว่าในการทดสอบ ปัญหาของฉันที่นี่ที่ฉันได้ใช้หลักการความรับผิดชอบเดียวค่อนข้าง …

9 design  clean-code  single-responsibility 

แบบนี้: Campaign: type: object properties: id: type: string description: "A GUID identifier" referenceId: type: string description: "A consumers identifier they have used to map their own systems logic to this object." name: type: string description: "'Great Campaign 2017' as an example" ผมกังวลเกี่ยวกับreferenceid โดเมนระบบเป็นแพลตฟอร์มที่รวมเข้ากับบุคคลที่สามได้หลายวิธีผ่านการส่งออกข้อมูลและการนำเข้ารูปแบบต่างๆ (xml, excel) เป็นผู้ใหญ่พอที่จะอนุญาตให้บุคคลที่ 3 รวมกับระบบของเราผ่าน API และการออกแบบของ …

9 rest  api  domain-driven-design  api-design  single-responsibility 

ฉันกำลังดูที่การออกแบบส่วนต่อประสานของฉันและฉันพยายามที่จะตัดสินใจว่าวิธีใดที่ "ถูกต้อง" ที่สุดในการใช้การควบคุมการเข้าถึงตามบทบาทซึ่งกำหนดไว้userและสิ่งsubjectที่userต้องการเข้าถึง เท่าที่ฉันเห็นฉันมีสามตัวเลือกหลัก (ที่สี่เป็นลูกครึ่งของสามสามและห้าเป็นบิดของสี่): ค้นหาsubjectด้วยรายการสิทธิ์ที่userมี -subject.allowAccess(user.getPermissionSet) ค้นหาuserด้วยรายการสิทธิ์ที่subjectต้องการ -user.hasPermissionTo(subject.getRequiredPermissions()) สอบถามบุคคลที่สามเพื่อค้นหาจุดตัดสิทธิ์ - accessController.doPermissionSetsIntersect(subject.permissionSet, user.getPermissionSet()) ค้นหาทั้งsubject/ userในขณะที่มอบหมาย "การตัดสินใจ" ให้กับบุคคลที่สามชั้น มีuserความพยายามในการเข้าถึงsubjectและโยนข้อผิดพลาดหากไม่ได้รับอนุญาต ฉันกำลังเอนเอียงไปทางตัวเลือกที่สี่ - มีsubjectประกอบด้วยaccessControllerข้อมูลที่โทรไปยังsubject.userMayAccess(User user)มอบหมายการดำเนินการแบบ a la: class Subject { public function display(user) { if(!accessController.doPermissionSetsIntersect(this.permissionSet, user.getPermissionSet())) { display403(); //Or other.. eg, throw an error.. } } } .. แต่เมื่อถามคำถามเพิ่มเติม: accessControllerฟิลด์ควรเป็นคลาสคงที่ .. ควรsubject รู้ว่าต้องใช้การอนุญาตใดเพื่อให้สามารถดูได้ …

9 design  single-responsibility  access-control 

ฉันได้เติบโตขึ้นโดยใช้หลักการในการออกแบบและใช้งานส่วนต่อประสานที่พูดโดยทั่วไปว่า "ถามเฉพาะสิ่งที่คุณต้องการ" ตัวอย่างเช่นหากฉันมีประเภทที่สามารถลบได้มากมายฉันจะสร้างDeletableส่วนต่อประสาน: interface Deletable { void delete(); } จากนั้นฉันสามารถเขียนคลาสสามัญ: class Deleter<T extends Deletable> { void delete(T t) { t.delete(); } } ที่อื่นในรหัสฉันมักจะถามถึงความรับผิดชอบที่เล็กที่สุดที่เป็นไปได้เพื่อตอบสนองความต้องการของรหัสลูกค้า ดังนั้นถ้าฉันจะต้องลบFileก็ยังจะขอไม่ได้ DeletableFile หลักการนี้เป็นความรู้ทั่วไปและมีชื่อยอมรับแล้วหรือไม่? มันขัดแย้งหรือไม่ มันถูกกล่าวถึงในตำราหรือไม่?

9 object-oriented  interfaces  solid  single-responsibility