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

จุดประสงค์ของการใช้DTOคืออะไรและเป็นแนวคิดล้าสมัยหรือไม่ ฉันใช้POJOในเลเยอร์มุมมองเพื่อถ่ายโอนและเก็บข้อมูล POJO เหล่านี้ถือเป็นทางเลือกแทน DTO ได้หรือไม่

132 java  design-patterns 

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

124 design-patterns  dependency-injection 

การฉีดพึ่งพา (DI) เป็นรูปแบบที่รู้จักกันดีและทันสมัย วิศวกรส่วนใหญ่ทราบถึงข้อดีของมันเช่น: ทำให้การแยกในการทดสอบหน่วยเป็นไปได้ / ง่าย การกำหนดการขึ้นต่อกันของคลาสอย่างชัดเจน ยกตัวอย่างเช่นการออกแบบที่ดี ( หลักการความรับผิดชอบเดี่ยว (SRP)) เปิดใช้งานการสลับการใช้งานอย่างรวดเร็ว ( DbLoggerแทนที่จะConsoleLoggerเป็นตัวอย่าง) ฉันคิดว่ามีฉันทามติอุตสาหกรรมที่ DI เป็นรูปแบบที่ดีมีประโยชน์ ไม่มีการวิจารณ์มากเกินไปในขณะนี้ ข้อเสียที่กล่าวถึงในชุมชนมักจะน้อย บางส่วนของพวกเขา: เพิ่มจำนวนคลาส สร้างอินเตอร์เฟสที่ไม่จำเป็น ขณะนี้เราหารือเกี่ยวกับการออกแบบสถาปัตยกรรมกับเพื่อนร่วมงานของฉัน เขาค่อนข้างอนุรักษ์นิยม แต่เปิดใจ เขาชอบตั้งคำถามกับสิ่งต่าง ๆ ซึ่งฉันคิดว่าดีเพราะหลาย ๆ คนในวงการไอทีแค่คัดลอกเทรนด์ล่าสุดทำซ้ำข้อดีและโดยทั่วไปแล้วไม่คิดมากเกินไป - อย่าวิเคราะห์ลึกเกินไป สิ่งที่ฉันต้องการถามคือ: เราควรใช้การฉีดพึ่งพาเมื่อเรามีเพียงหนึ่งการดำเนินการ? เราควรห้ามการสร้างวัตถุใหม่ยกเว้นภาษา / กรอบงานหรือไม่? การฉีดความคิดที่ไม่ดีในการนำไปใช้งานเพียงครั้งเดียว (สมมติว่าเรามีการนำไปใช้เพียงครั้งเดียวดังนั้นเราจึงไม่ต้องการสร้างอินเทอร์เฟซ "ว่างเปล่า") ถ้าเราไม่ได้วางแผนทดสอบหน่วยเฉพาะชั้นเรียนหรือไม่

118 design-patterns  architecture  dependency-injection 

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

107 design  design-patterns 

ฉันเริ่มอ่านหนังสือรูปแบบการออกแบบโดย GoF รูปแบบบางอย่างคล้ายกันมากกับความแตกต่างทางแนวคิดเล็กน้อย คุณคิดว่าในหลาย ๆ รูปแบบบางอย่างนั้นไม่จำเป็นในภาษาไดนามิกเช่น Python (เช่นเพราะมันถูกแทนที่ด้วยคุณสมบัติแบบไดนามิก)?

98 design-patterns  python 

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

95 design-patterns  functional-programming  haskell  dsl  monad 

มักจะได้ยินว่า OOP นั้นสอดคล้องกับวิธีที่ผู้คนคิดเกี่ยวกับโลก แต่ฉันจะไม่เห็นด้วยอย่างยิ่งกับข้อความนี้: เรา (หรืออย่างน้อยฉัน) สร้างแนวคิดโลกในแง่ของความสัมพันธ์ระหว่างสิ่งต่าง ๆ ที่เราพบ แต่จุดเน้นของ OOP คือการออกแบบคลาสบุคคลและลำดับชั้นของพวกเขา โปรดสังเกตว่าในชีวิตประจำวันความสัมพันธ์และการกระทำมีอยู่ส่วนใหญ่ระหว่างวัตถุที่จะเป็นอินสแตนซ์ของคลาสที่ไม่เกี่ยวข้องใน OOP ตัวอย่างของความสัมพันธ์เช่น: "หน้าจอของฉันอยู่ด้านบนของตาราง"; "ฉัน (มนุษย์) กำลังนั่งอยู่บนเก้าอี้"; "รถยนต์อยู่บนถนน"; "ฉันพิมพ์บนแป้นพิมพ์"; "เครื่องชงกาแฟต้มน้ำ" "ข้อความจะปรากฏในหน้าต่างเทอร์มินัล" เราคิดในแง่ของ bivalent (บางครั้ง trivalent เช่นใน "ฉันให้คุณดอกไม้") คำกริยาที่กริยาคือการกระทำ (ความสัมพันธ์) ที่ทำงานบนวัตถุสองชิ้นเพื่อสร้างผลลัพธ์ / การกระทำบางอย่าง โฟกัสอยู่ในการดำเนินการและทั้งสอง (หรือสาม) [ไวยากรณ์] วัตถุมีความสำคัญเท่าเทียมกัน เปรียบเทียบกับ OOP ที่คุณต้องค้นหาวัตถุหนึ่ง (คำนาม) ก่อนและบอกให้ดำเนินการบางอย่างกับวัตถุอื่น วิธีการคิดเปลี่ยนจากการกระทำ / คำกริยาที่ใช้กับคำนามเป็นคำนามปฏิบัติการบนคำนาม - ราวกับว่าทุกอย่างถูกพูดด้วยเสียงเฉยๆหรือสะท้อนเสียงเช่น "ข้อความแสดงโดยหน้าต่างเทอร์มินัล" หรืออาจจะ …

86 design  design-patterns  object-oriented 

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

79 design-patterns  javascript  object-oriented  patterns-and-practices  design-principles 

YAGNIควรใช้จุดไหนในการต่อต้านการเขียนโค้ดที่ดีและในทางกลับกัน ฉันกำลังทำงานในโครงการในที่ทำงานและต้องการแนะนำมาตรฐานรหัสที่ดีให้กับเพื่อนร่วมงานของฉันอย่างช้าๆ (ปัจจุบันไม่มีและทุกอย่างก็แค่แฮ็คเข้าด้วยกันโดยไม่มีสัมผัสหรือเหตุผล) แต่หลังจากสร้างชุดของคลาส (เรา อย่าทำ TDD หรือน่าเสียดายที่การทดสอบหน่วยใด ๆ เลย) ฉันถอยหลังไปหนึ่งก้าวและคิดว่ามันเป็นการละเมิด YAGNI เพราะฉันรู้ด้วยความมั่นใจว่าเราไม่ต้องการขยายชั้นเรียนเหล่านี้ นี่คือตัวอย่างที่เป็นรูปธรรมของสิ่งที่ฉันหมายถึง: ฉันมีชั้นการเข้าถึงข้อมูลห่อชุดของขั้นตอนการจัดเก็บซึ่งใช้รูปแบบ Repository สไตล์พื้นฐานกับฟังก์ชั่น CRUD ขั้นพื้นฐาน IRepositoryเนื่องจากมีกำมือของวิธีการที่ทุกชั้นเรียนที่เก็บของฉันต้องฉันสร้างอินเตอร์เฟซทั่วไปสำหรับเก็บของฉันเรียกว่า อย่างไรก็ตามฉันได้สร้างอินเทอร์เฟซ "ตัวทำเครื่องหมาย" (เช่นอินเทอร์เฟซที่ไม่เพิ่มฟังก์ชันการทำงานใหม่) สำหรับที่เก็บแต่ละประเภท (เช่นICustomerRepository) และคลาสคอนกรีตนำไปใช้ ฉันได้ทำสิ่งเดียวกันกับการใช้ Factory เพื่อสร้างออบเจ็กต์ทางธุรกิจจาก DataReaders / DataSets ที่ส่งคืนโดย Stored Procedure ลายเซ็นของคลาสที่เก็บของฉันมีแนวโน้มที่จะมีลักษณะเช่นนี้: public class CustomerRepository : ICustomerRepository { ICustomerFactory factory = null; public CustomerRepository() : this(new …

76 design-patterns  software-craftsmanship 

วรรณกรรมการเขียนโปรแกรม OO เต็มไปด้วยรูปแบบการออกแบบ หนังสือส่วนใหญ่เกี่ยวกับการเขียนโปรแกรมเชิงวัตถุอุทิศบทหนึ่งหรือสองบทเพื่อออกแบบลวดลายเช่นโรงงานและนักตกแต่ง ดังนั้นรูปแบบที่เทียบเท่าในภาษาการทำงานคืออะไรและทำไมไม่มีใครเขียนหนังสือเกี่ยวกับพวกเขา? มีบางสิ่งที่พิเศษเกี่ยวกับภาษาที่ใช้งานได้ซึ่งขัดขวางความต้องการรูปแบบการออกแบบหรือไม่?

75 books  design-patterns  functional-programming 

ในปี 2003 บทความนี้โดย Stephen Figgins บน linuxdevcenter.com BitTorrent ของ Bram Cohen ถูกอธิบายว่าใช้รูปแบบการออกแบบ "แก้ไขทุกอย่าง" วิธีการทั่วไปที่น้อยกว่าซึ่งทั้งสองทำให้ BitTorrent ยากที่จะเข้าใจ แต่ควรค่าแก่การศึกษาคือการใช้ idempotence ของโคเฮน กระบวนการเป็น idempotent เมื่อใช้มากกว่าหนึ่งครั้งทำให้ไม่มีการเปลี่ยนแปลงเพิ่มเติม Cohen กล่าวว่าเขาใช้รูปแบบการออกแบบที่เรียกว่า "แก้ไขทุกอย่าง" ซึ่งเป็นฟังก์ชั่นที่สามารถตอบสนองต่อการเปลี่ยนแปลงจำนวนมากโดยไม่ได้สังเกตสิ่งที่มันอาจเปลี่ยนแปลง เขาอธิบายว่า“ คุณสังเกตเห็นเหตุการณ์ที่เกิดขึ้นจากนั้นเรียกใช้ฟังก์ชันแก้ไขทุกอย่างที่เขียนในลักษณะที่ไม่คุ้นเคยนี้และทำความสะอาดทุกสิ่งที่อาจเกิดขึ้นและคำนวณใหม่ทั้งหมดตั้งแต่เริ่มต้น” ในขณะที่ idempotence ทำให้การคำนวณยากขึ้นง่ายขึ้น แต่ก็ทำให้สิ่งต่าง ๆ มีความซับซ้อน ไม่ชัดเจนว่าการโทรกำลังจะเปลี่ยนแปลงหากมีสิ่งใดอยู่เสมอ คุณไม่จำเป็นต้องรู้ล่วงหน้า คุณมีอิสระที่จะเรียกใช้ฟังก์ชั่น เสียงนี้ค่อนข้างดีบนใบหน้าของมัน อย่างไรก็ตามสำหรับฉันแล้วการเรียกใช้ฟังก์ชั่น "แก้ไขทุกอย่าง" idempotent จะช่วยเพิ่มความแข็งแกร่งของระบบด้วยต้นทุนที่มีประสิทธิภาพและอาจทำให้ระบบที่บรรจุนั้นแย่ลง (ซึ่งอาจต้องการกระบวนการที่วางแผนและดำเนินการอย่างรอบคอบ) ฉันไม่สามารถพูดได้ว่าฉันเคยใช้มาก่อน ฉันยังไม่สามารถหาแหล่งที่มาสำหรับการใช้งานออนไลน์ของเขา ( แต่ฉันไม่พบคนนี้ที่อ้างว่าจะขึ้นอยู่กับมัน.) หรือฉันสามารถหาอ้างอิงถึงมันนอกของบทความนี้ (และผมคิดว่า google-Fu …

74 design-patterns 

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

74 design-patterns  mvc  rationale 

ฉันได้ยินเพียงคำว่า "รูปแบบการออกแบบ" ที่ใช้สำหรับโค้ดเชิงวัตถุและรูปแบบ GoF มีเพียงรูปแบบการออกแบบ OOP เท่านั้น แต่รูปแบบการออกแบบเป็นวิธีการแก้ปัญหาที่สง่างามสำหรับปัญหาการเขียนโปรแกรมทั่วไปใช่ไหม ไม่มีสิ่งใดในที่บอกว่าพวกเขาจะต้อง จำกัด อยู่ที่ OOP เท่านั้นไหม? ฉันต้องการดูตัวอย่างของรูปแบบการออกแบบภายนอกขอบเขตของการเขียนโปรแกรมเชิงวัตถุ คุณมีอะไรบ้าง ยังมีอยู่ (ไม่มีหนังสือเช่นหนังสือ GoF ต้องถูกเขียนขึ้นมาพวกเขาควรจะใช้แค่นั้นเพียงพอแล้ว)? สามารถระบุได้เฉพาะกับภาษาการเขียนโปรแกรมบางภาษา แต่รูปแบบทั่วไป (ระดับกระบวนทัศน์) เป็นที่ต้องการของกระบวนทัศน์อื่นที่ไม่ใช่เชิงวัตถุ

70 design-patterns 

ฉันดูคำพูดของสจ็วตเซียร์เซียร์ " คิดในข้อมูล " และนำหนึ่งในแนวคิดจากนั้นเป็นหลักการออกแบบในเกมนี้ที่ฉันทำ ความแตกต่างคือเขาทำงานใน Clojure และฉันทำงานใน JavaScript ฉันเห็นความแตกต่างที่สำคัญระหว่างภาษาของเราในเรื่องนั้น: Clojure เป็นการเขียนโปรแกรมที่ใช้งานง่าย รัฐส่วนใหญ่ไม่เปลี่ยนรูป ฉันใช้ความคิดจากสไลด์ "ทุกอย่างคือแผนที่" (จาก 11 นาที, 6 วินาทีถึง> 29 นาที) บางสิ่งที่เขาพูดคือ: เมื่อใดก็ตามที่คุณเห็นฟังก์ชั่นที่ใช้อาร์กิวเมนต์ 2-3 ข้อคุณสามารถทำให้เป็นกรณีสำหรับเปลี่ยนเป็นแผนที่และเพิ่งผ่านแผนที่มามีข้อดีมากมายดังนี้: คุณไม่ต้องกังวลกับคำสั่งโต้แย้ง คุณไม่ต้องกังวลกับข้อมูลเพิ่มเติมใด ๆ หากมีกุญแจพิเศษนั่นไม่ใช่ความกังวลของเรา พวกเขาไหลผ่านพวกเขาไม่ได้ยุ่ง คุณไม่จำเป็นต้องกำหนดสคีมา ตรงข้ามกับการส่งผ่านวัตถุไม่มีการซ่อนข้อมูล แต่เขาทำให้กรณีที่การซ่อนข้อมูลสามารถทำให้เกิดปัญหาและ overrated: ประสิทธิภาพ ใช้งานง่าย ทันทีที่คุณสื่อสารผ่านเครือข่ายหรือข้ามกระบวนการคุณจะต้องให้ทั้งสองฝ่ายเห็นพ้องกับการแสดงข้อมูลต่อไป นั่นเป็นงานพิเศษที่คุณสามารถข้ามได้ถ้าคุณแค่ทำงานกับข้อมูล ส่วนใหญ่เกี่ยวข้องกับคำถามของฉัน นี่คือ 29 นาทีใน: "ทำให้ฟังก์ชั่นของคุณประกอบได้" นี่คือตัวอย่างโค้ดที่เขาใช้อธิบายแนวคิด: ;; Bad (defn complex-process [] …

69 design  design-patterns  architecture  functional-programming 

ฉันเริ่มสร้างแอพใน 3 เลเยอร์ (DAL, BL, UI) [ส่วนใหญ่จัดการกับ CRM, รายงานการขายและสินค้าคงคลัง] เพื่อนร่วมงานคนหนึ่งบอกฉันว่าฉันต้องย้ายไปที่รูปแบบเลเยอร์บริการซึ่งนักพัฒนาซอฟต์แวร์มาจากรูปแบบการบริการจากประสบการณ์ของพวกเขาและเป็นวิธีที่ดีกว่าในการออกแบบแอปพลิเคชันส่วนใหญ่ เขากล่าวว่าจะง่ายกว่ามากในการรักษาแอพพลิเคชั่นในอนาคต โดยส่วนตัวแล้วฉันได้รับความรู้สึกว่ามันเป็นเพียงการสร้างสิ่งที่ซับซ้อนมากขึ้นและฉันก็ไม่สามารถเห็นผลประโยชน์มากมายจากสิ่งนี้ที่จะพิสูจน์ได้ แอพนี้มี UI ขนาดเล็กเพิ่มเติมที่ใช้ฟังก์ชั่นแอปพลิเคชั่นเดสก์ท็อปบางส่วน (แต่มีเพียงไม่กี่) ดังนั้นฉันจึงพบว่าตัวเองทำซ้ำรหัสบางส่วน (แต่ไม่มาก) เพียงเพราะการทำซ้ำรหัสบางอย่างฉันจะไม่แปลงเป็นบริการที่มุ่งเน้น แต่เขาบอกว่าฉันควรใช้ต่อไปเพราะโดยทั่วไปแล้วมันเป็นสถาปัตยกรรมที่ดีมากทำไมโปรแกรมเมอร์จึงหลงใหลในบริการ ฉันพยายาม google บนมัน แต่ฉันยังคงสับสนและไม่สามารถตัดสินใจได้ว่าจะทำอย่างไร

68 design-patterns  architecture  web-services  services  service