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

บางคนบอกว่าถ้าคุณนำหลักการของ SOLID มาใช้กับสุดขั้วคุณก็จะจบลงด้วยการเขียนโปรแกรมที่ใช้งานได้ ฉันเห็นด้วยกับบทความนี้ แต่ฉันคิดว่าซีแมนทิกส์บางอย่างหายไปจากการเปลี่ยนจากส่วนต่อประสาน / วัตถุไปเป็นฟังก์ชัน / ปิดและฉันต้องการทราบว่า Function Programming สามารถลดความสูญเสียได้อย่างไร จากบทความ: นอกจากนี้หากคุณใช้หลักการแยกส่วนต่อประสาน (ISP) อย่างจริงจังคุณจะเข้าใจว่าคุณควรใช้การเชื่อมต่อแบบสวมบทบาทแทนการเชื่อมต่อส่วนหัว หากคุณผลักดันการออกแบบของคุณไปสู่อินเทอร์เฟซที่เล็กลงเรื่อย ๆ ในที่สุดคุณจะมาถึงสุดยอด Role Interface: อินเทอร์เฟซด้วยวิธีการเดียว เรื่องนี้เกิดขึ้นกับฉันมาก นี่คือตัวอย่าง: public interface IMessageQuery { string Read(int id); } ถ้าฉันใช้การพึ่งพาIMessageQueryส่วนหนึ่งของสัญญาโดยนัยคือการโทรRead(id)จะค้นหาและส่งคืนข้อความด้วย ID ที่กำหนด เปรียบเทียบสิ่งนี้กับการพึ่งพาของลายเซ็นการทำงานที่เทียบเท่า, int -> string. โดยไม่ต้องชี้นำใด ๆ ToString()เพิ่มเติมฟังก์ชั่นนี้อาจจะง่าย หากคุณดำเนินการIMessageQuery.Read(int id)ด้วยToString()ฉันอาจกล่าวหาว่าคุณถูกโค่นล้มโดยเจตนา! ดังนั้นโปรแกรมเมอร์ฟังก์ชันสามารถทำอะไรได้เพื่อรักษาซีแมนทิกส์ของอินเตอร์เฟสที่มีชื่อดี ยกตัวอย่างเช่นมันเป็นเรื่องธรรมดาที่จะสร้างประเภทเรคคอร์ดโดยมีสมาชิกคนเดียวหรือไม่? type MessageQuery = { …

16 object-oriented  functional-programming  solid 

ฉันมีโมดูลพูดว่า 'M' ซึ่งมีลูกค้าไม่กี่คนให้พูดว่า 'C1', 'C2', 'C3' ฉันต้องการที่จะแบ่งปัน namespace ของโมดูล M คือการประกาศของ API และข้อมูลที่มันเปิดเผยลงในไฟล์ส่วนหัวในลักษณะที่ - สำหรับลูกค้าใด ๆ จะเห็นเฉพาะข้อมูลและ API ที่ต้องการเท่านั้น ส่วนที่เหลือของเนมสเปซของโมดูลถูกซ่อนจากไคลเอนต์เช่นเป็นไปตามหลักการแยกส่วน การประกาศไม่ซ้ำในหลายไฟล์ส่วนหัวเช่นไม่ละเมิด แห้ง โมดูล M ไม่มีการพึ่งพาลูกค้า ลูกค้าไม่ได้รับผลกระทบจากการเปลี่ยนแปลงที่เกิดขึ้นในส่วนของโมดูล M ที่ไม่ได้ใช้ ลูกค้าที่มีอยู่ไม่ได้รับผลกระทบจากการเพิ่ม (หรือลบ) ของลูกค้าเพิ่มเติม ขณะนี้ฉันจัดการเรื่องนี้โดยการแบ่งเนมสเปซของโมดูลขึ้นอยู่กับความต้องการของลูกค้า ตัวอย่างเช่นในภาพด้านล่างส่วนต่างๆของเนมสเปซของโมดูลที่ลูกค้า 3 รายต้องการ ความต้องการของลูกค้ามีการทับซ้อนกัน namespace โมดูลแบ่งออกเป็น 4 ส่วนหัวของไฟล์ที่แยกต่างหาก - 'a', '1', '2' และ '3' อย่างไรก็ตามสิ่งนี้เป็นการละเมิดข้อกำหนดดังกล่าวบางประการเช่น R3 และ R5 …

15 c  interfaces  solid 

ฉันได้ยินมามากมายจากผู้ฝึกอบรมTDDว่าข้อดีอย่างหนึ่งของ TDD คือบังคับให้นักพัฒนาปฏิบัติตามหลักการของSOLID (ความรับผิดชอบเดี่ยว, เปิด - ปิด, การทดแทน Liskov, การแยกอินเตอร์เฟสและการผกผันการพึ่งพา) แต่สำหรับฉันแล้วมันก็เพียงพอแล้วที่จะเขียนการทดสอบ (การทดสอบหน่วยเบื้องต้น) เพื่อให้เข้าใจว่าการติดตาม SOLID เป็นสิ่งสำคัญ TDD บังคับให้ผู้พัฒนาติดตาม SOLID มากกว่าการเขียนบททดสอบหรือไม่?

15 unit-testing  tdd  solid 

ฉันเพิ่งเริ่มต้นกับRxJavaการใช้ReactiveXของ Java (หรือที่เรียกว่าRxและReactive Extensions ) สิ่งที่ทำให้ฉันหลงไหลจริงๆคือขนาดที่ใหญ่ของคลาสFlowableของ RxJava : มันมี 460 วิธี! เพื่อความเป็นธรรม: มีวิธีการมากมายที่มากเกินไปซึ่งกระแทกจำนวนวิธีทั้งหมดอย่างมีนัยสำคัญ บางทีคลาสนี้ควรจะถูกทำลาย แต่ความรู้และความเข้าใจของฉันเกี่ยวกับ RxJava มี จำกัด มาก คนที่สร้าง RxJava นั้นฉลาดมากและพวกเขาสามารถเสนอข้อโต้แย้งที่ถูกต้องในการเลือกสร้างFlowableด้วยวิธีการมากมาย ในทางกลับกัน: RxJava เป็นการใช้งาน Java ของส่วนขยายรีแอกทีฟของMicrosoftและนั่นไม่ได้มีคลาสFlowableดังนั้นนี่ไม่ใช่กรณีของการย้ายคลาสที่มีอยู่แบบสุ่มและนำไปใช้ใน Java [ อัปเดต:จุดก่อนหน้าในตัวเอียงไม่ถูกต้องตามจริง: คลาสObservableของ Microsoft ซึ่งมีมากกว่า 400 วิธีใช้เป็นพื้นฐานสำหรับคลาสObservableของ RxJava และFlowableนั้นคล้ายกับObservableแต่จัดการ backpressure สำหรับข้อมูลจำนวนมาก ดังนั้นทีม RxJava จึงย้ายคลาสที่มีอยู่ โพสต์นี้น่าจะท้าทายการออกแบบเดิมของคลาสObservableโดย Microsoft มากกว่าคลาสFlowableของ RxJava ] RxJava อายุน้อยกว่า 3 …

14 java  object-oriented  class-design  solid  reactive 

พื้นหลัง: ฉันกำลังพัฒนากรอบการส่งข้อความ กรอบนี้จะช่วยให้: การส่งข้อความผ่านบัสบริการ สมัครสมาชิกคิวบนบัสข้อความ สมัครสมาชิกหัวข้อบนบัสข้อความ ขณะนี้เรากำลังใช้ RabbitMQ แต่ฉันรู้ว่าเราจะย้ายไปที่ Microsoft Service Bus (บนสถานที่ตั้ง) ในอนาคตอันใกล้นี้ ฉันวางแผนที่จะสร้างชุดของอินเทอร์เฟซและการใช้งานเพื่อที่ว่าเมื่อเราย้ายไปที่ ServiceBus ฉันก็ต้องจัดเตรียมการใช้งานใหม่โดยไม่ต้องแก้ไขรหัสลูกค้าใด ๆ (เช่นผู้เผยแพร่หรือสมาชิก) ปัญหาที่นี่คือ RabbitMQ และ ServiceBus ไม่สามารถแปลได้โดยตรง ตัวอย่างเช่น RabbitMQ ขึ้นอยู่กับการแลกเปลี่ยนและชื่อหัวข้อในขณะที่ ServiceBus เป็นข้อมูลเกี่ยวกับ Namespaces และ Queues นอกจากนี้ไม่มีอินเทอร์เฟซทั่วไประหว่างไคลเอนต์ ServiceBus และไคลเอนต์ RabbitMQ (เช่นทั้งสองอาจมีการเชื่อมต่อ ICon แต่อินเทอร์เฟซแตกต่างกัน - ไม่ใช่จากเนมสเปซทั่วไป) ดังนั้นถึงจุดของฉันฉันสามารถสร้างอินเตอร์เฟซดังต่อไปนี้: public interface IMessageReceiver{ void AddSubscription(ISubscription subscriptionDetails) } เนื่องจากคุณสมบัติที่ไม่สามารถแปลได้ของทั้งสองเทคโนโลยีการปรับใช้ …

14 solid  liskov-substitution 

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

14 design-patterns  object-oriented  class-design  solid  single-responsibility 

ฉันเข้าใจเจตนาของหลักการแบบเปิด มันหมายถึงการลดความเสี่ยงของการทำลายบางสิ่งบางอย่างที่ใช้งานได้แล้วในขณะที่แก้ไขโดยบอกให้คุณพยายามขยายโดยไม่ต้องแก้ไข อย่างไรก็ตามฉันมีปัญหาในการทำความเข้าใจวิธีการใช้หลักการนี้ในทางปฏิบัติ เพื่อความเข้าใจของฉันมีสองวิธีในการใช้มัน ก่อนและหลังการเปลี่ยนแปลงที่เป็นไปได้: ก่อน: โปรแกรมไปยัง abstractions และ 'ทำนายอนาคต' มากที่สุดเท่าที่จะทำได้ ตัวอย่างเช่นวิธีการdrive(Car car)จะต้องเปลี่ยนหาก Motorcycleมีการเพิ่ม s ในระบบในอนาคตดังนั้นจึงอาจละเมิด OCP แต่วิธีdrive(MotorVehicle vehicle)นี้มีแนวโน้มที่จะไม่เปลี่ยนแปลงในอนาคตดังนั้นจึงเป็นไปตาม OCP อย่างไรก็ตามมันค่อนข้างยากที่จะทำนายอนาคตและรู้ล่วงหน้าว่าการเปลี่ยนแปลงใดที่จะเกิดขึ้นกับระบบ หลังจาก: เมื่อต้องการการเปลี่ยนแปลงให้ขยายคลาสแทนการแก้ไขเป็นรหัสปัจจุบัน แบบฝึก # 1 ไม่ยากที่จะเข้าใจ อย่างไรก็ตามมันเป็นข้อปฏิบัติที่ 2 ที่ฉันมีปัญหาในการทำความเข้าใจวิธีการสมัคร ยกตัวอย่างเช่น (ฉันเอามันจากวิดีโอบน YouTube): ขอบอกว่าเรามีวิธีการในระดับที่ยอมรับได้วัตถุ:CreditCard makePayment(CraditCard card)หนึ่งวันVoucherจะถูกเพิ่มเข้าไปในระบบ วิธีนี้ไม่รองรับพวกมันดังนั้นจึงต้องมีการแก้ไข เมื่อนำวิธีการนี้ไปใช้ในตอนแรกเราไม่สามารถคาดการณ์อนาคตและโปรแกรมในแง่นามธรรมได้มากขึ้น (เช่นmakePayment(Payment pay)ดังนั้นตอนนี้เราต้องเปลี่ยนรหัสที่มีอยู่ แบบฝึกหัดที่ 2 กล่าวว่าเราควรเพิ่มฟังก์ชันการทำงานโดยขยายแทนการปรับเปลี่ยน นั่นหมายความว่าอย่างไร? ฉันควรคลาสย่อยคลาสที่มีอยู่แทนที่เพียงแค่เปลี่ยนเป็นรหัสเดิมหรือไม่ ฉันควรทำเสื้อคลุมบางอย่างเพื่อหลีกเลี่ยงการเขียนรหัสใหม่หรือไม่? หรือหลักการไม่ได้อ้างถึง 'วิธีการแก้ไข / เพิ่มฟังก์ชันการทำงานที่ถูกต้อง' …

14 design  object-oriented  object-oriented-design  solid 

เมื่ออ่านบทความบน ISP ดูเหมือนว่ามีคำจำกัดความที่ขัดแย้งกันสองอย่างของ ISP: ตามคำจำกัดความแรก (ดู1 , 2 , 3 ) ISP ระบุว่าคลาสที่ใช้อินเทอร์เฟซไม่ควรถูกบังคับให้ใช้ฟังก์ชันที่พวกเขาไม่ต้องการ ดังนั้นอินเตอร์เฟซไขมันIFat interface IFat { void A(); void B(); void C(); void D(); } class MyClass: IFat { ... } ควรแบ่งออกเป็นอินเตอร์เฟสขนาดเล็กISmall_1และISmall_2 interface ISmall_1 { void A(); void B(); } interface ISmall_2 { void C(); void D(); } class …

14 solid  design-principles 

แรงบันดาลใจจากคำตอบนี้ : หลักการทดแทน Liskov ต้องการ สิ่งนั้น เงื่อนไขเบื้องต้นไม่สามารถเสริมความแข็งแกร่งในประเภทย่อย Postconditions ไม่สามารถลดลงในประเภทย่อย ค่าคงที่ของซูเปอร์ไทป์จะต้องเก็บรักษาไว้ในประเภทย่อย ข้อ จำกัด ประวัติ ("กฎประวัติศาสตร์") วัตถุนั้นได้รับการยกย่องว่าสามารถปรับเปลี่ยนได้ด้วยวิธีการของพวกเขาเท่านั้น (encapsulation) เนื่องจากชนิดย่อยอาจแนะนำวิธีการที่ไม่ปรากฏใน supertype การแนะนำวิธีการเหล่านี้อาจอนุญาตให้มีการเปลี่ยนแปลงสถานะในชนิดย่อยที่ไม่อนุญาตใน supertype ข้อ จำกัด ประวัติห้ามสิ่งนี้ ฉันหวังว่าถ้ามีคนจะโพสต์ลำดับชั้นของชั้นเรียนที่ละเมิด 4 คะแนนและจะแก้ไขได้อย่างไร ฉันกำลังมองหาคำอธิบายอย่างละเอียดเพื่อจุดประสงค์ด้านการศึกษาเกี่ยวกับวิธีระบุแต่ละจุดในลำดับชั้นและวิธีที่ดีที่สุดในการแก้ไข หมายเหตุ: ฉันหวังว่าจะโพสต์ตัวอย่างโค้ดเพื่อให้คนทำงาน แต่คำถามนั้นเกี่ยวกับวิธีระบุลำดับชั้นผิดพลาด :)

14 object-oriented  inheritance  solid  design-principles  liskov-substitution 

คลาส LinkedList มีอยู่พร้อมกับฟังก์ชั่นเช่น add_first (), add_last (), add_after (), remove_first (), remove_last () และ remove () ขณะนี้มีคลาสสแต็กที่จัดเตรียมฟังก์ชันการใช้งานเช่น push (), pop (), peek () หรือ top () และเพื่อใช้เมธอดเหล่านี้จะขยายเมธอดคลาส LinkedList นี่เป็นการละเมิดหลักการทดแทนของ Liskov หรือไม่? ตัวอย่างเช่นพิจารณา case add_after () เพื่อเพิ่มโหนดที่ตำแหน่งที่ n ของรายการที่เชื่อมโยง สามารถทำได้ในคลาสพื้นฐาน แต่ไม่สามารถอยู่ในคลาสสแต็กได้ postconditions ถูกทำให้อ่อนลงที่นี่หรือคุณปรับเปลี่ยนวิธี add_after () เพื่อเพิ่มไปยังด้านบนสุดของสแต็กหรือไม่ นอกจากนี้หากไม่เป็นการละเมิดการออกแบบที่ไม่ดีนี้เป็นอย่างไร และคุณจะใช้ฟังก์ชั่น Stack โดยใช้คลาส LinkedList …

13 design  object-oriented  object-oriented-design  solid  liskov-substitution 

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

13 object-oriented-design  solid  single-responsibility 

เมื่อนานมาแล้วที่ฉันอ่านคำตอบสแต็คโอเวอร์โฟลว์ที่ฉันหาไม่พบประโยคที่อธิบายว่าคุณควรทดสอบ API สาธารณะและผู้เขียนบอกว่าคุณควรทดสอบอินเทอร์เฟซ ผู้เขียนอธิบายว่าหากมีการเปลี่ยนแปลงวิธีการใช้งานคุณไม่จำเป็นต้องแก้ไขกรณีทดสอบเนื่องจากการทำเช่นนี้จะเป็นการผิดสัญญาที่ทำให้ระบบภายใต้การทดสอบทำงานได้ กล่าวอีกนัยหนึ่งการทดสอบควรล้มเหลวหากวิธีการไม่ทำงาน แต่ไม่ใช่เพราะการใช้งานมีการเปลี่ยนแปลง สิ่งนี้เรียกร้องความสนใจของฉันเมื่อเราพูดถึงการล้อเลียน เนื่องจากการเยาะเย้ยต้องอาศัยการเรียกร้องอย่างคาดหวังจากระบบภายใต้การทดสอบของผู้ทดสอบดังนั้น mocks จึงผนวกเข้ากับการใช้งานอย่างแน่นหนามากกว่าอินเตอร์เฟส ในขณะที่ทำการค้นคว้าmock vs stubหลายบทความเห็นด้วยว่าควรใช้ต้นขั้วแทน mocks เนื่องจากไม่ต้องพึ่งพาความคาดหวังจากการพึ่งพาซึ่งหมายความว่าการทดสอบไม่จำเป็นต้องมีความรู้เกี่ยวกับระบบพื้นฐานภายใต้การใช้งานการทดสอบ คำถามของฉันจะเป็น: mocks ละเมิดหลักการเปิด / ปิดหรือไม่? มีบางสิ่งที่ขาดหายไปในการโต้แย้งเพื่อช่วยสตับในย่อหน้าสุดท้ายที่ทำให้สตับไม่ดีเทียบกับ mocks หรือไม่? ถ้าเป็นเช่นนั้นเมื่อไรจะเป็นกรณีการใช้งานที่ดีในการเยาะเย้ยและเมื่อไหร่จะเป็นกรณีการใช้งานที่ดีในการใช้สตับ

13 unit-testing  solid  mocking  open-close  stub 

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

13 design-patterns  object-oriented  solid  design 

ฉันทำการทดสอบหน่วยและในชั้นเรียนของฉันฉันต้องส่งจดหมายจากวิธีใดวิธีหนึ่งดังนั้นการใช้การฉีดคอนสตรัคเตอร์ฉันฉีดอินสแตนซ์ของZend_Mailคลาสที่อยู่ในกรอบ Zend ตอนนี้บางคนยืนยันว่าถ้าห้องสมุดมีความมั่นคงเพียงพอและจะไม่เปลี่ยนแปลงบ่อยครั้งก็ไม่จำเป็นต้องห่อมัน ดังนั้นสมมติว่าZend_Mailมันเสถียรและจะไม่เปลี่ยนแปลงและมันก็เหมาะกับความต้องการของฉันทั้งหมดแล้วฉันจะไม่ต้องการเสื้อคลุม ตอนนี้มาดูคลาสของฉันLoggerที่ขึ้นอยู่กับZend_Mail: class Logger{ private $mailer; function __construct(Zend_Mail $mail){ $this->mail=$mail; } function toBeTestedFunction(){ //Some code $this->mail->setTo('some value'); $this->mail->setSubject('some value'); $this->mail->setBody('some value'); $this->mail->send(); //Some } } อย่างไรก็ตามการทดสอบหน่วยต้องการให้ฉันทดสอบองค์ประกอบหนึ่งครั้งดังนั้นฉันต้องจำลองZend_Mailชั้นเรียน นอกจากนี้ฉันกำลังละเมิดหลักการการพึ่งพาการพึ่งพาเนื่องจากLoggerชั้นเรียนของฉันตอนนี้ขึ้นอยู่กับการตัดสินใจที่ไม่เป็นนามธรรม ตอนนี้ฉันจะทดสอบLoggerการแยกโดยไม่ต้องห่อได้Zend_Mailอย่างไร! รหัสอยู่ใน PHP แต่คำตอบไม่จำเป็นต้องเป็น นี่เป็นปัญหาการออกแบบมากกว่าฟีเจอร์เฉพาะภาษา

13 design  object-oriented  unit-testing  tdd  solid 

ฉันค่อนข้างใหม่กับหลักการออกแบบSOLID ฉันเข้าใจถึงสาเหตุและผลประโยชน์ของพวกเขา แต่ยังไม่สามารถนำไปใช้กับโครงการขนาดเล็กที่ฉันต้องการสร้างโครงสร้างใหม่ให้เป็นการฝึกปฏิบัติเพื่อใช้หลักการ SOLID ฉันรู้ว่าไม่จำเป็นต้องเปลี่ยนแอปพลิเคชันที่ทำงานได้อย่างสมบูรณ์แบบ แต่ฉันต้องการปรับโครงสร้างใหม่เพื่อให้ได้รับประสบการณ์การออกแบบสำหรับโครงการในอนาคต แอปพลิเคชั่นมีงานดังต่อไปนี้ (จริง ๆ แล้วมากกว่านั้น แต่ให้ง่าย): มันต้องอ่านไฟล์ XML ซึ่งมีฐานข้อมูลตาราง / คอลัมน์ / ดูคำนิยาม ฯลฯ และสร้างไฟล์ SQL ที่สามารถใช้เพื่อสร้าง สกีมาฐานข้อมูล ORACLE (หมายเหตุ: โปรดอย่าอภิปรายว่าทำไมฉันถึงต้องการหรือทำไมฉันถึงไม่ใช้ XSLT และอื่น ๆ มีเหตุผลหลายประการ แต่มันไม่ใช่หัวข้อ) เป็นการเริ่มต้นฉันเลือกดูเฉพาะตารางและข้อ จำกัด หากคุณไม่สนใจคอลัมน์คุณสามารถระบุวิธีต่อไปนี้: ข้อ จำกัด เป็นส่วนหนึ่งของตาราง (หรือมากกว่าอย่างแม่นยำส่วนหนึ่งของคำสั่ง CREATE TABLE) และข้อ จำกัด อาจอ้างอิงตารางอื่น ก่อนอื่นฉันจะอธิบายว่าแอปพลิเคชันมีลักษณะอย่างไรในตอนนี้ (ไม่ได้ใช้ SOLID): ในขณะนี้แอปพลิเคชันมีคลาส "ตาราง" ซึ่งมีรายการตัวชี้ถึงข้อ จำกัด …

13 design  object-oriented  solid