การบันทึกถัดจากการใช้งานเป็นการละเมิด SRP หรือไม่

เมื่อคิดถึงการพัฒนาซอฟต์แวร์ที่คล่องตัวและหลักการทั้งหมด (SRP, OCP, ... ) ฉันถามตัวเองว่าจะจัดการการบันทึกอย่างไร

การบันทึกถัดจากการใช้งานเป็นการละเมิด SRP หรือไม่

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

สมมติว่าเรามีส่วนประกอบจำนวนมากโดยไม่มีการละเมิด SRP จากนั้นเราต้องการเพิ่มการบันทึก

• องค์ประกอบ A
• องค์ประกอบ B ใช้ A

เราต้องการบันทึกสำหรับ A ดังนั้นเราจึงสร้างส่วนประกอบอีก D ที่ตกแต่งด้วย A ทั้งสองใช้อินเตอร์เฟส I

• อินเตอร์เฟส I
• component L (บันทึกองค์ประกอบของระบบ)
• องค์ประกอบ A ใช้ I
• component D ใช้ I, ตกแต่ง / ใช้ A, ใช้ L สำหรับการบันทึก
• องค์ประกอบ B ใช้ I

ข้อดี: - ฉันสามารถใช้ A โดยไม่ต้องบันทึก - การทดสอบ A หมายความว่าฉันไม่ต้องการ mocks การบันทึกใด ๆ - การทดสอบนั้นง่ายกว่า

ข้อเสีย: - ส่วนประกอบเพิ่มเติมและการทดสอบเพิ่มเติม

ฉันรู้ว่านี่เป็นคำถามเปิดการอภิปราย แต่ฉันต้องการทราบว่ามีคนใช้กลยุทธ์การบันทึกข้อมูลที่ดีกว่ามัณฑนากรหรือการละเมิด SRP สิ่งที่เกี่ยวกับคนตัดไม้ซิงเกิลตันแบบคงที่ซึ่งเป็นค่าเริ่มต้น NullLogger และถ้าต้องการ syslog- เข้าสู่ระบบหนึ่งเปลี่ยนวัตถุการใช้งานที่รันไทม์?

ใช่เป็นการละเมิด SRPเนื่องจากการบันทึกเป็นข้อกังวลที่ตัดขวาง

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

ดูลิงค์นี้สำหรับตัวอย่างที่ดี: https://msdn.microsoft.com/en-us/library/dn178467%28v=pandp.30%29.aspx

นี่เป็นตัวอย่างสั้น ๆ :

public interface ITenantStore
{
    Tenant GetTenant(string tenant);
    void SaveTenant(Tenant tenant);
}

public class TenantStore : ITenantStore
{
    public Tenant GetTenant(string tenant)
    {....}

    public void SaveTenant(Tenant tenant)
    {....}
} 

public class TenantStoreLogger : ITenantStore
{
    private readonly ILogger _logger; //dep inj
    private readonly ITenantStore _tenantStore;

    public TenantStoreLogger(ITenantStore tenantStore)
    {
        _tenantStore = tenantStore;
    }

    public Tenant GetTenant(string tenant)
    {
        _logger.Log("reading tenant " + tenant.id);
        return _tenantStore.GetTenant(tenant);
    }

    public void SaveTenant(Tenant tenant)
    {
        _tenantStore.SaveTenant(tenant);
        _logger.Log("saving tenant " + tenant.id);
    }
}

ประโยชน์ที่ได้รับ

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

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

จุดของ SRP คือการหลีกเลี่ยงรหัสสปาเก็ตตี้ที่น่ากลัวซึ่งรหัสที่ทำสิ่งที่แตกต่างกันทั้งหมดเข้าด้วยกัน การผสมการบันทึกด้วยรหัสการทำงานไม่ได้ทำให้เสียงสัญญาณเตือนดังขึ้นสำหรับฉัน

ไม่ไม่ใช่การละเมิด SRP

ข้อความที่คุณส่งไปยังบันทึกควรเปลี่ยนด้วยเหตุผลเดียวกับรหัสโดยรอบ

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

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

NullLoggerการดำเนินงานของคุณแล้วก็ควรที่จะไม่ทราบว่าคนตัดไม้มันจะส่งข้อความไปยังเป็น

ที่กล่าวว่า

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

อะไรคือสิ่งที่เป็นข้อกังวลข้าม OTOH คือการติดตามการดำเนินการ : การบันทึกเข้าและออกในแต่ละวิธี AOP อยู่ในตำแหน่งที่ดีที่สุดในการทำเช่นนี้

เนื่องจากการบันทึกมักจะถูกพิจารณาว่าเป็นข้อกังวลข้ามกันฉันขอแนะนำให้ใช้ AOP เพื่อแยกการบันทึกจากการนำไปใช้

ขึ้นอยู่กับภาษาที่คุณใช้ Interceptor หรือกรอบ AOP (เช่น AspectJ ใน Java) เพื่อทำสิ่งนี้

คำถามคือถ้ามันคุ้มค่ากับความยุ่งยาก โปรดทราบว่าการแยกนี้จะเพิ่มความซับซ้อนของโครงการของคุณในขณะที่ให้ประโยชน์น้อยมาก

ฟังดูดีนะ คุณกำลังอธิบายมัณฑนากรการบันทึกข้อมูลมาตรฐานที่ค่อนข้างยุติธรรม คุณมี:

component L (บันทึกองค์ประกอบของระบบ)

สิ่งนี้มีหน้าที่รับผิดชอบอย่างหนึ่งคือการบันทึกข้อมูลที่ส่งผ่านไป

องค์ประกอบ A ใช้ I

สิ่งนี้มีความรับผิดชอบอย่างหนึ่ง: การนำเสนอการดำเนินการของส่วนต่อประสานที่ฉันใช้

นี่คือส่วนสำคัญ:

component D ใช้ I, ตกแต่ง / ใช้ A, ใช้ L สำหรับการบันทึก

เมื่อระบุด้วยวิธีนี้ฟังดูซับซ้อน แต่ดูด้วยวิธีนี้: Component D ทำสิ่งหนึ่ง : นำ A และ L มารวมกัน

• คอมโพเนนต์ D ไม่บันทึก มันมอบให้กับแอล
• คอมโพเนนต์ D ไม่ได้ใช้ตัวเอง มันมอบให้กับ A

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

ข้อแม้ที่สำคัญ:เมื่อ D ใช้องค์ประกอบการบันทึกของคุณ L มันควรทำในลักษณะที่ช่วยให้คุณเปลี่ยนวิธีการบันทึกของคุณ วิธีที่ง่ายที่สุดในการทำเช่นนี้คือการมีส่วนต่อประสาน IL ซึ่งถูกใช้งานโดย L. แล้ว:

• คอมโพเนนต์ D ใช้ IL เพื่อบันทึก ตัวอย่างของ L มีให้
• Component D ใช้ I ในการจัดเตรียมการทำงาน ตัวอย่างของ A มีให้
• องค์ประกอบ B ใช้ I; ตัวอย่างของ D มีให้

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

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

ตัวอย่าง:

class Logger {
   ActuallLogger logger;
   public Action ComposeLog(string msg, Action action) {
      return () => {
          logger.debug(msg);
          action();
      };
   }
}