สมมติว่าคุณไม่ได้มองหากรอบการเยาะเย้ยเพราะพวกมันมีความแพร่หลายและหาง่ายมีบางสิ่งที่ควรค่าแก่การสังเกต:
- มีสิ่งที่ "ไม่เคย" ที่คุณควร "เสมอ" ทำ
การห่อห้องสมุดบุคคลที่สามนั้นไม่ใช่วิธีที่ดีที่สุดเสมอไป หากแอปพลิเคชันของคุณขึ้นอยู่กับไลบรารีหรือถ้ามันถูกสร้างขึ้นรอบ ๆ ไลบรารีหลักหนึ่งหรือสองไลบรารีอย่าเสียเวลาไปกับมัน หากห้องสมุดมีการเปลี่ยนแปลงใบสมัครของคุณจะต้องมีการเปลี่ยนแปลงต่อไป
- มันก็โอเคที่จะใช้การทดสอบการรวม
นี่เป็นความจริงโดยเฉพาะอย่างยิ่งเกี่ยวกับขอบเขตที่มีความเสถียรเป็นธรรมชาติในแอปพลิเคชันของคุณหรือไม่สามารถเยาะเย้ยได้อย่างง่ายดาย หากพบเงื่อนไขเหล่านั้นการห่อและการเยาะเย้ยจะซับซ้อนและน่าเบื่อ ในกรณีนั้นฉันจะหลีกเลี่ยงทั้งสอง: อย่าห่อและไม่ล้อเลียน; เพียงแค่เขียนการทดสอบการรวม (หากการทดสอบอัตโนมัติเป็นเป้าหมาย)
- เครื่องมือและกรอบงานไม่สามารถกำจัดความซับซ้อนเชิงตรรกะได้
โดยหลักการแล้วเครื่องมือสามารถตัดลงบนแผ่นความร้อน แต่ไม่มีอัลกอริธึมที่สามารถทำได้โดยอัตโนมัติสำหรับการใช้อินเทอร์เฟซที่ซับซ้อนและทำให้เป็นเรื่องง่าย - ให้ใช้อินเทอร์เฟซ X อย่างเดียวและปรับให้เหมาะกับความต้องการของคุณ (เพียงคุณเท่านั้นที่รู้ว่าอัลกอริทึม!) ดังนั้นในขณะที่มีอย่างไม่ต้องสงสัยเครื่องมือที่สามารถสร้างห่อบางผมขอแนะนำว่าพวกเขาไม่ได้อยู่แพร่หลายเพราะในท้ายที่สุดแล้วคุณยังคงต้องรหัสเพียงอย่างชาญฉลาดและดังนั้นจึงตนเอง กับอินเทอร์เฟซแม้ว่าจะซ่อนอยู่ด้านหลัง wrapper
ที่กล่าวว่ามีกลยุทธ์ที่คุณสามารถใช้ในหลายภาษาเพื่อหลีกเลี่ยงการอ้างอิงโดยตรงกับชั้นเรียน และในบางกรณีคุณสามารถ "ปลอมแปลง" อินเทอร์เฟซหรือเสื้อคลุมบาง ๆ ที่ไม่มีอยู่จริง ตัวอย่างเช่นใน C # ฉันจะไปหนึ่งในสองเส้นทาง:
- ใช้โรงงานและการพิมพ์โดยปริยาย
คุณสามารถหลีกเลี่ยงความพยายามในการห่อคลาสที่ซับซ้อนด้วยคอมโบเล็ก ๆ น้อย ๆ นี้:
// "factory"
class PdfDocumentFactory {
public static ExternalPDFLibraryDocument Build() {
return new ExternalPDFLibraryDocument();
}
}
// code that uses the factory.
class CoreBusinessEntity {
public void DoImportantThings() {
var doc = PdfDocumentFactory.Build();
// ... i have no idea what your lib does, so, I'm making stuff but.
// but, you can do whatever you want here without explicitly
// referring to the library's actual types.
doc.addHeader("Wee");
doc.getAllText().makeBiggerBy(4).makeBold().makeItalic();
return doc.exportBinaryStreamOrSomething();
}
}
หากคุณสามารถหลีกเลี่ยงการเก็บวัตถุเหล่านี้ในฐานะสมาชิกทั้งผ่านวิธีการอื่น ๆ อีกมากมาย "การทำงาน" หรือโดยเก็บไว้ในพจนานุกรม (หรืออะไรก็ตาม ) วิธีนี้มีประโยชน์ในการตรวจสอบประเภทเวลารวบรวมโดยไม่มีหน่วยงานธุรกิจหลักของคุณต้องรู้ว่าชั้นเรียนที่พวกเขาทำงานด้วย
สิ่งที่จำเป็นต้องมีก็คือในเวลารวบรวมคลาสที่โรงงานของคุณส่งคืนมีวิธีการที่วัตถุทางธุรกิจของคุณใช้
- ใช้พิมพ์แบบไดนามิก
สิ่งนี้อยู่ในหลอดเลือดดำเดียวกับการใช้การพิมพ์โดยนัยแต่เกี่ยวข้องกับการแลกเปลี่ยนอื่น: คุณสูญเสียการตรวจสอบประเภทคอมไพล์และได้รับความสามารถในการเพิ่มการอ้างอิงภายนอกโดยไม่ระบุชื่อในฐานะสมาชิกชั้นเรียนและฉีดการพึ่งพาของคุณ
class CoreBusinessEntity {
dynamic Doc;
public void InjectDoc(dynamic Doc) {
Doc = doc;
}
public void DoImortantThings() {
Doc.addHeader("Wee");
Doc.getAllText().makeBiggerBy(4).makeBold().makeItalic();
return Doc.exportBinaryStreamOrSomething();
}
}
มีทั้งกลยุทธ์เหล่านี้เมื่อมันถึงเวลาที่จะเยาะเย้ยExternalPDFLibraryDocumentที่ผมระบุไว้ก่อนหน้านี้คุณมีงานที่ต้องทำบางอย่าง - แต่การทำงานของมันคุณจะต้องทำอยู่แล้ว และด้วยโครงสร้างนี้คุณหลีกเลี่ยงการกำหนดคลาสเสื้อคลุมเล็ก ๆ น้อย ๆ จำนวน 100 อันอย่างน่าเบื่อ คุณเพิ่งใช้ห้องสมุดโดยไม่ได้ดูโดยตรง - ส่วนใหญ่
จากทั้งหมดที่กล่าวมามีสามเหตุผลใหญ่ที่ฉันจะยังคงพิจารณาการรวมไลบรารีของบุคคลที่สามอย่างชัดเจน - ไม่มีสิ่งใดที่จะบอกใบ้ให้ใช้เครื่องมือหรือกรอบงาน:
- ไลบรารีเฉพาะไม่ได้อยู่ภายในแอปพลิเคชัน
- มันจะมีราคาแพงมากในการสลับโดยไม่ต้องปิด
- ฉันไม่ชอบ API เอง
หากฉันไม่มีข้อกังวลในบางประเด็นในทั้งสามด้านคุณไม่ได้ใช้ความพยายามอย่างมากในการสรุป และถ้าคุณมีความกังวลในทั้งสามด้านนี้เสื้อคลุมบางที่สร้างขึ้นโดยอัตโนมัติจะไม่ช่วยได้จริง ๆ
ถ้าคุณได้ตัดสินใจที่จะห่อห้องสมุด, การใช้งานที่มีประสิทธิภาพมากที่สุดและมีประสิทธิภาพของเวลาของคุณคือการสร้างโปรแกรมประยุกต์ของคุณกับอินเตอร์เฟซที่คุณต้องการ ; ไม่ใช่กับ API ที่มีอยู่
อีกทางหนึ่งให้ฟังคำแนะนำดั้งเดิม: เลื่อนการตัดสินใจทุกครั้งที่คุณทำได้ สร้าง "หลัก" ของแอปพลิเคชันของคุณก่อน รหัสกับอินเตอร์เฟซที่จะในที่สุดก็ทำในสิ่งที่คุณต้องการซึ่งจะในที่สุดก็จะสำเร็จโดย "สิ่งรอบข้าง" ที่ไม่ได้อยู่เลย เชื่อมช่องว่างตามต้องการ
ความพยายามนี้อาจไม่รู้สึกประหยัดเวลา แต่ถ้าคุณรู้สึกว่าคุณต้องการเสื้อคลุมนี่เป็นวิธีที่มีประสิทธิภาพที่สุดในการทำอย่างปลอดภัย
คิดแบบนี้
คุณต้องใช้รหัสกับไลบรารีนี้ในมุมมืดของรหัสของคุณ - แม้ว่าจะถูกปิด หากคุณแกล้งไลบรารีระหว่างการทดสอบมีความพยายามแบบแมนนวลที่หลีกเลี่ยงไม่ได้แม้ว่าจะปิดตัวลงก็ตาม แต่นั่นไม่ได้หมายความว่าคุณต้องยอมรับโดยตรงว่าไลบรารีตามชื่อตลอดทั้งแอปพลิเคชันจำนวนมากของคุณ
TLDR
หากห้องสมุดมีคุณค่าในการห่อใช้กลยุทธ์เพื่อหลีกเลี่ยงการอ้างอิงที่กว้างขวางไปยังห้องสมุดบุคคลที่สามของคุณโดยตรง แต่อย่าใช้ทางลัดในการสร้าง wrappers แบบบาง สร้างตรรกะทางธุรกิจของคุณก่อนพิจารณาอย่างรอบคอบเกี่ยวกับอินเทอร์เฟซของคุณและสร้างอแด็ปเตอร์ของคุณตามความจำเป็น
และถ้าเป็นอย่างนั้นอย่ากลัวการทดสอบบูรณาการ พวกมันช่างคลุมเครือเล็กน้อย แต่พวกเขายังคงมีหลักฐานของรหัสการทำงานและพวกเขาก็ยังสามารถสร้างขึ้นเพื่อรักษาความถดถอยได้อย่างง่ายดาย