คำถามติดแท็ก design-principles

2
มีหลักการ OO ใดบ้างที่ใช้ได้กับ Javascript จริงหรือไม่
Javascript เป็นภาษาเชิงวัตถุต้นแบบ แต่สามารถเป็นคลาสได้หลายวิธีโดย: การเขียนฟังก์ชั่นที่จะใช้เป็นคลาสด้วยตัวเอง ใช้ระบบระดับดีในกรอบ (เช่นmootools Class.Class ) สร้างจาก Coffeescript ในตอนแรกฉันมักจะเขียนโค้ดตามคลาสใน Javascript และพึ่งพามันอย่างมาก อย่างไรก็ตามเมื่อเร็ว ๆ นี้ฉันได้ใช้กรอบงาน Javascript และNodeJSที่หายไปจากความคิดในชั้นเรียนนี้และพึ่งพาเพิ่มเติมเกี่ยวกับลักษณะแบบไดนามิกของรหัสเช่น: การเขียนโปรแกรม Async การใช้และการเขียนโค้ดที่ใช้ callbacks / events การโหลดโมดูลด้วย RequireJS (เพื่อไม่ให้รั่วไหลไปยัง namespace ทั่วโลก) แนวคิดการเขียนโปรแกรมเชิงหน้าที่เช่นรายการความเข้าใจ (แผนที่ตัวกรองและอื่น ๆ ) เหนือสิ่งอื่นใด สิ่งที่ฉันรวบรวมได้คือหลักการและรูปแบบ OO ส่วนใหญ่ที่ฉันอ่าน (เช่นรูปแบบ SOLID และ GoF) ถูกเขียนขึ้นสำหรับภาษา OO ที่อ้างอิงกับคลาสในใจเช่น Smalltalk และ C ++ แต่มีผู้ใดบ้างที่สามารถใช้งานได้กับภาษาต้นแบบเช่น Javascript …

9
จะมีอะไรผิดพลาดได้หากหลักการชดเชย Liskov ถูกละเมิด?
ฉันได้ติดตามคำถามที่ได้รับการโหวตอย่างสูงเกี่ยวกับการละเมิดหลักการทดแทน Liskov ฉันรู้ว่าหลักการชดเชย Liskov คืออะไร แต่สิ่งที่ยังไม่ชัดเจนในใจของฉันคือสิ่งที่อาจผิดพลาดได้หากฉันในฐานะนักพัฒนาไม่ได้คิดถึงหลักการในขณะที่เขียนโค้ดเชิงวัตถุ

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

6
ข้อต่อหลวมในการออกแบบเชิงวัตถุ
ฉันพยายามเรียนรู้ GRASP และฉันพบสิ่งนี้อธิบาย ( ที่หน้า 3 ) เกี่ยวกับการมีเพศสัมพันธ์ต่ำและฉันรู้สึกประหลาดใจมากเมื่อฉันพบสิ่งนี้: พิจารณาวิธีการaddTrackสำหรับAlbumชั้นเรียนสองวิธีที่เป็นไปได้คือ: addTrack( Track t ) และ addTrack( int no, String title, double duration ) วิธีใดลดข้อต่อ อย่างที่สองทำเนื่องจากคลาสที่ใช้คลาส Album ไม่จำเป็นต้องทราบคลาส Track โดยทั่วไปพารามิเตอร์สำหรับเมธอดควรใช้ประเภทฐาน (int, char ... ) และคลาสจากแพ็กเกจ java. * ฉันมักจะพูดพล่ามกับเรื่องนี้; ฉันเชื่อว่าaddTrack(Track t)ดีกว่าaddTrack(int no, String title, double duration)เนื่องจากเหตุผลหลายประการ: มันจะดีกว่าเสมอสำหรับวิธีการที่จะทำให้พารามิเตอร์น้อยลงที่สุดเท่าที่จะเป็นไปได้ (ตาม Clean Code ของลุงบ็อบไม่มีหรืออย่างใดอย่างหนึ่งที่ดีกว่า, 2 ในบางกรณีและ …

4
กฎหมายของ Demeter นำไปใช้กับระบบเชิงวัตถุเกี่ยวกับการมีเพศสัมพันธ์และการทำงานร่วมกันได้อย่างไร? [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ไม่วิธีกฎหมายของ Demeterนำไปใช้กับระบบเชิงวัตถุด้วยการมีเพศสัมพันธ์และการทำงานร่วมกัน? ฉันกำลังอ่านหนังสือ "การพัฒนาซอฟต์แวร์และการฝึกฝนอย่างมืออาชีพ" และพบบทเกี่ยวกับ LoD และอยากรู้ว่าหลักการนั้นถูกนำไปใช้กับระบบเชิงวัตถุอย่างไร

3
คำจำกัดความที่ขัดแย้งกันสองประการของหลักการแยกส่วนต่อประสาน - ข้อใดที่ถูกต้อง?
เมื่ออ่านบทความบน 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 …

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

5
มีข้อเสียอย่างมีนัยสำคัญหรือไม่ขึ้นอยู่กับ abstractions?
ผมอ่านวิกินี้บน Stable Abstractions หลักการ (SAP) SAP ระบุว่ายิ่งมีความเสถียรของแพคเกจมากเท่าไหร่ก็ควรที่จะเป็นนามธรรม นี่ก็หมายความว่าหากแพ็คเกจมีความเสถียรน้อยกว่า (มีแนวโน้มที่จะเปลี่ยนแปลงได้) ก็ควรมีรูปธรรมมากขึ้น สิ่งที่ฉันไม่เข้าใจจริงๆคือสาเหตุที่เป็นเช่นนี้ แน่นอนในทุกกรณีโดยไม่คำนึงถึงความมั่นคงเราควรขึ้นอยู่กับนามธรรมและซ่อนการดำเนินงานที่เป็นรูปธรรม?

5
ควรหยุดการสืบทอดเมื่อใด
กาลครั้งหนึ่งนานมานี้ฉันถามคำถามเกี่ยวกับการโอเวอร์โฟลว์เกี่ยวกับการสืบทอด ฉันได้กล่าวว่าฉันออกแบบเครื่องมือหมากรุกในแบบ OOP ดังนั้นฉันจึงรับช่วงต่อของฉันทั้งหมดจากระดับนามธรรมของ Piece แต่การสืบทอดยังคงดำเนินต่อไป ให้ฉันแสดงด้วยรหัส public abstract class Piece { public void MakeMove(); public void TakeBackMove(); } public abstract class Pawn: Piece {} public class WhitePawn :Pawn {} public class BlackPawn:Pawn {} โปรแกรมเมอร์พบว่าการออกแบบของฉันมีความเหนือกว่าทางวิศวกรรมเล็กน้อยและแนะนำให้เอาคลาสสีที่มีสีออกมา public abstract class Piece { public Color Color { get; set; } public abstract void …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.