เหตุใดจึงสร้างวัตถุ Logger แทนที่จะใช้วิธีการบันทึกแบบคงที่ทั่วทั้งแอปพลิเคชัน

ยกตัวอย่างของแอพพลิเคชั่น Ruby on Rails แบบง่าย ๆ มันสร้างLoggerวัตถุในระหว่างกระบวนการโหลดแอปพลิเคชัน:

# in environment.rb
config.logger = Logger.new(<STDOUT | file | whatever>)

# and in our application we use this object
logger.warn "This process is taking too long to process. Optimization needed."

คำถามของฉันคือทำไมเราไม่ใช้วิธีการเรียน (หรือวิธีการคงที่) สำหรับการเข้าสู่ระบบ? จะไม่Logger.warnขยายมากกว่าLogger.new.warn? หรืออย่างน้อยดูเหมือนว่าใช้งานง่ายกว่าLogger.warnLogger.new.warn

แม้ว่าLogger.newจะเป็นวัตถุซิงเกิลตันมันมีข้อดีอะไรบ้าง?

นี่คือตัวอย่างที่ใช้ Java เป็นเวลานานแล้วที่ฉันใช้ log4j แต่จากสิ่งที่ฉันจำเครื่องมือบันทึก log4j ทั้งหมดจะเริ่มต้นจากไฟล์ XML ไฟล์ XML นั้นอาจมีตัวบันทึกหลายตัวที่มีการกำหนดค่าที่แตกต่างกัน (ที่ที่คุณเขียน, ระดับที่เขียน ฯลฯ ) ดังนั้นในกรณีนี้คุณจะมีวัตถุคนตัดไม้มากกว่าวิธีคงที่คนตัดไม้เพื่อระบุคนตัดไม้ที่คุณต้องการเรียก กล่าวคือ

Logger logger = Logger.get("Network");

จะบันทึกสิ่งต่าง ๆ ที่เกี่ยวข้องกับการเชื่อมต่อเครือข่ายแพ็คเก็ตที่ถูกส่ง ฯลฯ หรือ

Logger logger = Logger.get("Application");

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

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

Logger.new เป็นโรงงานที่จะดำเนินการตามที่จะใช้ผลลัพธ์ (ชื่อของคลาส / ไฟล์)

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

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

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

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

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

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