พื้นฐานการไตร่ตรองหมายถึงการใช้รหัสของโปรแกรมของคุณเป็นข้อมูล
ดังนั้นการใช้ภาพสะท้อนอาจเป็นความคิดที่ดีเมื่อรหัสโปรแกรมของคุณเป็นแหล่งข้อมูลที่มีประโยชน์ (แต่มีการแลกเปลี่ยนกันดังนั้นจึงอาจไม่ใช่ความคิดที่ดีเสมอไป)
ตัวอย่างเช่นพิจารณาคลาสที่เรียบง่าย:
public class Foo {
public int value;
public string anotherValue;
}
และคุณต้องการสร้าง XML จากมัน คุณสามารถเขียนโค้ดเพื่อสร้าง XML:
public XmlNode generateXml(Foo foo) {
XmlElement root = new XmlElement("Foo");
XmlElement valueElement = new XmlElement("value");
valueElement.add(new XmlText(Integer.toString(foo.value)));
root.add(valueElement);
XmlElement anotherValueElement = new XmlElement("anotherValue");
anotherValueElement.add(new XmlText(foo.anotherValue));
root.add(anotherValueElement);
return root;
}
แต่นี่เป็นรหัสสำเร็จรูปจำนวนมากและทุกครั้งที่คุณเปลี่ยนคลาสคุณต้องอัปเดตรหัส จริงๆคุณสามารถอธิบายสิ่งที่รหัสนี้เป็น
- สร้างองค์ประกอบ XML ด้วยชื่อของคลาส
- สำหรับแต่ละคุณสมบัติของคลาส
- สร้างองค์ประกอบ XML ด้วยชื่อของคุณสมบัติ
- ใส่ค่าของคุณสมบัติลงในองค์ประกอบ XML
- เพิ่มองค์ประกอบ XML ให้กับราก
นี่คืออัลกอริทึมและอินพุตของอัลกอริทึมคือคลาส: เราต้องการชื่อและชื่อประเภทและค่าของคุณสมบัติ นี่คือที่สะท้อนมา: มันช่วยให้คุณเข้าถึงข้อมูลนี้ Java ช่วยให้คุณตรวจสอบประเภทโดยใช้วิธีการของClassชั้นเรียน
บางกรณีใช้งานเพิ่มเติม:
- กำหนด URL ในเว็บเซิร์ฟเวอร์ตามชื่อเมธอดของคลาสและพารามิเตอร์ URL ตามอาร์กิวเมนต์เมธอด
- แปลงโครงสร้างของคลาสให้เป็นข้อกำหนดประเภท GraphQL
- เรียกวิธีการทุกคลาสที่มีชื่อขึ้นต้นด้วย "test" เป็นกรณีทดสอบหน่วย
อย่างไรก็ตามการสะท้อนกลับทั้งหมดหมายถึงไม่เพียง แต่ดูรหัสที่มีอยู่ (ซึ่งโดยตัวมันเองเรียกว่า "วิปัสสนา") แต่ยังแก้ไขหรือสร้างรหัส มีสองกรณีการใช้งานที่โดดเด่นใน Java สำหรับนี้: พร็อกซี่และ mocks
สมมติว่าคุณมีอินเทอร์เฟซ:
public interface Froobnicator {
void froobnicateFruits(List<Fruit> fruits);
void froobnicateFuel(Fuel fuel);
// lots of other things to froobnicate
}
และคุณมีการนำไปใช้งานที่ทำสิ่งที่น่าสนใจ:
public class PowerFroobnicator implements Froobnicator {
// awesome implementations
}
และในความเป็นจริงคุณมีการใช้งานที่สองเช่นกัน:
public class EnergySaverFroobnicator implements Froobnicator {
// efficient implementations
}
ตอนนี้คุณยังต้องการบันทึกผลลัพธ์บางส่วน; คุณเพียงต้องการข้อความบันทึกทุกครั้งที่มีการเรียกใช้เมธอด คุณสามารถเพิ่มบันทึกผลลัพธ์ไปยังทุกวิธีอย่างชัดเจน แต่นั่นน่ารำคาญและคุณต้องทำสองครั้ง หนึ่งครั้งต่อการติดตั้งแต่ละครั้ง (ดังนั้นยิ่งมากขึ้นเมื่อคุณเพิ่มการใช้งานเพิ่มเติม)
คุณสามารถเขียนพร็อกซีแทน:
public class LoggingFroobnicator implements Froobnicator {
private Logger logger;
private Froobnicator inner;
// constructor that sets those two
public void froobnicateFruits(List<Fruit> fruits) {
logger.logDebug("froobnicateFruits called");
inner.froobnicateFruits(fruits);
}
public void froobnicateFuel(Fuel fuel) {
logger.logDebug("froobnicateFuel( called");
inner.froobnicateFuel(fuel);
}
// lots of other things to froobnicate
}
แม้ว่าจะมีรูปแบบซ้ำ ๆ ที่สามารถอธิบายได้ด้วยอัลกอริทึม:
- พร็อกซีของคนตัดไม้เป็นคลาสที่ใช้อินเทอร์เฟซ
- มันมีนวกรรมิกที่ใช้การดำเนินการอื่นของอินเทอร์เฟซและคนตัดไม้
- สำหรับทุกวิธีในส่วนต่อประสาน
- การใช้งานบันทึกข้อความ "$ methodname ชื่อ"
- จากนั้นเรียกใช้เมธอดเดียวกันบนอินเทอร์เฟซภายในส่งผ่านอาร์กิวเมนต์ทั้งหมด
และอินพุตของอัลกอริทึมนี้คือนิยามอินเตอร์เฟส
Reflection อนุญาตให้คุณกำหนดคลาสใหม่โดยใช้อัลกอริทึมนี้ Java ช่วยให้คุณทำสิ่งนี้ได้โดยใช้วิธีการของjava.lang.reflect.Proxyชั้นเรียนและมีห้องสมุดที่ให้พลังงานมากกว่าเดิม
ดังนั้นข้อเสียของการสะท้อนคืออะไร?
- รหัสของคุณยากที่จะเข้าใจ คุณเป็นหนึ่งในระดับของการลบออกเพิ่มเติมจากผลกระทบที่เป็นรูปธรรมของรหัสของคุณ
- รหัสของคุณจะยากต่อการดีบัก โดยเฉพาะอย่างยิ่งกับไลบรารีที่สร้างรหัสรหัสที่ถูกเรียกใช้อาจไม่ใช่รหัสที่คุณเขียน แต่รหัสที่คุณสร้างขึ้นและตัวดีบักอาจไม่สามารถแสดงรหัสนั้นได้ (หรืออนุญาตให้คุณวางจุดพัก)
- รหัสของคุณช้าลง การอ่านข้อมูลประเภทและการเข้าถึงฟิลด์แบบไดนามิกโดยการจัดการรันไทม์ของพวกเขาแทนการเข้าถึงการเข้ารหัสยากช้ากว่า การสร้างโค้ดแบบไดนามิกสามารถลดผลกระทบนี้ได้โดยเสียค่าใช้จ่ายในการดีบัก
- รหัสของคุณอาจบอบบางมาก การเข้าถึงการสะท้อนแบบไดนามิกไม่ได้ตรวจสอบประเภทโดยคอมไพเลอร์ แต่มีข้อผิดพลาดเกิดขึ้นขณะทำงาน