จะเกิดอะไรขึ้นถ้าฉันจะไม่ใช้รูปแบบการออกแบบซอฟต์แวร์ [ปิด]


17

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


24
รูปแบบการออกแบบซอฟต์แวร์ค่อนข้างชัดเจน คุณจะต้องรู้จักพวกเขาทั้งหมดอย่างดีเพื่อให้แน่ใจว่าคุณไม่ได้ใช้มัน - อาจจะดีพอที่คุณจะใช้มันได้!
James McLeod

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

6
@JMansfield โค้ดที่แย่ที่สุดที่ฉันเคยเห็นมีส่วนเกี่ยวข้องมากเกินไปสำหรับรูปแบบการออกแบบ
Erik Reppen

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

5
"ลวดลายการออกแบบ" เป็นคำศัพท์ไม่ใช่เทคนิค
Kaz Dragon

คำตอบ:


76

คุณไม่มีจุด

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

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

ดังนั้นประเด็นสำคัญสองข้อที่ฉันพยายามทำ:

  1. คุณไม่สามารถไม่ใช้รูปแบบการออกแบบ
  2. หากไม่ทราบชื่อของสิ่งที่คุณกำลังใช้งานคุณจะมีช่วงเวลาที่ลำบากในการทำงานเป็นทีม

12
+1: ถูกต้องอย่างแน่นอน ฉันเริ่มการพัฒนา OO ก่อนที่จะทราบถึงรูปแบบการออกแบบ ใช่เรายังประดิษฐ์สิ่งต่าง ๆเช่นโรงงานซิงเกิลตันและบางสิ่งที่เมื่อคุณมองมันในรูปแบบของแสงที่สว่างไสวเหมือนรูปแบบกลยุทธ์ ประเด็นก็คือว่าตอนนี้ฉันรู้ว่ารูปแบบการออกแบบฉันรู้ว่าโรงงานได้ตกลง แต่จะได้รับการดำเนินการที่ดีกว่า Singletons ได้ทำไม่ดีและสิ่งที่อาจจะได้รับรูปแบบกลยุทธ์จะได้รับมากดีกว่าถ้ามันเป็นจริงได้รับรูปแบบกลยุทธ์
Binary Worrier

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

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

+1 สำหรับการเปรียบเทียบกับโครงสร้างทางกายภาพ ฉันจะเพิ่มว่ามันจะช่วยสร้างบ้านถ้าคุณรู้อยู่แล้วว่า "มัด" เป็นโครงสร้างที่ดีในการรองรับน้ำหนักของหลังคาแทนที่จะทดลองและหวังว่ามันจะไม่ยุบ
kdgregory

39

คนที่จำอดีตไม่ได้ถูกประณามให้ทำซ้ำ

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

ทุกสิ่งที่ได้รับการพัฒนาในวันนี้ขึ้นอยู่กับความรู้ที่ผ่านมาส่วนใหญ่จะไม่มีเหตุผลที่จะเพิกเฉย ลองนึกภาพการสร้างตึกระฟ้าในวันนี้โดยไม่ทราบว่าต้องเผชิญกับปัญหาที่เกิดจากคนที่สร้างมหาวิหารเมื่อหลายร้อยปีก่อน


10
"ทุกคำพูดมีความเท่าเทียมและตรงกันข้าม" "เราจะต้องฉีกขาดออกจากกันในอดีตหากเราสมควรได้รับอนาคตอย่างแท้จริง" (ตกลงว่าหนึ่งเป็นฮิตเลอร์จึงน่าจะดีที่สุดที่จะไม่สนใจมัน .... )
รัสเซล

20

ฉันอาจประสบปัญหาประเภทใดหากฉันไม่ใช้รูปแบบการออกแบบซอฟต์แวร์

คุณจะมีปัญหาในการไม่สามารถเขียนซอฟต์แวร์ใด ๆ

ตัวแปรเป็นรูปแบบการออกแบบ

วิธีการเป็นรูปแบบการออกแบบ

ผู้ประกอบการ - นอกจากนี้การลบ ฯลฯ - เป็นรูปแบบการออกแบบ

งบเป็นรูปแบบการออกแบบ

ค่าเป็นรูปแบบการออกแบบ

การอ้างอิงเป็นรูปแบบการออกแบบ

นิพจน์เป็นรูปแบบการออกแบบ

คลาสเป็นรูปแบบการออกแบบ

...

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

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

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


1
The things that you have to learn like "the singleton pattern" and so on are simply patterns that haven't (yet) been baked into whatever language you're using.- นั่นคือ (เกือบ) นิยามของรูปแบบการออกแบบ - การสร้างโค้ดที่ยืดหยุ่น / นำมาใช้ซ้ำได้ง่ายที่ใช้ในการเอาชนะข้อ จำกัด ในภาษานั้นเป็นเรื่องง่ายที่จะสื่อสารกับผู้อื่น เมื่อเป็นส่วนหนึ่งของภาษาแล้วจะไม่มีรูปแบบการออกแบบอีกต่อไป
Izkata

1
@Izkata: ดังนั้นตำแหน่งของคุณคือพูดว่ารูปแบบผู้สังเกตการณ์เป็นไปไม่ได้ใน C # เพราะ C # มีรูปแบบผู้สังเกตการณ์ที่สร้างขึ้นในภาษาในรูปแบบของเหตุการณ์หรือไม่ นั่นมันโง่ บิตเฉพาะภาษาที่เกี่ยวข้องกับรูปแบบเป็นวิธีที่ยอมรับในการใช้รูปแบบในภาษา แน่นอนรูปแบบการออกแบบสามารถใช้ในภาษาที่สนับสนุนพวกเขาโดยตรง นั่นคือจุดรวมของการสนับสนุนพวกเขาโดยตรง!
Eric Lippert

ผมไม่เคยบอกว่าเป็นไปไม่ได้ผมพยายามที่จะบ่งบอกถึงการที่ไม่จำเป็น ตัวอย่างเช่น Javaไม่มีเหตุการณ์ดังนั้นจึงใช้รูปแบบการออกแบบเพื่อจำลองเหตุการณ์
Izkata

@Izkata: ฉันสับสนแล้ว คุณบอกว่าเมื่อรูปแบบเป็นส่วนหนึ่งของภาษามันจะไม่เป็นรูปแบบอีกต่อไป ดังนั้น "รูปแบบการสังเกตการณ์" รูปแบบใน Javaแต่ไม่ใช่รูปแบบใน C #?
Eric Lippert

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

4

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

@ กล่าวว่าฉันไม่มีความคิด! @ # $ คิดว่าจุดของฟลายเวทคืออะไรและฉันไม่ละอายที่จะยอมรับ (ดูความคิดเห็นสำหรับรายการ wikipedia อื่นที่ช่วยได้มาก)

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

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

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


2
ฟลายเวท (ไม่ใช่ล้อมู่เล่) อ่านย่อหน้าแรก (และย่อหน้าเดียวเท่านั้น) ของบทความwikipediaแล้วดูที่Integer.valueOf (int)และพิจารณาว่ากี่ครั้งที่สิ่งนี้หลีกเลี่ยงการสร้างจำนวนเต็มใหม่สำหรับค่าทั่วไป

2
@MichaelT และเจ้ากรรม มันสะกดคำออกมาได้ดีกว่าทุกอย่างที่ฉันเคยเห็น ขอบคุณ
Erik Reppen

ปัญหาที่ฉันเห็นด้วยคำแนะนำรูปแบบการออกแบบส่วนใหญ่คือพวกเขาพยายามที่จะให้มุมมองโครงการขนาดใหญ่ (หนังสือ GoF คือทั้งหมดที่เกี่ยวกับการเขียนโปรแกรมประมวลผลคำ - ไม่ใช่งานเล็ก ๆ ) แต่บางครั้งพวกมันสามารถใช้งานได้กับสิ่งเล็ก ๆ (เกือบ 'เล็กน้อย') โค้ด 7 บรรทัดสามารถอธิบายฟลายเวทได้อย่างชัดเจนในสิ่งที่ทุกคนใช้อย่างต่อเนื่อง ง่ายต่อการเข้าใจมากกว่าโครงการขนาดใหญ่หรือตัวอย่างที่คาดหวังไว้

1
@MichaelT สำหรับฉันแล้วมันก็เป็นตัวอย่างที่ดีของการได้ความชัดเจนเล็ก ๆ น้อย ๆ เกี่ยวกับบางสิ่งบางอย่างที่มีประโยชน์ในการเขียนโค้ดโดยทั่วไปแม้ว่าความคิดนั้นจะไม่ได้ใช้งานในภาษาหลักของฉันทันที JavaScript โดยที่มรดกสืบทอดและการปิดต้นแบบ ปัญหา. การมีช่วงเวลา a-ha ยังคงให้ความคิดบางอย่างที่เกี่ยวข้อง
Erik Reppen

2

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


0

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


-1

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.