คุณออกแบบโครงการเชิงวัตถุได้อย่างไร [ปิด]

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

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

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

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

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

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

ขั้นตอนที่ฉันใช้สำหรับการออกแบบเริ่มต้น (การไปที่คลาสไดอะแกรม) คือ:

1. รวบรวมความต้องการ พูดคุยกับลูกค้าและแยกแยะกรณีการใช้งานเพื่อกำหนดฟังก์ชันการทำงานที่ซอฟต์แวร์ควรมี

2. เขียนคำบรรยายกรณีการใช้งานส่วนตัว

3. ผ่านการบรรยายและเน้นคำนาม (บุคคล, สถานที่, สิ่งของ), เป็นคลาสผู้สมัครและคำกริยา (การกระทำ), เป็นวิธีการ / พฤติกรรม

4. ยกเลิกคำนามที่ซ้ำกันและแยกการทำงานทั่วไปออก

5. สร้างแผนภาพคลาส หากคุณเป็นผู้พัฒนา Java NetBeans 6.7 จาก Sun มีโมดูล UML ที่อนุญาตให้สร้างไดอะแกรมรวมถึงวิศวกรรมไปกลับและไม่เสียค่าใช้จ่าย Eclipse (โอเพนซอร์ส Java IDE) ก็มีเฟรมเวิร์กโมเดล แต่ฉันไม่เคยมีประสบการณ์มาก่อน คุณอาจต้องการลอง ArgoUML ซึ่งเป็นเครื่องมือโอเพนซอร์ส

6. นำหลักการของ OOD ไปใช้ในการจัดชั้นเรียนของคุณ

เพิ่มไปยังสิ่งที่ Scott Davies ได้กล่าว:

1. ตรวจสอบให้แน่ใจว่าคุณรู้ว่าโปรแกรมของคุณเกี่ยวกับอะไรก่อนที่จะเริ่ม โปรแกรมของคุณคืออะไร? มันจะไม่ทำอะไร? ปัญหาอะไรที่พยายามแก้ไข

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

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

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

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

แค่สองเซ็นต์ของฉัน หวังว่ามันจะมีประโยชน์

เมื่อฉันมีโอกาสฉันมักจะใช้สิ่งที่ฉันเรียกว่า "กฎการทำซ้ำสามครั้ง"

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

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

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

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

ดังนั้นสรุป:

1. ในการทำซ้ำคุณจะได้ลิ้มรสและเรียนรู้
2. ในการทำซ้ำสองคุณทำความสะอาดผลิตภัณฑ์ของคุณและเตรียมความพร้อมสำหรับอนาคต
3. ในการทำซ้ำสามคุณเพิ่มคุณสมบัติใหม่และเรียนรู้เพิ่มเติม
4. ข้ามไป 2

แหล่งที่น่าสนใจที่สุดที่ฉันรู้เกี่ยวกับเรื่องนี้คือส่วนที่ D ของการสร้างซอฟต์แวร์เชิงวัตถุรุ่นที่ 2โดย Bertrand Meyer

ส่วน D: วิธีการเชิงวัตถุ: การใช้วิธีการที่ดี

19: เกี่ยวกับวิธีการ, 20: รูปแบบการออกแบบ: ระบบโต้ตอบหลายแผง, 21: มรดกกรณีศึกษา: "เลิกทำ" ในระบบโต้ตอบ, 22: วิธีการหาชั้นเรียน , 23: หลักการออกแบบชั้นเรียน, 24: การใช้มรดกอย่างดี , 25: เทคนิคที่มีประโยชน์, 26: ความรู้สึกมีสไตล์, 27: การวิเคราะห์เชิงวัตถุ, 28: กระบวนการสร้างซอฟต์แวร์, 29: การสอนวิธีการ

น่าสนใจในบทที่22 จะหาชั้นเรียนได้ทางออนไลน์

ซ้ำแล้วซ้ำอีก แต่เป็นจริงอย่างสมบูรณ์ - เข้าใจข้อมูลของคุณ

สำหรับ OOP ชั้นเรียนของคุณควรอธิบายข้อมูลที่สำคัญและวิธีการโต้ตอบ

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

นี่เป็นเพียงส่วนเสริม: รู้ว่าคุณกำลังพยายามทำอะไร

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

http://behaviour-driven.org/

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

ก่อนอื่นให้ลองคิดจากระดับนามธรรมที่สูงขึ้น คิดเกี่ยวกับองค์ประกอบที่สำคัญและความรับผิดชอบของพวกเขา (ส่วนต่อประสานกับส่วนประกอบอื่น ๆ ) ดูรูปแบบสถาปัตยกรรมบางอย่างเพื่อเป็นแรงบันดาลใจ (ไม่ไม่ใช่รูปแบบการออกแบบสิ่งเหล่านี้อยู่ในระดับต่ำเกินไป! MVC และ Multi-Tier เป็นตัวอย่างรูปแบบสถาปัตยกรรม) สำหรับโครงการที่มีขนาดใหญ่พอสมควรมุมมองดังกล่าวควรมีองค์ประกอบประมาณ 3-5 รายการ

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

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

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

ในระยะสั้นมาก: ใช้ OO และหลักการซ่อนข้อมูลและดึงมันขึ้นอีกระดับ!

PS: วาดภาพจำนวนมากขณะออกแบบมันเหมือนกับสถาปัตยกรรมจริง ๆ !

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

เทคนิคที่ฉันใช้ในโครงการจริงที่ประสบความสำเร็จพอสมควรคือ Responsibility Driven Design ซึ่งได้แรงบันดาลใจจากหนังสือของ Wirfs-Brock

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

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

การรู้ว่าเมื่อใดที่จะหยุดเป็นเรื่องของการตัดสิน (ซึ่งมาพร้อมกับประสบการณ์เท่านั้น)

รูปแบบการออกแบบ

รูปแบบการออกแบบที่สร้างสรรค์

Singleton - ตรวจสอบให้แน่ใจว่ามีการสร้างคลาสอินสแตนซ์เดียวเท่านั้นและระบุจุดเชื่อมต่อส่วนกลางไปยังวัตถุ

Factory (เวอร์ชันง่ายของ Factory Method) - สร้างวัตถุโดยไม่ต้องเปิดเผยตรรกะการสร้างอินสแตนซ์ไปยังไคลเอนต์และอ้างอิงไปยังวัตถุที่สร้างขึ้นใหม่ผ่านอินเทอร์เฟซทั่วไป

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

Abstract Factory - เสนออินเทอร์เฟซสำหรับสร้างตระกูลของวัตถุที่เกี่ยวข้องโดยไม่ต้องระบุคลาสของพวกเขาอย่างชัดเจน

ตัวสร้าง - กำหนดอินสแตนซ์สำหรับการสร้างวัตถุ แต่ให้คลาสย่อยตัดสินใจว่าคลาสใดที่จะสร้างอินสแตนซ์และอนุญาตให้ควบคุมได้อย่างละเอียดยิ่งขึ้นในกระบวนการก่อสร้าง

Prototype - ระบุชนิดของวัตถุที่จะสร้างโดยใช้อินสแตนซ์ต้นแบบและสร้างวัตถุใหม่โดยการคัดลอกต้นแบบนี้

รูปแบบการออกแบบเชิงพฤติกรรม

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

คำสั่ง - ห่อหุ้มคำขอในวัตถุอนุญาตให้กำหนดพารามิเตอร์ของไคลเอนต์ที่มีการร้องขอที่แตกต่างกันและช่วยให้บันทึกคำขอในคิว

ล่าม - ให้ภาษากำหนดการเป็นตัวแทนของไวยากรณ์พร้อมกับล่ามที่ใช้การเป็นตัวแทนในการตีความประโยคในภาษา / แมปโดเมนกับภาษาภาษาไวยากรณ์และไวยากรณ์การออกแบบเชิงวัตถุแบบลำดับชั้น

Iterator - ให้วิธีการเข้าถึงองค์ประกอบของวัตถุรวมตามลำดับโดยไม่ต้องเปิดเผยการเป็นตัวแทนพื้นฐาน

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

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

กลยุทธ์ - กำหนดตระกูลของอัลกอริธึมแค็ปซูลแต่ละอันและทำให้มันแทนกันได้ กลยุทธ์ช่วยให้อัลกอริทึมแตกต่างจากลูกค้าที่ใช้งาน

วิธีเทมเพลต - กำหนดโครงกระดูกของอัลกอริทึมในการดำเนินการโดยการเลื่อนขั้นตอนบางอย่างไปที่คลาสย่อย / วิธีเทมเพลตช่วยให้คลาสย่อยกำหนดขั้นตอนบางอย่างของอัลกอริทึมใหม่โดยไม่ให้พวกเขาเปลี่ยนโครงสร้างของอัลกอริทึม

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

Null Object - ให้วัตถุเป็นตัวแทนสำหรับการขาดวัตถุประเภทที่กำหนด / Null Object Pattern ไม่แสดงพฤติกรรมใด ๆ อย่างชาญฉลาดซ่อนรายละเอียดจากผู้ทำงานร่วมกัน

รูปแบบการออกแบบโครงสร้าง

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

Bridge - เขียนวัตถุลงในโครงสร้างต้นไม้เพื่อแสดงลำดับชั้นทั้งส่วน / คอมโพสิตช่วยให้ลูกค้าปฏิบัติต่อวัตถุและองค์ประกอบของวัตถุอย่างสม่ำเสมอ

Composite - เขียนวัตถุลงในโครงสร้างต้นไม้เพื่อแสดงลำดับชั้นทั้งส่วน / คอมโพสิตช่วยให้ลูกค้าปฏิบัติต่อวัตถุและองค์ประกอบของวัตถุอย่างสม่ำเสมอ

มัณฑนากร - เพิ่มความรับผิดชอบเพิ่มเติมแบบไดนามิกให้กับวัตถุ

Flyweight - ใช้การแบ่งปันเพื่อสนับสนุนวัตถุจำนวนมากที่มีส่วนหนึ่งของสถานะภายในเหมือนกันโดยที่ส่วนอื่น ๆ ของรัฐสามารถเปลี่ยนแปลงได้

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

พร็อกซี - ระบุ“ ตัวยึด” สำหรับวัตถุเพื่อควบคุมการอ้างอิง

ฉันอยากจะแนะนำให้คุณใช้BlueJและ ActiveWriter เพื่อเรียนรู้และพัฒนาความเข้าใจที่ดีเกี่ยวกับวัตถุ หนังสือที่แนะนำนี้ยังเป็นแหล่งข้อมูลที่ดีอีกด้วย

จากWikipedia :

BlueJ เป็นสภาพแวดล้อมการพัฒนาแบบรวมสำหรับภาษาการเขียนโปรแกรม Java ซึ่งพัฒนาขึ้นเพื่อวัตถุประสงค์ทางการศึกษาเป็นหลัก แต่ยังเหมาะสำหรับการพัฒนาซอฟต์แวร์ขนาดเล็ก

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

alt text http://www.ryanknu.com/ryan/bluej.png

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

_{(ที่มา: altinoren.com )}

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

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

และสุดท้าย - ลองอ่านสิ่งนี้: อัลกอริทึมของการคิดสร้างสรรค์

เพียงแค่อ้างถึงhttp://www.fysh.org/~katie/computing/methodologies.txt

และที่แกนกลางของ RUP เป็นพื้นที่เล็ก ๆ ที่คุณต้องใช้ความสามารถในการออกแบบของ OO .... ถ้าคุณไม่มีมันก็เหมือนมีวิธีการในการวิ่ง 100m

"ขั้นตอนที่ 1: เขียนเกี่ยวกับการวิ่งเร็วจริง ๆ ขั้นตอนที่ 2: ไปและวาดแผนของสนามแข่งขั้นตอนที่ 3: ไปและซื้อกางเกงขาสั้นไลคร่าแน่นจริง ๆ ขั้นที่ 4: วิ่งเร็วจริงๆเร็วจริงๆขั้นที่ 5: ข้ามเส้นแรก "

มันเป็นขั้นตอนที่ 4 นั่นคือสิ่งที่ยาก แต่ถ้าคุณให้ความสำคัญกับ 1,2,3 และ 5 เป็นไปได้ไม่มีใครสังเกตได้และคุณอาจทำเงินได้มากเพื่อขายวิธีการที่จะเป็นนักกีฬาที่คิดว่ามี "ความลับ" ถึง 100m วิ่งมากกว่า

คุณถามคำถามว่าผู้เขียนจำนวนมากใช้ในการเขียนหนังสือ มีวิธีการมากมายและคุณควรเลือกหนึ่งที่ดูเหมือนว่า "สวยที่สุด" สำหรับคุณ
ฉันสามารถแนะนำหนังสือ"Domain Driven Design"โดย Eric Evans นอกจากนี้การตรวจสอบเว็บไซต์dddcommunity.org

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

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

ใช่ถ้าคุณทำงานในโลกแห่งความเป็นจริงมานานกว่า 5 ปีแล้วคุณจะเลือกระหว่างแบบจำลองหรือกระบวนการพัฒนาซอฟต์แวร์จำนวนมาก

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

หากไม่สามารถทำได้คุณควรทำด้วยตัวเอง เริ่มต้นทำซ้ำโดยการเขียนโค้ดที่น่ารังเกียจมากเรียนรู้ข้อผิดพลาดของคุณทิ้งมันทั้งหมดเขียนโค้ดที่ดีขึ้นเรื่อย ๆ

คุณจะได้เรียนรู้มากมายเกี่ยวกับ codebase ของคุณ เครื่องมือเป็นเครื่องมือพวกเขาจะไม่สอนอะไรคุณ

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

หากคุณไม่มีความเชี่ยวชาญนั้นจะทำงานกับคนที่มีความเชี่ยวชาญนั้นและแปลงความคิดเหล่านั้นเป็นรายละเอียดทางเทคนิค

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

1. รูปแบบการออกแบบการศึกษาและต้นแบบ
2. จากนั้นเรียนรู้เกี่ยวกับการออกแบบการขับเคลื่อนโดเมน
3. หลังจากนั้นเรียนรู้การรวบรวมความต้องการ

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

4. คุณรู้เกี่ยวกับขั้นตอนที่ 3 คุณต้องมีความเชี่ยวชาญ ฉันหมายความว่าผ่านการฝึกฝนมากมายเพื่อให้เป็นธรรมชาติที่สองของคุณ นั่นเป็นเพราะวิธีการที่คุณเรียนรู้นั้นขัดกับวิธีที่เราเคยมี ดังนั้นคุณต้องมีความเชี่ยวชาญจริงๆ มิฉะนั้นคุณจะพบว่าตัวเองกลับไปสู่วิธีดั้งเดิมในการทำสิ่งต่างๆ นี่เป็นเหมือน Test Testen Process ซึ่งผู้พัฒนาจาวาจำนวนมากยอมแพ้หลังจากลองมาหลายครั้ง เว้นแต่พวกเขาจะเชี่ยวชาญอย่างเต็มที่มิฉะนั้นมันก็เป็นภาระของพวกเขา

5. กรณีใช้งานการเขียนโดยเฉพาะอย่างยิ่งสำหรับหลักสูตรอื่น หลักสูตรอื่นใช้เวลามากกว่า 50% ของเวลาในการพัฒนาของเรา โดยปกติเมื่อ PM ของคุณมอบหมายงานให้คุณเช่นสร้างระบบเข้าสู่ระบบเขาจะคิดว่ามันตรงไปตรงมาคุณสามารถใช้เวลา 1 วันในการเสร็จสิ้น แต่เขาไม่เคยคำนึงถึงว่าคุณต้องพิจารณา 1. จะเกิดอะไรขึ้นถ้ารหัสผู้ใช้ในรหัสผ่านไม่ถูกต้อง 2. จะเกิดอะไรขึ้นถ้ารหัสผู้ใช้ในรหัสผ่านผิด 3 ครั้ง 3. ถ้าผู้ใช้ไม่พิมพ์ชื่อผู้ใช้และอื่น ๆ คุณต้องแสดงรายชื่อเหล่านั้นและแสดงต่อ PM ของคุณขอให้เขากำหนดเวลาใหม่

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

OOP ควรถูกมองว่าเป็นหนึ่งในกระบวนทัศน์ไม่ใช่กระบวนทัศน์ที่เหนือกว่า OOP นั้นดีสำหรับการแก้ปัญหาบางประเภทเช่นการพัฒนา GUI Library นอกจากนี้ยังสอดคล้องกับรูปแบบของการพัฒนาซอฟต์แวร์ตามปกติโดย บริษัท ซอฟต์แวร์ขนาดใหญ่ - ทีมนักออกแบบหรือสถาปนิกชั้นแนวหน้าวางการออกแบบซอฟต์แวร์ลงในไดอะแกรม UML หรือสื่ออื่นที่คล้ายคลึงกันและทีมนักพัฒนาที่รู้แจ้งน้อยกว่าแปลการออกแบบนั้นเป็นซอร์สโค้ด OOP ให้ประโยชน์เล็กน้อยหากคุณทำงานคนเดียวหรือกับทีมโปรแกรมเมอร์ที่มีความสามารถสูง จากนั้นจะเป็นการดีกว่าถ้าใช้ภาษาที่รองรับกระบวนทัศน์หลากหลายและจะช่วยให้คุณสามารถสร้างต้นแบบได้อย่างรวดเร็ว Python, Ruby, Lisp / Scheme และอื่น ๆ เป็นตัวเลือกที่ดี ต้นแบบคือการออกแบบของคุณ จากนั้นคุณก็ปรับปรุงมัน ใช้กระบวนทัศน์ที่ดีที่สุดในการแก้ปัญหาในมือ หากจำเป็นให้เพิ่มประสิทธิภาพฮอตสปอตด้วยส่วนขยายที่เขียนด้วยภาษา C หรือภาษาระบบอื่น ๆ ด้วยการใช้ภาษาใดภาษาหนึ่งเหล่านี้คุณจะได้รับความสามารถเพิ่มมากขึ้นฟรีไม่เพียง แต่ในระดับโปรแกรมเมอร์ แต่ยังอยู่ในระดับผู้ใช้ด้วย ภาษาอย่าง Lisp สามารถสร้างและเรียกใช้รหัสแบบไดนามิกได้ซึ่งหมายความว่าผู้ใช้ของคุณสามารถขยายแอปพลิเคชันโดยการเขียนโค้ดขนาดเล็กในภาษาที่ตัวซอฟต์แวร์เขียนรหัสเอง! หรือถ้าคุณเลือกที่จะเขียนโปรแกรมใน C หรือ C ++ ให้ลองทำการฝังล่ามภาษาเล็ก ๆ อย่าง Lua เปิดเผยฟังก์ชันการทำงานเป็นปลั๊กอินที่เขียนด้วยภาษานั้น

ฉันคิดว่า OOP และ OOD ส่วนใหญ่สร้างซอฟต์แวร์ที่ตกเป็นเหยื่อของการออกแบบมากกว่า

เพื่อสรุปวิธีการเขียนซอฟต์แวร์ที่ฉันชอบคือ:

1. ใช้ภาษาแบบไดนามิก
2. เขียนการออกแบบ (ต้นแบบ) ในภาษานั้น
3. หากจำเป็นให้เพิ่มประสิทธิภาพบางพื้นที่โดยใช้ C / C ++
4. จัดเตรียมความสามารถในการขยายโดยวิธีการล่ามของภาษาการใช้งานเอง

คุณสมบัติสุดท้ายช่วยให้ซอฟต์แวร์สามารถปรับให้เข้ากับความต้องการของผู้ใช้ (รวมถึงตัวเอง!) ได้อย่างง่ายดาย

ฉันใช้การออกแบบทดสอบขับเคลื่อน (TDD) การเขียนแบบทดสอบก่อนจะช่วยให้คุณออกแบบที่สะอาดและถูกต้อง ดูhttp://en.wikipedia.org/wiki/Test-driven_development

เรียนรู้รูปแบบการออกแบบ มันเป็นการปฏิวัติส่วนตัวของฉันตลอดสองปีที่ผ่านมาเกี่ยวกับ OOP รับหนังสือ ฉันอยากจะแนะนำคุณคนนี้:

รูปแบบการออกแบบหัวแรก

มันอยู่ใน Java แต่มันสามารถขยายไปยังภาษาใด ๆ

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

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

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

จริง สังเกตว่าร้านขายยาด้านข้างใช้งานอย่างไรหรือห้องของแพทย์

นำปัญหาโดเมนของคุณมาสู่สิ่งที่คุณเข้าใจได้ สิ่งที่คุณสามารถเกี่ยวข้อง

จากนั้นเมื่อ "ผู้เล่น" ภายในโดเมนเริ่มปรากฏชัดเจนและคุณเริ่มสร้างแบบจำลองรหัสของคุณเลือกใช้วิธีการสร้างแบบจำลอง "ผู้ให้บริการผู้บริโภค" เช่นรหัสของคุณคือ "ผู้ให้บริการ" ของรุ่นและคุณเป็นผู้บริโภค "

เกี่ยวข้องกับโดเมนและเข้าใจในระดับสูงเป็นส่วนสำคัญของการออกแบบใด ๆ

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