สิ่งหนึ่งที่ช่วยในการพัฒนาได้มากคือการนำโค้ดกลับมาใช้ใหม่ (code reuse) ถ้าเราสามารถซื้อ library ที่แก้ปัญหาให้เราได้ (และหาวิธีใช้งานมัน) เราก็มักจะลดเวลาในโปรเจกต์ลงไปได้มาก ปัญหาเดียวคือมันง่ายมากที่จะพึ่งพา library มากเกินไป ถ้าคุณใช้มันอย่างไม่เลือกหน้าทั่วทั้งโค้ดของคุณ คุณก็แทบจะต้องอยู่กับมันไปตลอด ทีมที่ผมเคยทำงานด้วยบางทีมเจ็บหนักมากจากการพึ่งพา library มากเกินไป กรณีหนึ่ง vendor ขึ้นค่า royalties สูงมากจนแอปพลิเคชันไม่สามารถทำกำไรในตลาดได้ ทีมงานไม่สามารถเปลี่ยนไปใช้ library ของ vendor อื่นได้ง่ายๆ เพราะการแยก calls โค้ดของ vendor เดิมออกมาทั้งหมดก็คือการเขียนใหม่ทั้งโปรเจกต์นั่นเอง
หลีกเลี่ยงการกระจาย calls โดยตรงไปยังคลาสของ library ทั่วทั้งโค้ดของคุณ คุณอาจคิดว่าคุณจะไม่เปลี่ยนแปลงมัน แต่การคิดแบบนั้นกลับทำให้มันกลายเป็นจริงขึ้นมาได้
ในตอนที่เขียนหนังสือเล่มนี้ โลกของการพัฒนาส่วนใหญ่ถูกแบ่งขั้วอยู่รอบ Java และ .NET ทั้ง Microsoft และ Sun ต่างพยายามทำให้แพลตฟอร์มของตนกว้างขวางที่สุดเท่าที่จะทำได้ โดยสร้าง library มากมายเพื่อให้คนยังคงใช้ผลิตภัณฑ์ของตนต่อไป ในแง่หนึ่งมันก็เป็นผลดีต่อหลายโปรเจกต์ แต่คุณก็ยังสามารถพึ่งพา library ใด library หนึ่งมากเกินไปได้ การใช้คลาสของ library แบบ hard-coded ทุกครั้งคือจุดที่คุณควรจะมี seam ได้ library บางตัวทำได้ดีมากในการกำหนด interface สำหรับคลาสที่เป็นรูปธรรม (concrete classes) ทั้งหมดของมัน ในกรณีอื่นๆ คลาสต่างๆ เป็นแบบ concrete และถูกประกาศเป็น final หรือ sealed หรือมีฟังก์ชันหลักๆ ที่เป็น non-virtual ซึ่งทำให้ไม่มีทางที่จะจำลอง (fake) พวกมันในระหว่างทดสอบได้ ในกรณีเหล่านี้ บางครั้งสิ่งที่ดีที่สุดที่คุณทำได้คือเขียน wrapper บางๆ ครอบคลาสที่คุณต้องการแยกออกมา อย่าลืมเขียนถึง vendor ของคุณและบ่นให้พวกเขารู้ว่าทำให้งานพัฒนาของคุณยากลำบาก
นักออกแบบ library ที่ใช้ความสามารถของภาษาเพื่อบังคับใช้ข้อจำกัดด้านดีไซน์มักจะทำผิดพลาด พวกเขาลืมไปว่าโค้ดที่ดีต้องทำงานได้ทั้งในสภาพแวดล้อม production และ test ข้อจำกัดสำหรับสภาพแวดล้อมแรกอาจทำให้การทำงานในสภาพแวดล้อมหลังแทบจะเป็นไปไม่ได้
มีความขัดแย้งพื้นฐานระหว่างความสามารถของภาษาที่พยายามบังคับใช้การออกแบบที่ดี กับสิ่งที่คุณต้องทำเพื่อทดสอบโค้ด หนึ่งในความขัดแย้งที่พบบ่อยที่สุดคือ once dilemma ถ้า library สันนิษฐานว่าจะมี instance ของคลาสเพียงตัวเดียวในระบบ มันจะทำให้การใช้ fake objects เป็นเรื่องยาก อาจไม่มีทางที่จะใช้ Introduce Static Setter (372) หรือเทคนิคการทำลาย dependencies อื่นๆ ที่คุณสามารถใช้เพื่อจัดการกับ singletons ได้ บางครั้งการห่อ (wrap) singleton ก็เป็นทางเลือกเดียวที่คุณมี
ปัญหาที่เกี่ยวข้องกันคือ restricted override dilemma ในภาษา OO บางภาษา เมธอดทั้งหมดเป็น virtual ในภาษาอื่น เมธอดเป็น virtual โดยค่าเริ่มต้น แต่ก็สามารถทำให้เป็น non-virtual ได้ ในภาษาอื่นๆ คุณต้องประกาศให้เป็น virtual อย่างชัดเจน จากมุมมองของการออกแบบ การทำให้บางเมธอดเป็น non-virtual ก็มีคุณค่าอยู่บ้าง ในบางครั้ง ผู้คนมากมายในวงการได้แนะนำให้ทำให้เมธอดเป็น non-virtual ให้มากที่สุดเท่าที่จะทำได้ บางครั้งเหตุผลที่พวกเขาให้ก็ใช้ได้ แต่มันปฏิเสธได้ยากว่าการปฏิบัตินี้ทำให้การนำ sensing และ separation เข้ามาใช้ใน code base เป็นเรื่องยาก นอกจากนี้ยังปฏิเสธได้ยากว่าผู้คนมักเขียนโค้ดที่ดีได้ใน Smalltalk ซึ่งการปฏิบัตินั้นเป็นไปไม่ได้ ใน Java ที่ผู้คนทั่วไปไม่ทำแบบนั้น และแม้แต่ใน C++ ซึ่งก็มีโค้ดจำนวนมากที่เขียนโดยไม่ใช้แนวทางนี้ คุณสามารถทำงานได้ดีเพียงแค่สมมติว่า public method เป็น non-virtual ใน production code ถ้าคุณทำแบบนั้น คุณก็สามารถ override มันเฉพาะใน test และได้ประโยชน์ทั้งสองโลก
บางครั้งการใช้ coding convention ก็ดีพอๆ กับการใช้ความสามารถของภาษาที่มีข้อจำกัด ลองคิดถึงสิ่งที่ tests ของคุณต้องการ