วิธีการกระจายความรู้สำหรับการเขียนโปรแกรมทั่วไปในหมู่สมาชิกในทีม?

ฉันอยู่ในสภาพแวดล้อมที่ผู้คนเชื่อว่า:

1. Java generics เป็นคุณสมบัติที่ใช้สำหรับการเขียนไลบรารีโดยเฉพาะและไม่ใช่การเข้ารหัสที่แท้จริง
2. C ++ เป็นภาษาการเขียนโปรแกรม OO; templateเป็นคุณสมบัติเสริมและหลีกเลี่ยงได้

แม้ว่าคนเหล่านี้จะพึ่งพาไลบรารีที่เขียนโดยใช้โปรแกรมทั่วไป (เช่น STL, คอนเทนเนอร์ Java) ถ้าผมเขียนโค้ดที่ใช้templateหรือgenericsรหัสวิจารณ์มีแนวโน้มที่จะปฏิเสธมันและจะแสดงความคิดเห็นที่จะเขียนมันใน"เหมาะสม / เข้าใจ / สง่างาม"วิธี

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

เป็นวิธีที่ดีที่สุด ( ไม่ถูกตัดคอ ) ของการอธิบายพวกเขาวิธีการปฏิบัติของการเขียนโค้ดซึ่งประกอบด้วย OO และการเขียนโปรแกรมทั่วไปทั้งสองในเวลาเดียวกันคืออะไร?

ยังมีคนในโลกที่ไม่ใช้ generics jave ใน "รหัสธรรมดา" ฉันเชื่อด้วยเทมเพลต C ++ แต่เป็นชื่อสามัญ? พวกเขาไม่ได้เรียนรู้ / ใช้งานได้ยาก คุณลักษณะที่ดีที่สุดของ Java และ C ++ อย่างจริงจังคือลำดับทั่วไปและแม่แบบ

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

ตราบใดที่คุณไม่ได้ทำอะไรบางอย่างเหมือนกับการใช้เทมเพลตเป็นภาษาการเขียนโปรแกรมของคุณพาราเมตริกแบบ polymorphism (generics / template) ก็ค่อนข้างดี

1. หลีกเลี่ยงการทำสำเนารหัส

นี่คือชัดเจน แต่รหัส polymorphic เป็นรหัสทั่วไป นั่นคือเหตุผลที่เรียกว่ายาชื่อสามัญ

2. รองรับการตรวจสอบแบบคงที่ดีขึ้น

คุณจะต้องเขียนสิ่งต่าง ๆ เช่นpublic Object clone()หรือpublic boolean equals(object b)ซึ่งไม่ได้เป็นแค่สิ่งที่น่ารังเกียจพวกเขามีประเภทที่ไม่ให้ข้อมูลเกี่ยวกับสิ่งที่พวกเขาทำ ทางเลือกสำหรับพาราเมทริกโพลิมอร์ฟิซึมนั้นมีอยู่ทั่วทุกที่

3. รหัส OOP แบบหลายพารามิเตอร์ที่ไม่ใช่พารามิเตอร์นั้นไม่สามารถจัดการกับ "วิธีการแบบไบนารี" ได้ในวิธีที่ถูกต้อง

คุณใช้สิ่งเหล่านี้บ่อยครั้ง

4. เป็นการปฏิบัติที่ดีที่สุด

ใน Java การใช้ generics ถือเป็นแนวปฏิบัติที่ดีที่สุด (ดู Java ที่มีประสิทธิภาพโดย Josh Bloch) นักคิดหลัก C ++ เช่น Sutter และ Alexandrescu ยังสนับสนุนให้ใช้เทมเพลตเพื่อแก้ไขปัญหาที่หลากหลาย

5. มันเหมาะกับกระบวนทัศน์ OO

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

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

ยาสามัญเพื่อช่วยชีวิต!

   public class Business<S extends Datastore>{
      private S store; ...
   }

ตอนนี้คุณสามารถเริ่มสร้างความแตกต่างแบบคงที่Businessวัตถุของคุณตามความสามารถในการใช้คุณสมบัติเฉพาะของฐานข้อมูล คุณยังต้องมีการตรวจสอบและการตรวจสอบรันไทม์ แต่คุณสามารถเริ่มสร้างโค้ดที่ดีขึ้นได้

และ

6. ไม่มีรหัสปกติ

มีเพียงสามสิ่งในเอกภพการเขียนโปรแกรม:

1. ห้องสมุด
2. การกำหนดค่าและ
3. รหัสไม่ดี

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

ฉันพบว่าทัศนคตินี้น่าทึ่ง หลังจากที่คุณคุ้นเคยกับการเขียนโปรแกรมประเภท parametrized แล้วการไม่ใช้มันก็ทำให้ทุกอย่างเจ็บปวด และ Java และ C ++ มีจุดหยาบ ๆ ซึ่งช่วยแก้ไขได้

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

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

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

• ยาชื่อสามัญ (หรืออะไรก็ตาม) จะปรับปรุงมูลค่าของผลิตภัณฑ์หรือไม่ อาจจะไม่.

• ยาชื่อสามัญ (หรืออะไรก็ตาม) จะทำให้มันยากขึ้นสำหรับคนที่พวกเขาได้ว่าจ้างให้ทำงานของพวกเขา? ใช่.

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

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

ฉันจะถ่ายทอดข้อดีของ generics ไปยังผู้ตรวจสอบโค้ดและเพื่อนร่วมงานคนอื่น ๆ ก่อนการตรวจสอบใด ๆ :

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

2) Generics ให้ความปลอดภัยประเภทโดยไม่มีค่าใช้จ่ายในการใช้งานหลายอย่าง

ดังนั้น [1] และ [2] ลดความเสี่ยงของข้อผิดพลาดในรหัส นี้ช่วยประหยัดเวลานักพัฒนาและทำให้เงินของ บริษัท

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

ฉันจะเพิ่มงบสองสามคำเกี่ยวกับวิธีที่โปรแกรมเมอร์คนอื่นไม่มีปัญหากับ generics: Generics ใช้กันอย่างแพร่หลายใน Java และภาษาอื่น ๆ เช่น C # โปรแกรมเมอร์ที่จริงจังคนใดจะพบกับชีวิตที่ยากลำบากโดยปราศจากการสร้างบล็อคที่ปลอดภัยประเภทนั้น

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

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

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

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

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

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

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

และเพื่อให้โปรแกรมเมอร์ใช้รูปแบบนี้คุณสามารถเพิ่มประเภททั่วไปContextที่ควรใช้สิ่งที่มีStrategyประเภท รหัสฉลาดมันจะมีลักษณะเช่นนี้ใน Java:

// declare the generic Context class that has a type "S" 
// that is an upper bound class of Strategy
public class Context <S extends Strategy> {
    S strategy;

    // Constructor with an initial strategy
    public Context(S initialStrategy) {
        this.strategy = initialStrategy;
    }

    public void doSomething() {
      strategy.execute(); // assumes that Strategy has an execute() method.
    }

    public void setStrategy(S strategy) {
        this.strategy = strategy;
    }
}

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

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

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

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

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

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

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

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

หมายเหตุ "เข้าใจได้" หากผู้ตรวจสอบโค้ดไม่เห็นประโยชน์ของยาชื่อสามัญดังนั้น<<<>>>-stuff ทั้งหมดเป็นเพียงเสียงที่ไม่สามารถเข้าใจได้ซึ่งไม่จำเป็น

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

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

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

ความคิดสุ่มอีกสองสามข้อจากการเดินทางทั่วไปของฉัน:

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

Generics ทำความสะอาดรหัสของฉันและเตือนฉันว่ามีปัญหาหลายครั้งเกินไปที่ฉันจะปฏิเสธมัน แต่ฉันก็เห็นเวลาการพัฒนาที่เพิ่มขึ้นเวลาพิเศษในการฝึกอบรมและโปรแกรมเมอร์ Java บังคับให้ทำงานใน C #, C และ Visual Basic .. หรือ Java 1.4 ฉันจะเน้นการเขียนโค้ดที่เพื่อนร่วมงานของคุณสามารถเข้าใจได้ หากคุณสามารถจัดส่งยาชื่อสามัญที่เข้าใจได้ดี ฉันเห็นว่า Java generics เป็นโอกาส / ปัญหาที่ยังไม่ได้เกิดขึ้น