เหตุใดจึงไม่เพิ่มรูปแบบการออกแบบในการสร้างภาษา

เมื่อเร็ว ๆ นี้ฉันได้พูดคุยกับเพื่อนร่วมงานที่กล่าวว่า บริษัท ของเขากำลังทำงานเพื่อเพิ่มรูปแบบการออกแบบ MVC เป็นส่วนขยาย PHP

เขาอธิบายว่าพวกเขาเขียนรหัส C เพื่อเพิ่มControllers, Models and Viewsโครงสร้างภาษาเพื่อเพิ่มประสิทธิภาพ

ตอนนี้ฉันรู้แล้วว่า MVC เป็นรูปแบบการออกแบบสถาปัตยกรรมที่ใช้กันอย่างแพร่หลายในเว็บแอปพลิเคชัน แต่ฉันยังต้องเจอภาษาที่มีโครงสร้างภาษาสำหรับตัวควบคุม

IMHO การรวมรูปแบบการออกแบบเป็นภาษาสามารถเน้นความสำคัญของการออกแบบ OO ที่ดี

ดังนั้นทำไมรูปแบบการออกแบบที่ไม่ได้ใช้มากที่สุด (MVC, Factory, Strategy, ... ฯลฯ ) เพิ่มลงในโครงสร้างภาษา

หากคำถามฟังดูกว้างเกินไปคุณอาจ จำกัด คำถามไว้ที่ PHP เท่านั้น

แก้ไข:

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

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

สิ่งที่เกี่ยวกับรูปแบบการออกแบบห่วง ? ขณะที่ห่วงการออกแบบรูปแบบ? สวิทช์การออกแบบรูปแบบ? วัตถุออกแบบรูปแบบ? ชั้นออกแบบรูปแบบ? ทั้งหมดเหล่านี้ได้รับการเพิ่มในบางภาษา

บางคนก็มี ตัวอย่างเช่นตัววนซ้ำนั้นเป็นคุณลักษณะทางภาษาในหลาย ๆ ภาษาและไลบรารีมาตรฐานของพวกเขา (หวัดดี, foreach และ return return) ผู้สังเกตการณ์มักปรากฏในรูปแบบของเหตุการณ์ (ไม่ใช่ใน PHP - คุณต้องจัดการการสมัครสมาชิกด้วยตนเอง) คำสั่งเป็นคุณสมบัติหลักใน WPF

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

ส่วนประกอบเดียวของ MVC ที่ IMO จะได้รับประโยชน์จากการสนับสนุนด้านภาษาบางประเภทคือ View (พร้อมด้วยเครื่องมือสร้างเทมเพลตอย่างเป็นทางการ) - และใน PHP ได้รับการสนับสนุนแล้ว - คุณสามารถสร้างและโหลดสคริปต์ PHP แบบไดนามิกได้ การประมวลผลล่วงหน้าบางประเภทใช้เป็นเทมเพลต)

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

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

แต่เพื่อมุ่งเน้นคำถาม - มีหลายสาเหตุที่คุณไม่ต้องการเพิ่มรูปแบบการออกแบบมากเกินไปในภาษา:

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

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

ทำไมรูปแบบการออกแบบที่ใช้มากที่สุด (MVC, Factory, Strategy, ... ฯลฯ ) ไม่ถูกเพิ่มในโครงสร้างภาษา

รูปแบบเหล่านี้ส่วนใหญ่สามารถนำไปใช้ในภาษาการเขียนโปรแกรมส่วนใหญ่โดยไม่มีการสนับสนุนทางภาษาที่เฉพาะเจาะจง ใช้อินสแตนซ์ MVC ใน Java:

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

ด้วยตัวเลือกเหล่านี้ทั้งหมดมีค่าเล็กน้อยในการขยายภาษาโดยตรง และมีจำนวน "ข้อเสีย":

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

พวกเขาคือ.

ฟังก์ชั่นเป็นรูปแบบการออกแบบในรหัสการประกอบก่อนที่พวกเขาจะกลายเป็นภาษาสร้างใน C.

ฟังก์ชั่นเสมือนเป็นรูปแบบการออกแบบใน C ก่อนที่พวกเขาจะกลายเป็นสร้าง langiage ใน C ++

อย่างไรก็ตามมีการแลกเปลี่ยนเป็น หากรูปแบบเกี่ยวข้องกับการผลิตรหัสสำเร็จรูป (แม้แต่คำหลักสองสามคำ) นั่นเป็นข้อบ่งชี้ว่ามันจะเป็นคุณสมบัติภาษาที่มีประโยชน์ แต่ถ้ารูปแบบนั้นเรียบง่ายและชัดเจนเช่น C "สำหรับ (int i = 0; i <10; i ++)" มันยังคงมีประโยชน์สำหรับทุกคนที่จะเขียนแบบเดียวกัน แต่มันก็ไม่ได้ยาวกว่า "for i = 0 ถึง 10" อย่างมีนัยสำคัญและมีข้อได้เปรียบที่สำคัญ เห็นได้ชัดว่าจะแก้ไขมันอย่างไรเพื่อทำให้เกิดลูปที่ต่างกันเล็กน้อย

อ่านหนังสือ 'แก๊งสี่' และมันจะกลายเป็นที่ชัดเจนว่า:

1. รูปแบบการออกแบบในหนังสือเล่มนี้เป็นที่รู้จักกันดีว่าเป็นข้อตกลง smalltalk ที่เข้ารหัสในภาษา OO อื่น ๆ
2. ดังนั้นรูปแบบเหล่านั้นจึงไม่สามารถรวมอยู่ในภาษา OO ได้ - จะเป็นการปรับใช้ smalltalk ภายในภาษาเหล่านั้น - ควรใช้ smalltalk โดยตรง
3. เหตุใดรูปแบบการออกแบบจึงมีประโยชน์เพราะไม่เน้นบทบาทของภาษาที่ใช้ในปัจจุบันและเน้นประเด็นอื่นที่ไม่ใช่ไวยากรณ์ การเข้ารหัสรูปแบบเหล่านั้นในภาษาจะทำให้คุณสมบัติการออกแบบรูปแบบนี้สูญเสียไป
4. ปัญหาที่แท้จริงในคำถามข้างต้นคือมันพลาดจุดที่การเขียนซอฟต์แวร์ไม่เพียง แต่เกี่ยวกับการเรียนรู้ภาษา เป็นเรื่องสำคัญที่จะต้องให้ห่างจากภาษาที่ให้โดยตรงและมุ่งเน้นไปที่ข้อกำหนดปัจจุบัน

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

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

เอ๊ะคำถามค้าง แต่ฉันไม่เห็นด้วยกับคำตอบมากมายขึ้นอยู่กับที่คุณตั้ง "รูปแบบการออกแบบ" บนหน้าปัดความหมายรวมถึงการยอมรับ

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

ในทางกลับกัน Iterator เป็นแนวคิดทั่วไปสูงที่สามารถนำไปใช้ในหลากหลายวิธีเพื่อการก่อสร้างที่หลากหลาย

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