กระบวนการง่ายๆในการออกแบบระบบ OOP คืออะไรก่อนการเข้ารหัส

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

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

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

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

หากดำน้ำในชั้นเรียนเป็นวิธีที่คุณต้องการรหัสดังนั้นไม่ว่าจะเป็น ให้ฉันบอกคุณคำใบ้ ผัดวันประกันพรุ่ง

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

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

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

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

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

คุณยืนยันว่าการพัฒนาแบบทันทีโดยไม่ต้องมี "แผนเริ่มต้น" คือ:

"... ไม่ใช่วิธีที่เหมาะสมในการสร้างซอฟต์แวร์ ... "

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

หากปัญหาของคุณคือคุณไม่มั่นใจในทักษะการจัดทำเอกสาร / การออกแบบ / UML ของคุณให้ฝึกฝนโดยการทำเอกสารโครงการที่มีอยู่

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

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

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

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

คุณควรพิจารณาใช้คลาสเมื่อคุณตอบตกลงกับคำถามต่อไปนี้:

• ฉันมีกลุ่มของข้อมูลที่เกี่ยวข้องกับแนวคิดเดียวกัน (เช่นชื่อนามสกุลที่อยู่) หรือไม่
• ฉันต้องดำเนินการที่ต้องใช้ข้อมูลหลายชิ้น (เช่นcalculatePrice(basePrice, quantity, tax)) หรือไม่?
• ฉันจะมีอย่างอื่นไหมถ้ามีบล็อคโค้ดขนาดใหญ่ที่มีการทำงานต่างกันเล็กน้อยด้วยข้อมูลเดียวกันหรือคล้ายกัน (เช่นif(type == "cat") { meow(name); } else if (type == "dog") { bark(name); }==> animal.speak())
• ฉันมีคลาสที่มีอยู่แล้วซึ่งทำงานมากกว่าหนึ่งงานที่เฉพาะเจาะจงและมีการเติบโตใหญ่เกินไปหรือไม่

หลังจากนั้นไม่นานก็จะกลายเป็นลักษณะที่สองในการสร้างชั้นเรียน อย่ากลัวที่จะใช้มันหากรหัสของคุณตกอยู่ในกรณีใดกรณีหนึ่งข้างต้น ฉันหวังว่าจะช่วย!

ฉันคิดว่าจุดที่ทำโดยDoc Brownในความคิดเห็นนั้นสมควรได้รับการเปิดเผยมากกว่าความคิดเห็นเนื่องจากเขาพูดถูก:

" ตอนนี้ฉันรู้แล้วว่านี่ไม่ใช่วิธีที่เหมาะสมในการสร้างซอฟต์แวร์ " - ใครบอกคุณสิ่งนี้ ดูเหมือนว่าคุณจะตกหลุมพรางของความเชื่อที่ได้รับความนิยม "การออกแบบเป็นสิ่งที่คุณทำก่อนการเขียนโค้ด เพื่อรักษาคุณจากความเข้าใจผิดนี้ฉันขอแนะนำให้เริ่มต้นด้วย"Code as Design"โดย Jack Reeves - Doc Brown เมื่อ 21 มิ.ย. เวลา 5:27 น

@ Laiv: "การเข้ารหัส" เป็นส่วนหนึ่งของสิ่งที่อยู่ในสาขาวิชาวิศวกรอื่น ๆ ที่เรียกว่าการออกแบบ ในการสร้างบ้านขั้นตอนตั้งแต่การออกแบบไปจนถึงผลิตภัณฑ์สุดท้ายนั้นใช้อิฐถี่และปูน ในการเขียนโปรแกรมขั้นตอนนี้ทำโดยคอมไพเลอร์เมื่อแปลการออกแบบ (= โปรแกรม) เป็นผลิตภัณฑ์สุดท้าย (= ไบนารีที่ปฏิบัติการได้) และนั่นไม่ใช่ภูมิปัญญาใหม่ บทความของรีฟส์มีอายุ 25 ปี - Doc Brown วันที่ 21 มิ.ย. เวลา 6:39 น

ความเชื่อมั่นเดียวกันนี้ยังสะท้อนในที่อื่น ๆ พิจารณาการพูดคุยของ Glenn Vanderburgในหัวข้อ "วิศวกรรมซอฟต์แวร์จริง" และพูดถึง "งานฝีมือวิศวกรรมและสาระสำคัญของการเขียนโปรแกรม" และ "งานฝีมือและวิศวกรรมซอฟต์แวร์" พิจารณาหน้าWhatIsSoftwareDesignและTheSourceCodeIsTheDesign รวมถึงการอภิปรายเกี่ยวกับวิกิ C2

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

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

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

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

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

ความแตกต่างที่สำคัญอย่างหนึ่งระหว่างขั้นตอนวิธีการของ OO คือปกติแล้วความต้องการขั้นตอนการคิดแผนที่ไปที่หน้าจอในขณะที่ OOD มีแนวโน้มที่จะคิดว่าเกิดอะไรขึ้นภายใต้ฝากระโปรงออกจากปลายด้านหน้า

มีเทคนิคในการเขียนโปรแกรมมากเรียกว่าเป็นการ์ดซีอาร์ซี CRC ย่อมาจาก "class-responsibility-collaborators"

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

ทุกระดับบัตรถือคุณเขียนสิ่งที่ความรับผิดชอบของชั้นเรียนที่จะเป็นตัวอย่างเช่น"คำนวณรวมแกรนด์"

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

คุณอาจค้นพบว่าความรับผิดชอบบางอย่างที่คุณคิดว่าเป็นของเป็นInvoceของผู้ทำงานร่วมกันคนหนึ่ง

หลังจากออกกำลังกายการ์ดทุกใบจะกลายเป็นคลาสความรับผิดชอบทุกอย่างจะกลายเป็นวิธีการและความสัมพันธ์ในการทำงานร่วมกันทั้งหมดอาจกลายเป็นองค์ประกอบการรวมหรือการเรียกเพียงอย่างเดียว

การออกกำลังกายนั้นสามารถทำได้ (และควร) ในกลุ่มซึ่งแม้แต่นักธุรกิจก็มีส่วนร่วม

คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับเทคนิคนี้ได้ในลิงก์เหล่านี้:

http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card

http://www.extremeprogramming.org/rules/crccards.html

ตัวอย่างของการ์ด CRC:

ความท้าทายหลักสำหรับเราในฐานะชุมชนของผู้ปฏิบัติงานซอฟต์แวร์ ผู้ปฏิบัติงานออกแบบเชิงวัตถุที่เฉพาะเจาะจงมากขึ้นนั้นคือการทำให้ปัญหา / งานทั้งหมดของเรากลายเป็นประเด็นการเขียนโปรแกรม ไม่ว่าจะเป็นงาน - แสดงเป็นฟังก์ชั่นหรือไม่ว่าจะเป็นนักแสดงของงาน - แสดงเป็นอินเทอร์เฟซ / คลาส [ขับรถไปที่ OOAD] เมื่อเราพัฒนาพฤติกรรมการออกแบบซอฟต์แวร์ของเราโดยการเพิ่มพูนความรู้เกี่ยวกับวิธีการ / กรอบต่าง ๆ อย่างต่อเนื่อง มุมมองของเราได้รับการปรับปรุงให้มากขึ้นเรื่อย ๆ ไปสู่การแยกวัตถุอย่างชัดเจนและวัตถุใดที่จะทำหน้าที่ใด

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

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

ยกตัวอย่างของผู้ผลิตรถยนต์ที่มีรถยนต์หลากหลายประเภท ได้แก่ รถยนต์เพื่อการพาณิชย์รถยนต์เพื่อผู้บริโภค (รถเก๋งรถแฮทช์แบ็ครถสเตชั่นแวกอน) เป็นต้น

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

1. ขึ้นอยู่กับหมวดหมู่ (ภาคการตลาด) ของยานพาหนะ: ยานพาหนะหนัก, ยานพาหนะสำหรับผู้บริโภค [ซีดาน, รถยนต์, สเตชั่นแวกอน ฯลฯ ]

2. ขึ้นอยู่กับความจุของเครื่องยนต์และลักษณะการขับขี่: 800-1500 CC,> 1500 CC เป็นต้น

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