Чи реєстрація поруч із впровадженням є порушенням SRP?

Думаючи про гнучку розробку програмного забезпечення та всі принципи (SRP, OCP, ...), я запитую себе, як ставитись до ведення журналів.

Чи реєстрація поруч із впровадженням є порушенням SRP?

Я б сказав, yesтому що реалізація також має бути спроможна запускатись без реєстрації. Тож як я можу краще реалізувати ведення журналу? Я перевірив деякі шаблони і дійшов висновку, що найкращий спосіб не порушувати принципи визначеним користувачем способом, а використовувати будь-який шаблон, який, як відомо, порушує принцип, - це використовувати шаблон декоратора.

Скажімо, у нас є маса компонентів повністю без порушення SRP, і тоді ми хочемо додати журнал.

• компонент А
• компонент В використовує A

Ми хочемо вести журнал для A, тому ми створюємо ще один компонент D, прикрашений A, що реалізує інтерфейс I.

• інтерфейс I
• компонент L (компонент реєстрації системи)
• компонент A реалізує I
• компонент D реалізує I, декорує / використовує A, використовує L для ведення журналів
• компонент B використовує I

Переваги: ​​- Я можу використовувати A без реєстрації - тестування A означає, що мені не потрібні макети реєстрації - тести простіші

Недолік: - більше компонентів і більше тестів

Я знаю, що це, здається, ще одне питання відкритої дискусії, але я насправді хочу знати, чи хтось використовує кращі стратегії реєстрації журналів, ніж декоратор чи порушення 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, то ви краще, ніж 99% усіх інших програмістів, і вам слід погладити себе по спині.

Сенс SRP полягає в тому, щоб уникнути жахливого коду спагетті, де код, який робить різні речі, все змішується між собою. Змішування журналу з функціональним кодом не дзвонить жодним дзвонам тривоги для мене.

Ні, це не порушення СРП.

Повідомлення, які ви надсилаєте до журналу, повинні змінюватися з тих самих причин, що і навколишній код.

Що таке порушення SRP - це використання певної бібліотеки для входу безпосередньо в код. Якщо ви вирішили змінити спосіб ведення журналу, SRP заявляє, що це не повинно впливати на ваш бізнес-код.

Якийсь конспект Loggerповинен бути доступний для коду вашої реалізації, і єдине, що має сказати ваша реалізація, - це "Надіслати це повідомлення в журнал", без жодних побоювань щодо того, як це робиться. Вирішення питання про точний спосіб ведення журналу (навіть часові позначки) не є обов'язком вашої реалізації.

Тоді ваша реалізація також не повинна знати, чи є реєстратор, якому він надсилає повідомлення NullLogger.

Це сказав.

Я не хотів би занадто швидко переходити на вирубку як наскрізну проблему . Виправлення журналів для відстеження конкретних подій, що відбуваються у вашому коді реалізації, належить до коду реалізації.

Що стосується наскрізних проблем, OTOH, - це відстеження виконання : реєстрація входить та виходить із кожного методу. AOP найкраще робити це.

Оскільки ведення журналів часто вважається наскрізною проблемою, я б запропонував використовувати AOP для відділення журналу від реалізації.

Залежно від мови, для якого ви використовуєте перехоплювач або якусь рамку AOP (наприклад, AspectJ на Java).

Питання в тому, чи справді це варте клопоту. Зауважте, що це розділення збільшить складність вашого проекту, надаючи при цьому дуже мало користі.

Це звучить прекрасно. Ви описуєте досить стандартний декоратор лісозаготівлі. Ти маєш:

компонент L (компонент реєстрації системи)

Це несе одну відповідальність: реєстрацію інформації, яка передається їй.

компонент A реалізує I

Це несе одну відповідальність: забезпечення реалізації інтерфейсу I (якщо я належним чином сумісний з SRP, тобто).

Це важлива частина:

компонент D реалізує I, декорує / використовує A, використовує L для ведення журналів

Коли це сказано так, це звучить складно, але подивіться на це так: Компонент D робить одне : об'єднувати A і L разом.

• Компонент D не реєструється; він делегує це L
• Компонент D не реалізує сам Я; він делегує це А

Тільки відповідальність , що компонент D має, щоб переконатися , що L повідомляється , коли А використовується. Реалізація A і L є і в іншому місці. Це повністю сумісні з SRP, а також є акуратним прикладом OCP і досить звичним використанням декораторів.

Важливий застереження: коли D використовує ваш компонент журналу L, він повинен робити це таким чином, що дозволяє змінити спосіб ведення журналу. Найпростіший спосіб зробити це - мати інтерфейс IL, який реалізується Л. Тоді:

• Компонент D використовує ІЛ для реєстрації; надається екземпляр L
• Компонент D використовує I для забезпечення функціональності; надається екземпляр A
• Компонент B використовує I; надається екземпляр D

Таким чином, нічого не залежить безпосередньо від чого-небудь іншого, що полегшує їх заміну. Це дозволяє легко адаптуватися до змін і легко знущатися над частинами системи, щоб ви могли провести тестування.

Звичайно, це порушення СРП, оскільки ви маєте наскрізну стурбованість. Однак ви можете створити клас, який відповідає за складання журналу з виконанням будь-якої дії.

приклад:

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