ขณะที่คุณพยายามค้นหาคุณลักษณะใหม่ๆ ในแอปพลิเคชันของคุณต่อไป คุณพบว่าโซลูชันที่คุณเสนอมีความคล้ายคลึงกับบางสิ่งที่คุณเคยใช้งานมาก่อนหรือไม่ หากคุณเป็นโปรแกรมเมอร์ (แม้ว่าคุณจะเพิ่งเริ่มต้นได้เพียงช่วงสั้นๆ ก็ตาม) คุณก็อาจจะตอบว่า "ใช่" ดูเหมือนว่าคุณกำลังใช้โค้ดเก่าเพื่อแก้ไขปัญหาที่เพิ่งค้นพบในระหว่างการพัฒนาซอฟต์แวร์ คุณอาจตระหนักว่าโซลูชันของคุณเป็นหลักการพื้นฐาน ซึ่งเป็นวิธีการที่สามารถทำซ้ำได้อย่างกว้างขวาง ไม่เพียงแต่โดยคุณเท่านั้น แต่โดยนักพัฒนามืออาชีพทุกคนด้วย
ในความเป็นจริง มีปัญหาการเขียนโปรแกรมมากมายเกิดขึ้นซ้ำแล้วซ้ำอีก และวิธีการพื้นฐาน (หรือรูปแบบการออกแบบ) มากมายสำหรับการแก้ปัญหาเหล่านี้ก็ได้เกิดขึ้น รูปแบบการออกแบบคือเทมเพลตที่สอนวิธีจัดระเบียบโค้ดของคุณโดยใช้การออกแบบที่น่าเชื่อถือและเชื่อถือได้
ประวัติรูปแบบการออกแบบ
คำว่า "รูปแบบการออกแบบ" เดิมมีบัญญัติไว้ในสาขาสถาปัตยกรรม ในหนังสือ "A Pattern Language: Towns/Building/Construction" ของเขาเมื่อปี 1977 คริสโตเฟอร์ อเล็กซานเดอร์ อธิบายถึงปัญหาการออกแบบสถาปัตยกรรมทั่วไปบางประการ และอธิบายวิธีใช้คอลเลกชั่นของรูปแบบที่รู้จักกันดีที่มีอยู่เพื่อเริ่มการออกแบบใหม่ที่มีประสิทธิภาพ มุมมองของ Alexander แปลได้ดีต่อการพัฒนาซอฟต์แวร์ และมีความเห็นพ้องต้องกันในระยะยาวเกี่ยวกับการใช้ส่วนประกอบที่มีอยู่เพื่อสร้างโซลูชันใหม่
รูปแบบการออกแบบทั้งหมดมีลักษณะทั่วไปบางประการ: ชื่อ คำชี้แจงปัญหา และวิธีแก้ไข
1. การระบุรูปแบบการออกแบบมีความสำคัญเนื่องจากช่วยให้โปรแกรมเมอร์คนอื่นเข้าใจวัตถุประสงค์ของโค้ดของคุณได้ทันทีโดยไม่ต้องศึกษาอย่างลึกซึ้งเกินไป (อย่างน้อยผ่านการระบุนี้ โปรแกรมเมอร์จะคุ้นเคยกับรูปแบบนี้) -
2. คำอธิบายปัญหาใช้เพื่อแสดงขอบเขตการใช้งานของรุ่นนี้ -
3. โซลูชันจะอธิบายการดำเนินการของโมเดลนี้ การอภิปรายที่ดีเกี่ยวกับรูปแบบการออกแบบควรครอบคลุมถึงข้อดีและข้อเสียของการใช้แบบจำลอง -
ขยาย
