ไม่สามารถเข้าใจรูปแบบการออกแบบโปรแกรมมิง

16

ฉันทำงานกับ javascript ตลอด 4 ปีที่ผ่านมา ฉันมีความมั่นใจมากเกี่ยวกับทักษะการแก้ปัญหาของฉันและฉันเห็นได้ว่าคุณภาพรหัสของฉันดีขึ้น ฉันพยายามติดตามชุมชนและฉันกำลังทำงานกับ ES2015 และ React.js อย่างไรก็ตามฉันรู้สึกว่าฉันไม่สามารถเข้าใจรูปแบบการออกแบบโปรแกรมได้เลย ฉันรู้ว่าจะหาแหล่งข้อมูลเกี่ยวกับเรื่องนี้ได้ที่ไหนและฉันได้อ่านหนังสือเกี่ยวกับเรื่องนี้แล้ว ฉันพึ่งพาเพื่อนร่วมงานอาวุโสของฉันในการตัดสินใจเกี่ยวกับโครงสร้างโครงการ แต่ฉันไม่มีปัญหาในการทำงาน

เมื่อใดก็ตามที่ฉันต้องการเริ่มต้นด้วยตัวเองฉันจะมองหาสองเส้นทางนี้: ถ้าฉันใช้ห้องสมุด / กรอบใหญ่อย่าง React.js ฉันมักจะคัดลอกสิ่งที่ชุมชนกำลังทำอยู่ ถ้าฉันทำอะไรที่เล็กลงฉันจะใช้รูปแบบโมดูล ฉันรู้ว่าเมื่อฉันได้รับความเข้าใจที่ดีขึ้นในเรื่องนี้ฉันจะสามารถตัดสินใจได้ดีขึ้น แต่ตอนนี้ฉันหลงทางไปแล้ว

ฉันควรมองหาการศึกษาขั้นสูงในเรื่องนี้หรือไม่? ฉันต้องการที่ปรึกษาในเรื่องนี้หรือไม่? ฉันแค่โง่เหรอ? นี่มันยากที่จะเข้าใจใช่ไหม

design-patterns javascript

— Abensur
แหล่งที่มา

6

ในความคิดของฉันมีบางภาษาที่ 'ให้อภัย' มากกว่าคนอื่นเมื่อพูดถึงความจำเป็นในการใช้รูปแบบการออกแบบ ภาษาที่ถูกรวบรวมที่พิมพ์อย่างรุนแรง (เช่น Java และ C #) ได้รับผลกระทบจากการออกแบบที่ไม่ดีมากกว่าภาษาสคริปต์ที่พิมพ์อย่างอ่อนเช่น JavaScript และ PHP ไม่ต้องบอกว่ารูปแบบการออกแบบนั้นไม่มีประโยชน์สำหรับทั้งคู่

— แมทธิว

3

ขนาดของโครงการก็มีบทบาทสำคัญเช่นกัน

— แมทธิว

2

nitpick @ Matthew ฉันจะไม่จำเป็นต้องโทร Java / C # ขอพิมพ์ ...

— Jared สมิ ธ

2

@ JaredSmith จริงฉันมักจะลืมความแตกต่างระหว่างพิมพ์อย่างยิ่งและพิมพ์แบบคงที่

— แมทธิว

6

หากคุณพยายามทำรูปแบบโดยทั่วไปให้หยุด! ไม่มีอะไรที่นั่น! รูปแบบเป็นวิธีการแก้ปัญหาที่เป็นที่นิยมสำหรับปัญหาที่เกิดขึ้นโดยทั่วไปและมีคนตั้งชื่อ นั่นคือทั้งหมดที่มีให้มัน คุณอาจพบว่ามันยากที่จะเข้าใจรูปแบบเฉพาะบางอย่าง - ฉันต่อสู้กับการจดจำวิธีการใช้รูปแบบ "ผู้เยี่ยมชม" อย่างมีประสิทธิภาพเพื่อเลียนแบบการจัดส่งแบบคู่ใน Java - แต่ถ้าคุณกำลังมองหาซอสลับที่เชื่อมโยง "ผู้เข้าชม" เพื่อพูดว่า "data transfer object" คุณจะไม่พบมัน พวกเขาเป็นเพียงสองวิธีที่ได้รับความนิยมสำหรับสองปัญหาทั่วไปบางคนตั้งชื่อให้พวกเขาและชื่อก็ติดอยู่

— โซโลมอนช้า

34

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

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

สิ่งสำคัญที่ควรทราบเกี่ยวกับรูปแบบการออกแบบ:

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

— โรเบิร์ตฮาร์วีย์
แหล่งที่มา

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

— Polygnome

1

รูปแบบของ Gof มีอายุ20 ปี ส่วนใหญ่ถูกสร้างขึ้นเพื่อแก้ไขปัญหาเกี่ยวกับ C ++ ปัญหาที่ Java สืบทอดเนื่องจาก Java ใช้ C ++

— Robert Harvey

ความขัดแย้งในคำตอบนี้เป็นส่วน "ปัญหาที่รู้จักกันดี" เป็นการยากที่จะเข้าใจ "ปัญหาที่รู้จักกันดี" เหล่านี้หากคุณไม่เคยพบเจอ

— Fuhrmanator

2

Java ไม่ได้ขึ้นกับ C ++ ไวยากรณ์ javas ได้รับแรงบันดาลใจจาก C ++ แต่ไม่ได้ขึ้นอยู่กับมัน ทั้งสองภาษาทำงานแตกต่างกันมาก จากข้อเท็จจริงที่ว่า Java abstact hardware, จัดการหน่วยความจำด้วยตัวเอง, ไม่ได้มีเทมเพลต แต่เป็น generics ฯลฯ

— Polygnome

4

วิธีการเรียนรู้ของทุกคนแตกต่างกันเล็กน้อยและฉันก็ไม่รู้ว่าวิธีการทั่วไปของคุณคืออะไร แต่ฉันเชื่อว่าการที่คุณทำให้ตัวเองเป็นความเสียหายโดยการติดฉลากตัวเองว่า "โง่"

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

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

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

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

— ดาวเคราะห์รกร้าง
แหล่งที่มา

1

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

— เอเดรียน Iftode

@AdrianIftode - เห็นด้วย ดังที่ได้กล่าวมาแล้วฉันจะไม่ลดราคาหนังสือบล็อกหรือสื่อการอ่านใด ๆ แต่เป็นปัญหาทั่วไปที่ฉันพบกับผู้ที่พยายามเรียนรู้ในภาษาโปรแกรม / แพลตฟอร์ม / กรอบงานและดูเหมือนว่าพวกเขาได้ทำการเข้ารหัสและ / ความพยายาม แต่ได้อ่านหนังสือทุกเล่มที่คุณสามารถสั่นคลอนได้

— อ้างว้างดาวเคราะห์

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

— cmaster - คืนสถานะโมนิกา

1

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

ตัวอย่าง: ระบบเหตุการณ์ของ JavaScript มักไม่เพียงพอต่องานในมือ คุณไม่เคยพบว่าตัวเองต้องการรวมหรือแปลงกระแสของเหตุการณ์หรือไม่? หรือชุดของเหตุการณ์นั้นเป็นค่าชั้นหนึ่งในสิทธิของตนเอง? คุณต้องมีรูปแบบผู้ไกล่เกลี่ยและ / หรือผู้สังเกตการณ์ ต้องการการเชื่อมโยงข้อมูลแบบสองทางหรือไม่ เรื่องเดียวกัน

ลำดับชั้นต้นแบบที่เปราะบางลงไปได้อย่างไร Mixin / Trait / Subclass Factory ลวดลายเพื่อช่วยเหลือ

— Jared Smith
แหล่งที่มา

4

แทบจะเป็นไปไม่ได้เลยที่จะเขียนโปรแกรมที่ไม่สำคัญโดยไม่ใช้รูปแบบการออกแบบใด ๆ โดยทั่วไปคุณจะใช้โปรแกรมทั่วไปเช่นกัน สิ่งที่คุณไม่ต้องการคือสามารถจดจำรูปแบบที่คุณใช้โดยใช้ชื่อ คุณสามารถเขียนโค้ดที่ใช้งานได้แม้ว่าคุณจะไม่สามารถตั้งชื่อรูปแบบการออกแบบทั้งหมดที่คุณใช้ตลอดทั้งรหัสได้

— Servy

@Servy รูปแบบการออกแบบเป็น abstractions, abstractions ไม่จำเป็นอย่างเคร่งครัด คุณสามารถเขียนการใช้งานพฤติกรรมแบบแฝงแบบ one-off ได้เสมอ ... ซ้ำแล้วซ้ำอีก ยกตัวอย่างเช่นในตัวอย่างที่ฉันให้เกี่ยวกับเหตุการณ์มันเป็นไปได้ที่จะเชื่อมโยงทุกฝ่ายที่เกี่ยวข้องด้วยตนเองและจากนั้นเปลี่ยนพวกเขาทั้งหมดทุกครั้งที่มีการเปลี่ยนแปลงข้อกำหนดมันเพิ่งแย่เมื่อเทียบกับการใช้ pub / sub สำหรับคลาสย่อยที่เป็นไปได้ (หากสิ้นเปลือง) ในการเขียนโค้ดด้วยตัวเองในทุก ๆ ความเป็นไปได้ด้วยการใช้คลาสแบบครั้งเดียวมันไม่ดีเท่าไหร่

— Jared Smith

1

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

— Servy

@Servy ถ้านั่นเป็นวิธีที่คุณใช้คำนั้นฉันไม่เห็นด้วย แต่ฉันได้รับความประทับใจว่า OP หมายถึงรูปแบบ GOFish โดยเฉพาะ

— Jared Smith

1

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

— Polygnome

1

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

พิเศษ:

ทำงานร่วมกันกับโครงการ OSS ง่ายๆที่คุณชอบ
เมื่อมีวิธีการแก้ไขปัญหาสองวิธีให้เลือกวิธีที่ง่ายกว่าเสมอ
สร้างประสบการณ์พิเศษด้วยโครงการด้านที่คุณมีอิสระที่จะทำข้อผิดพลาดแปลก ๆ ทุกประเภทและคุณจะได้เรียนรู้รูปแบบการออกแบบ "ยาก" (tm)

— Motocarota
แหล่งที่มา