คำถามติดแท็ก solid

ดูเหมือนชัดเจนว่า "หลักการความรับผิดชอบเดี่ยว" ไม่ได้หมายความว่า "ทำเพียงสิ่งเดียวเท่านั้น" นั่นคือวิธีการที่ใช้ 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 

ในการสัมภาษณ์งานเมื่อเร็ว ๆ นี้ฉันไม่สามารถตอบคำถามเกี่ยวกับSOLID ได้นอกเหนือจากการให้ความหมายพื้นฐานของหลักการต่าง ๆ มันทำให้ฉันเป็นโรคจิตจริงๆ ฉันได้ขุดไปสองสามวันแล้วและยังไม่ได้ข้อสรุปที่น่าพอใจ คำถามสัมภาษณ์คือ: หากคุณกำลังดูโครงการ. Net ที่ฉันบอกคุณว่าปฏิบัติตามหลักการของ SOLID อย่างเคร่งครัดคุณคาดหวังอะไรในแง่ของโครงการและโครงสร้างโค้ด ฉันดิ้นรนนิดหน่อยไม่ตอบคำถามจริงๆแล้วก็ระเบิดออกมา ฉันจะจัดการคำถามนี้ได้ดีขึ้นได้อย่างไร

150 c#  .net  solid 

สมมติว่าเรามีรายการของเอนทิตีงานและProjectTaskประเภทย่อย สามารถปิดงานได้ตลอดเวลายกเว้นงานProjectTasksที่ไม่สามารถปิดได้เมื่อพวกเขามีสถานะเป็นเริ่มต้น UI ควรตรวจสอบให้แน่ใจว่าไม่มีตัวเลือกในการปิดการเริ่มต้นทำงานProjectTaskแต่มีการป้องกันบางอย่างในโดเมน: public class Task { public Status Status { get; set; } public virtual void Close() { Status = Status.Closed; } } public class ProjectTask : Task { public override void Close() { if (Status == Status.Started) throw new Exception("Cannot close a started Project Task"); base.Close(); } …

132 design  object-oriented-design  solid  liskov-substitution 

หาก Square เป็นรูปแบบสี่เหลี่ยมผืนผ้ากว่าเหตุใด Square จึงไม่สามารถสืบทอดจากสี่เหลี่ยมผืนผ้าได้ หรือทำไมมันถึงออกแบบไม่ดี? ฉันเคยได้ยินคนพูดว่า: หากคุณกำหนดให้ Square ได้รับมาจากสี่เหลี่ยมผืนผ้าดังนั้น Square ควรใช้งานได้ทุกที่ที่คุณคาดว่าสี่เหลี่ยมผืนผ้า ปัญหาคืออะไรที่นี่? และทำไม Square ถึงใช้งานได้ทุกที่ที่คุณคาดหวังสี่เหลี่ยมผืนผ้า? มันจะใช้งานได้เฉพาะเมื่อเราสร้างวัตถุสแควร์และถ้าเราแทนที่วิธี SetWidth และ SetHeight สำหรับสแควร์กว่าทำไมจะมีปัญหาใด ๆ ? ถ้าคุณมีเมธอด SetWidth และ SetHeight บนคลาสพื้นฐานสี่เหลี่ยมผืนผ้าของคุณและถ้าการอ้างอิงสี่เหลี่ยมผืนผ้าของคุณชี้ไปที่สแควร์แล้ว SetWidth และ SetHeight ไม่สมเหตุสมผลเนื่องจากการตั้งค่าอย่างใดอย่างหนึ่งจะเปลี่ยนอีกเพื่อให้ตรงกับมัน ในกรณีนี้สแควร์ล้มเหลวการทดสอบการทดแทน Liskov ด้วยสี่เหลี่ยมผืนผ้าและนามธรรมของการมีการสืบทอดสแควร์จากสี่เหลี่ยมผืนผ้าเป็นสิ่งที่ไม่ดี บางคนสามารถอธิบายข้อโต้แย้งข้างต้นได้หรือไม่ อีกครั้งถ้าเราใช้วิธี SetWidth และ SetHeight มากเกินไปใน Square มันจะไม่แก้ไขปัญหานี้หรือไม่ ฉันเคยได้ยิน / อ่านด้วย: ปัญหาที่แท้จริงคือเราไม่ได้สร้างโมเดลสี่เหลี่ยมผืนผ้า แต่เป็น "สี่เหลี่ยมที่ปรับเปลี่ยนได้" เช่นสี่เหลี่ยมที่มีความกว้างหรือความสูงสามารถปรับเปลี่ยนได้หลังจากการสร้าง …

105 object-oriented-design  inheritance  abstraction  solid 

ฉันชอบ SOLID และฉันพยายามอย่างดีที่สุดที่จะใช้และนำไปใช้เมื่อฉันกำลังพัฒนา แต่ฉันอดไม่ได้ที่จะรู้สึกราวกับว่าแนวทางของ SOLID จะเปลี่ยนรหัสของคุณให้เป็นรหัส 'framework' - เช่นรหัสที่คุณต้องการออกแบบหากคุณสร้างเฟรมเวิร์กหรือไลบรารีเพื่อให้นักพัฒนารายอื่นใช้ โดยทั่วไปฉันได้ฝึกการเขียนโปรแกรม 2 โหมด - การสร้างสิ่งที่ถามผ่านข้อกำหนดและ KISS (การเขียนโปรแกรมทั่วไป) มากขึ้นหรือน้อยลงหรือการสร้างตรรกะบริการและอื่น ๆ ที่ใช้ซ้ำทั่วไปและนำกลับมาใช้ใหม่ได้ . หากผู้ใช้ต้องการให้แอปพลิเคชันทำสิ่ง x และ y จริง ๆ มันสมเหตุสมผลหรือไม่ที่จะต้องติดตาม SOLID และเพิ่มจุดเริ่มต้นที่เป็นนามธรรมทั้งหมดเมื่อคุณไม่รู้ด้วยซ้ำว่าเป็นปัญหาที่ถูกต้องหรือไม่ ด้วย? หากคุณเพิ่มจุดเริ่มต้นของสิ่งที่เป็นนามธรรมคุณจะปฏิบัติตามข้อกำหนดของผู้ใช้จริง ๆ หรือคุณสร้างกรอบงานด้านบนของเฟรมเวิร์กที่มีอยู่และสแต็คเทคโนโลยีเพื่อให้การเพิ่มในอนาคตง่ายขึ้นหรือไม่? ในกรณีใดบ้างที่คุณให้บริการเพื่อผลประโยชน์ของลูกค้าหรือของผู้พัฒนา นี่เป็นสิ่งที่ดูเหมือนว่าเป็นเรื่องธรรมดาในโลกของ Java Enterprise ที่ให้ความรู้สึกราวกับว่าคุณกำลังออกแบบเฟรมเวิร์กของคุณเองบน J2EE หรือ Spring ดังนั้นมันจึงเป็น UX ที่ดีกว่าสำหรับนักพัฒนาแทนที่จะมุ่งเน้นที่ UX สำหรับผู้ใช้

70 frameworks  solid 

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

64 solid  single-responsibility 

ดูเหมือนว่า Java มีอำนาจในการประกาศคลาสที่ไม่สามารถสืบทอดได้สำหรับทุกวัยและตอนนี้ C ++ ก็มีเช่นกัน อย่างไรก็ตามในแง่ของหลักการ Open / Close ใน SOLID ทำไมมันถึงมีประโยชน์? สำหรับฉันfinalคำหลักฟังดูเหมือนfriend- ถูกกฎหมาย แต่ถ้าคุณใช้งานอยู่การออกแบบส่วนใหญ่อาจผิด โปรดให้ตัวอย่างที่คลาสที่ไม่สามารถสืบทอดได้จะเป็นส่วนหนึ่งของสถาปัตยกรรมที่ดีหรือรูปแบบการออกแบบ

54 java  c++  solid  final 

โครงการส่วนใหญ่ที่ฉันทำงานพิจารณาการพัฒนาและการทดสอบหน่วยในการแยกซึ่งทำให้การทดสอบหน่วยการเขียนในภายหลังเป็นฝันร้าย วัตถุประสงค์ของฉันคือการทดสอบในใจในระหว่างขั้นตอนการออกแบบระดับสูงและระดับต่ำเอง ฉันต้องการทราบว่ามีหลักการออกแบบที่กำหนดไว้อย่างดีซึ่งส่งเสริมรหัสที่สามารถทดสอบได้หรือไม่ หนึ่งในหลักการดังกล่าวที่ฉันได้เข้าใจเมื่อเร็ว ๆ นี้คือการพึ่งพิงการพึ่งพาผ่านการฉีดการพึ่งพาและการกลับควบคุม ฉันได้อ่านแล้วว่ามีบางสิ่งที่เรียกว่าโซลิด ฉันต้องการที่จะเข้าใจว่าหากทำตามหลักการของ SOLID จะส่งผลทางอ้อมในรหัสที่สามารถทดสอบได้ง่ายหรือไม่? ถ้าไม่มีมีหลักการออกแบบที่ชัดเจนที่ส่งเสริมรหัสที่สามารถทดสอบได้หรือไม่ ฉันรู้ว่ามีบางสิ่งที่เรียกว่าการทดสอบพัฒนา แม้ว่าฉันจะสนใจการออกแบบโค้ดโดยคำนึงถึงการทดสอบในระหว่างขั้นตอนการออกแบบเองมากกว่าที่จะผลักดันการออกแบบผ่านการทดสอบ ฉันหวังว่านี่จะสมเหตุสมผล อีกหนึ่งคำถามที่เกี่ยวข้องกับหัวข้อนี้คือไม่ว่าจะเป็นปัจจัยใหม่ผลิตภัณฑ์ / โครงการที่มีอยู่และทำการเปลี่ยนแปลงรหัสและการออกแบบเพื่อวัตถุประสงค์ในการสามารถเขียนกรณีทดสอบหน่วยสำหรับแต่ละโมดูล?

54 unit-testing  tdd  solid 

วัตถุประสงค์ของ IOC Containers คืออะไร? เหตุผลที่รวมกันสามารถทำให้เป็นดังต่อไปนี้: เมื่อใช้หลักการพัฒนา OOP / SOLID การพึ่งพาการฉีดจะทำให้เกิดความยุ่งเหยิง ไม่ว่าคุณจะมีจุดเริ่มต้นระดับสูงสุดที่จัดการการพึ่งพาสำหรับหลายระดับต่ำกว่าตนเองและผ่านการอ้างอิงซ้ำผ่านการก่อสร้างซ้ำหรือคุณมีรหัสที่ซ้ำกันในรูปแบบโรงงาน / ผู้สร้างและอินเตอร์เฟสที่สร้างการพึ่งพาตามที่คุณต้องการ ไม่มีวิธี OOP / SOLID ในการดำเนินการนี้และมีรหัสสวยมาก หากข้อความก่อนหน้านั้นเป็นจริงแล้วตู้คอนเทนเนอร์ IOC จะทำอย่างไร เท่าที่ฉันรู้พวกเขาไม่ได้ใช้เทคนิคที่ไม่รู้จักบางอย่างที่ไม่สามารถทำได้ด้วยตนเอง DI ดังนั้นการอธิบายเพียงอย่างเดียวคือ IOC Containers ทำลายหลักการ OOP / SOLID โดยการใช้อ็อบเจกต์ส่วนตัวแบบคงที่ ตู้ IOC ทำลายหลักการต่อไปนี้หรือไม่? นี่เป็นคำถามจริงเนื่องจากฉันมีความเข้าใจที่ดี แต่มีความรู้สึกว่ามีคนอื่นมีความเข้าใจที่ดีขึ้น: การควบคุมขอบเขต ขอบเขตคือเหตุผลสำหรับเกือบทุกการตัดสินใจของฉันในการออกแบบรหัสของฉัน บล็อกท้องถิ่นโมดูลคงที่ / ทั่วโลก ขอบเขตควรชัดเจนมากที่สุดเท่าที่ระดับบล็อกและน้อยที่สุดที่คงที่ที่สุด คุณควรเห็นการประกาศการสร้างอินสแตนซ์และการสิ้นสุดวงจรชีวิต ฉันเชื่อมั่นในภาษาและ GC ในการจัดการขอบเขตตราบใดที่ฉันชัดเจนด้วย จากการวิจัยของฉันฉันพบว่า IOC Containers ตั้งค่าการพึ่งพาส่วนใหญ่หรือทั้งหมดเป็นแบบคงที่และควบคุมพวกมันผ่านการใช้งาน …

51 object-oriented  solid  inversion-of-control 

ในช่วงไม่กี่ปีที่ผ่านมาเราได้ค่อยๆเปลี่ยนไปใช้โค้ดที่ดีขึ้นอย่างค่อยเป็นค่อยไปในเวลาไม่กี่ก้าว ในที่สุดเราก็เริ่มที่จะเปลี่ยนไปใช้สิ่งที่คล้ายกับ 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 และฉันได้ข้อสรุปว่า LSP และ OCP มีความคล้ายคลึงกัน (ถ้าไม่พูดมากกว่านี้) หลักการเปิด / ปิดระบุ "เอนทิตีของซอฟต์แวร์ (คลาส, โมดูล, ฟังก์ชั่น, อื่น ๆ ) ควรจะเปิดสำหรับการขยาย แต่ปิดสำหรับการปรับเปลี่ยน" ในคำง่ายๆ LSP ระบุว่าอินสแตนซ์ใด ๆ ของFooสามารถถูกแทนที่ด้วยอินสแตนซ์ใด ๆBarที่ได้มาจากFooและโปรแกรมจะทำงานในลักษณะเดียวกัน ฉันไม่ใช่โปรแกรมเมอร์ OOP มืออาชีพ แต่สำหรับฉันแล้วดูเหมือนว่า LSP จะเป็นไปได้ก็ต่อเมื่อBarได้รับมาจากFooไม่ได้เปลี่ยนแปลงอะไรเลย แต่จะขยายออกไปเท่านั้น นั่นหมายความว่าโดยเฉพาะอย่างยิ่งโปรแกรม LSP จะเป็นจริงเฉพาะเมื่อ OCP เป็นจริงและ OCP เป็นจริงเฉพาะในกรณีที่ LSP เป็นจริง นั่นหมายความว่าพวกเขาเท่าเทียมกัน ช่วยแก้ให้ด้วยนะถ้าฉันผิด. ฉันต้องการเข้าใจแนวคิดเหล่านี้จริงๆ ขอบคุณมากสำหรับคำตอบ

48 object-oriented  inheritance  solid  open-close  liskov-substitution 

เพื่อนร่วมงานของฉันชอบพูดว่า "การบันทึก / การแคช / ฯลฯ เป็นข้อกังวลข้าม" จากนั้นดำเนินการใช้ซิงเกิลที่เกี่ยวข้องทุกที่ พวกเขารัก IoC และ DI มันเป็นข้อแก้ตัวที่ถูกต้องหรือไม่ที่จะทำลายหลักการของ SOLI D ?

43 dependency-injection  solid  anti-patterns  singleton 

ฉันกำลังพยายามหา SOLID อยู่ ดังนั้นหลักการการพึ่งพาการพึ่งพาจึงหมายความว่าสองคลาสใด ๆ ควรสื่อสารผ่านอินเทอร์เฟซไม่ใช่โดยตรง ตัวอย่าง: หากclass Aมีวิธีที่คาดว่าตัวชี้ไปยังวัตถุของการพิมพ์แล้ววิธีนี้ควรจริงคาดว่าวัตถุของการพิมพ์class B abstract base class of Bสิ่งนี้จะช่วยในการเปิด / ปิดเช่นกัน โดยมีเงื่อนไขว่าฉันเข้าใจที่ถูกต้องคำถามของฉันจะเป็นมันเป็นวิธีที่ดีที่จะใช้นี้ทั้งหมดปฏิสัมพันธ์ชั้นเรียนหรือฉันควรพยายามที่จะคิดในแง่ของชั้น ? เหตุผลที่ฉันสงสัยก็เพราะเราจ่ายราคาบางอย่างสำหรับการทำตามหลักการนี้ บอกว่าฉันต้องใช้คุณสมบัติZนี้ หลังจากการวิเคราะห์ผมสรุปได้ว่าคุณลักษณะที่Zประกอบด้วยฟังก์ชั่นA, และB Cฉันจะสร้างซุ้มระดับZที่ผ่านอินเตอร์เฟซที่ใช้เรียนA, และB Cฉันเริ่มต้นการเข้ารหัสและการดำเนินการในบางจุดที่ผมทราบดีว่างานที่Zจริงประกอบด้วยฟังก์ชั่นA, และB Dตอนนี้ฉันต้องทำให้เสียCอินเตอร์เฟส, Cคลาสต้นแบบและเขียนDอินเตอร์เฟสและคลาสแยกกัน หากไม่มีอินเทอร์เฟซจะต้องเปลี่ยนคลาสเท่านั้น กล่าวอีกนัยหนึ่งคือการเปลี่ยนแปลงบางสิ่งฉันต้องเปลี่ยน 1. ผู้โทร 2. ส่วนต่อประสาน 3. การประกาศ 4. การดำเนินการ ในไพ ธ อนการใช้งานร่วมกันโดยตรงฉันจะต้องเปลี่ยนเฉพาะการใช้งานเท่านั้น

43 design  dependency-injection  solid 

หลักการ SOLID กลายเป็น YAGNI เมื่อใด ในฐานะโปรแกรมเมอร์เราทำการแลกเปลี่ยนตลอดเวลาระหว่างความซับซ้อนการบำรุงรักษาเวลาในการสร้างและอื่น ๆ ในบรรดาคนอื่น ๆ แนวทางที่ฉลาดที่สุดสองข้อในการเลือกอยู่ในใจของฉันคือหลักการของ SOLID และ YAGNI หากคุณไม่ต้องการมัน อย่าสร้างมันและรักษาความสะอาด ยกตัวอย่างเช่นตอนที่ฉันดูซีรีส์ dimecast บน SOLIDฉันเห็นว่ามันเริ่มจากโปรแกรมที่ค่อนข้างง่ายและกลายเป็นคอมเพล็กซ์ที่ค่อนข้างซับซ้อน (ตอนจบใช่ความซับซ้อนยังอยู่ในสายตาของคนดู) แต่ก็ยังทำให้ ฉันสงสัยว่า: เมื่อใดที่หลักการของ SOLID เปลี่ยนเป็นสิ่งที่คุณไม่ต้องการ หลักการที่มั่นคงทั้งหมดเป็นวิธีการทำงานที่เปิดใช้งานการเปลี่ยนแปลงในภายหลัง แต่ถ้าหากปัญหาในการแก้ไขเป็นเรื่องที่ค่อนข้างง่าย หรือหลักการของ SOLID เป็นสิ่งที่ใช้อยู่เสมอ ตามที่ถามในความคิดเห็น: หลักการที่เป็นของแข็ง YAGNI

43 design  philosophy  solid 

เมื่อเวลาผ่านไปฉันสามารถเข้าใจสองส่วนของSOLID - "S" และ "O" “ O” - ฉันเรียนรู้หลักการแบบเปิดด้วยความช่วยเหลือของรูปแบบการสืบทอดและกลยุทธ์ “ S” - ฉันเรียนรู้หลักการความรับผิดชอบเดี่ยวขณะเรียนรู้ ORM (ตรรกะการคงอยู่ถูกพรากไปจากวัตถุโดเมน) ในทำนองเดียวกันภูมิภาค / ภารกิจที่ดีที่สุดในการเรียนรู้ส่วนอื่น ๆ ของ SOLID (“ L”,“ I” และ“ D”) คืออะไร? อ้างอิง msdn - อันตรายจากการละเมิดหลักการ SOLID ใน C # channel9 - การนำหลักการ SOLID ไปใช้ใน. NET / C # หลักการของ OOPS (หลักการที่เป็นของแข็ง)

43 object-oriented  solid