คุณเข้าใกล้การออกแบบคลาสใน OOP ได้อย่างไร


12

เมื่อฉันพยายามออกแบบโซลูชัน OO ฉันมักใช้การสร้างแบบจำลองCRCโดยที่ฉันแสดงรายการชื่อคลาส (คำนาม) สิ่งที่พวกเขาทำ (คำกริยา) และวิธีที่พวกเขาทำงานร่วมกับคลาสอื่น ๆ

บล็อกนี้มีสิ่งด้านล่างที่จะพูดเกี่ยวกับวิธีการที่เป็นคำนามคำกริยานี้

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

คำถามของฉันคือมีเทคนิคการสร้างแบบจำลองที่ดีกว่าที่จะใช้วิธีการ OO หรือไม่?


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

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

คำตอบ:


12

ในความเป็นธรรมเขาเพิ่ม "สนุก" ในการอ้างสิทธิ์นั้น

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

หากคุณต้องการลองความท้าทายเล็กน้อยที่นี่หยุดอ่านแล้วลองทำแบบจำลองเกมผูกขาดโดยใช้ภาษาอังกฤษจากนั้นกลับมาที่นี่

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

แต่ทันทีที่คุณเริ่มเขียนการทดสอบคุณจะพบว่าวัตถุใดที่สำคัญที่สุดในเกม: กฎ

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

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

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

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

บางทีฉันอาจมี MonopolyPiece คลาสพื้นฐานและแต่ละประเภทจะได้มาจากสิ่งเหล่านั้น ฉันจะเริ่มต้นด้วย DogPiece การทดสอบครั้งแรก ... อ่า จริงๆแล้วมันไม่มีตรรกะเลย ใช่แต่ละชิ้นจะถูกวาดแตกต่างกันดังนั้นฉันอาจต้องการ DogDrawer แต่ในขณะที่ฉันเล่นเกมนี้ฉันต้องการเขียน "D" บนหน้าจอ ฉันจะเติม UI ให้มากขึ้นในตอนท้าย

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

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

คุณเห็นว่ามาเมื่อคุณเขียนคำนามและคำกริยา?

ในความเป็นจริงแล้วเป็นตัวอย่างที่ดีในรูปแบบและหลักการปฏิบัติ Agile Principles ของ Robert Martinที่พวกเขาพยายามที่จะรวบรวมแอพ Bowling Score Card โดยใช้ TDD และค้นหาสิ่งต่าง ๆ ที่พวกเขาคิดว่าเป็นคลาสที่เห็นได้ชัด


ไม่เข้าใจว่าทำไม TDD เป็นคำตอบสำหรับการวิเคราะห์ OO ที่ OP ถาม คำนาม / คำกริยาคือการประมาณแรกของโดเมนปัญหา (มีประโยชน์มากที่สุดสำหรับผู้เริ่มต้น) และแน่นอนว่าการเรียนการกลั่นสามารถทำได้ในภายหลัง แต่การเรียกร้อง TDD นำการออกแบบในทิศทางที่ถูกต้องคือ IMHO ผิดธรรมดา (คุณแนะนำให้ข้ามการวางแผน ออกแบบและเริ่มเขียนโค้ด?!) ตัวอย่างการผูกขาดยังทำให้เข้าใจผิดเช่นกันขึ้นอยู่กับส่วนของระบบที่คุณกำลังใช้งาน: UI หรือตรรกะหลัก ในสี่เหลี่ยมลูกเต๋าด้าน UI และอะไรที่ไม่สมเหตุสมผล
Roman Susi

+1 & รายการโปรด ก่อนอื่นประสบการณ์ของฉันคือ TDD ผลักดันกระบวนการคิดของคุณไปยังสถานที่ที่เหมาะสม อย่างรวดเร็ว (บางครั้งคุณอาจโต้เถียงเกี่ยวกับ และมันสามารถช่วยเปิดเผยข้อบกพร่องในการออกแบบได้เช่นกัน: คุณจะได้เรียนรู้การฉีดแบบพึ่งพาหากไม่มีสิ่งใด! คำนามคำกริยา - ใครที่ไม่ได้เริ่มที่นี่? แต่ วัตถุเหล่านี้ส่วนใหญ่จะเป็นใบ้ทั้งหมด ข้อมูลถ้าคุณจะลึกซึ้ง ชื่อหนังสือน้ำเชื้อบอกว่าทั้งหมดสำหรับฉันอัลกอริทึม + โครงสร้างข้อมูล = โปรแกรม
Radarbob

3

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

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

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

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

แก้ไข: แค่อ่านบล็อกที่สองครึ่งและฉันต้องบอกว่าฉันเห็นด้วยกับมันค่อนข้างมาก ฉันจะต้องอ่านส่วนที่เหลือและดูสิ่งที่มันเสนอในแง่ของการเรียนรู้


2
ข้อผิดพลาด: บรรทัดที่ 2: การเชื่อมโยงหลายมิติไม่ถูกต้อง!
Cracker

1
ซอฟต์แวร์ SE ถูกปิดมัน มันทำงานได้ดีในการแสดงตัวอย่าง นี่คือลิงค์ในรูปแบบข้อความ: objectmentor.com/resources/articles/CoffeeMaker.pdf
Edward Strange

0

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

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

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

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