"นามธรรมก่อนวัยอันควร" คืออะไร?

ฉันได้ยินวลีที่ถูกโยนและฉันมีข้อโต้แย้งที่ฟังดูบ้าอย่างสมบูรณ์ (ขออภัยถ้าฉันกำลังทำฟางอยู่ที่นี่ไม่ใช่ความตั้งใจของฉัน) โดยทั่วไปจะมีบางอย่างตาม:

คุณไม่ต้องการสร้างสิ่งที่เป็นนามธรรมก่อนที่คุณจะรู้ว่ากรณีทั่วไปคืออะไรมิฉะนั้น (1) คุณอาจวางสิ่งต่าง ๆ ในสิ่งที่เป็นนามธรรมของคุณหรือ (2) ไม่สนใจสิ่งที่มีความสำคัญ

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

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

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

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

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

public abstract class BaggingRobot() {
    private Collection<Item> items;

    public abstract void bag(Item item);
}

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

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

อย่างน้อยที่สุดในความคิดของฉันสิ่งที่เป็นนามธรรมก่อนวัยอันควรเป็นเรื่องธรรมดาและโดยเฉพาะอย่างยิ่งในช่วงต้นของประวัติศาสตร์ของ OOP

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

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

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

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

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

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

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

เมื่อฉันเรียนรู้เกี่ยวกับการวิเคราะห์และออกแบบเชิงวัตถุเมื่อหลายปีก่อนเราจะเริ่มด้วยคำอธิบายภาษาอังกฤษธรรมดาของระบบที่ลูกค้าต้องการ

เมื่อมองดูสิ่งนั้นคำนาม (หรือวลีที่เป็นคำนาม) จะถูกพิจารณาว่าเป็นคลาสที่เป็นไปได้ คำกริยาใด ๆ (หรือวลีกริยา) จะเป็นวิธีการที่มีศักยภาพในชั้นเรียน ดังนั้น "ห่อหุ่นยนต์" BaggingRobotอาจจะเป็นชั้นเรียน "เปิดถุง" OpenBagอาจจะกลายเป็นวิธีการ

หลังจากการทำซ้ำสองสามครั้งสิ่งนี้จะเปลี่ยนเป็นแผนภาพคลาส

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

คลาสนามธรรมจะถูกนำมาใช้เฉพาะเมื่อมันกลายเป็นที่ชัดเจนว่า:

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

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

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

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

การคลอดก่อนกำหนดจริงๆแล้วก็หมายความว่าคุณไม่มีเหตุผลที่ดีในการทำสิ่งที่เป็นนามธรรมและเนื่องจาก abstractions อยู่ไกลจากฟรีในหลายภาษาคุณอาจเกิดค่าใช้จ่ายโดยไม่มีเหตุผล

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

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

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

public class Item {
/* Relevant item attributes as specified by customer */
}

public class BaggingRobot {
  private Collection<Item> items;

  public void bag(Item item);
}

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

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

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

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