Понимание принципа единой ответственности с помощью этого реального фрагмента кода

Я думаю, что важно помнить о том, чтобы ваши обязанности оставались на том же уровне абстракции. Это означает, что если вы разбиваете эту одну функцию на несколько частей, да, она будет выполнять много вещей, однако у нее будет одна ответственность - оркестровка работы на более низком уровне абстракции.

В качестве примера приведем первую часть вашей функции после некоторого рефакторинга:

public List<ProjectElement> getFavoriteProjectElementsSortedDescendingByTotalWorkHoursInLast60Days(Employee owner) {
    // All Favorite Project Elements of Owner
    final List<ProjectElement> favoriteProjectElementsOfOwner
            = (List<ProjectElement>) (List<?>) favoriteBusinessObjectHelper.getAllFavoriteObjectsForBusinessObjectType(BusinessObjectType.PROJECT_ELEMENT.toInt());

    // Activities by Favorite Project Elements
    final List<Activity> favoriteProjectElementActivitiesForLast60Days
            = activityFinder.findByInProjectElementsForLastGivenDates(owner, favoriteProjectElementsOfOwner, 60);

    // Create a Map with Favorite Project Element - Calculated Work
    final Map<ProjectElement, Long> projectElementTotalWorkMap = this.makeFacoriteProjectMap(favoriteProjectElementActivitiesForLast60Days)

Функциональность, которая генерирует ваш projectElementTotalWorkMap, была перемещена в частную функцию. Так что теперь выяснение того, как построить карту, больше не является вашей основной обязанностью. Если в способе создания карты есть ошибка, вам нужно только посмотреть функцию, в которую вы ее переместили:

private Map<ProjectElement, Long> projectElementTotalWorkMap makeFacoriteProjectMap(List<Activity> favoriteProjectElementActivitiesForLast60Days)
{
    Map<ProjectElement, Long> projectElementTotalWorkMap= new HashMap<ProjectElement, Long>();
    for (Activity activity : favoriteProjectElementActivitiesForLast60Days) {
        final ProjectElement activityProjectElement = activity.getProjectElement();
        if (!projectElementTotalWorkMap.containsKey(activityProjectElement)) {
            projectElementTotalWorkMap.put(activityProjectElement, 0L);
        }
        final long calculatedWork = activity.getCalculatedWork();
        final long totalCalculatedWork = projectElementTotalWorkMap.get(activityProjectElement) + calculatedWork;
        projectElementTotalWorkMap.put(activityProjectElement, totalCalculatedWork);
    }

    return projectElementTotalWorkMap;
}

Раньше, если вы обнаружили ошибку в способе создания этой карты, вам пришлось бы изменить основную функцию. Основная функция также должна быть изменена, если, например, что-то произошло в неправильном порядке.

Оркестровка теперь является единственной ответственностью основных функций.

Этот же рефакторинг может быть применен для создания вашего projectElementsSorted ArrayList, после чего функция getFavoriteProjectElementsSortedDescendingByTotalWorkHoursInLast60Days будет иметь 1 обязанность - организовать шаги, чтобы предоставить вам отсортированный список рабочих часов за последние 60 дней.

Будут и другие небольшие частные функции, каждая из которых будет выполнять свою собственную ответственность. Даже при таком большом количестве частных функций, каждая из которых выполняет свои собственные функции, основной класс, в котором находится этот код, по-прежнему несет одну ответственность перед внешним миром.

Чтобы связать вас с примером лая вашей собаки, я проведу еще одну аналогию. Допустим, у вас есть дрессировщик, который приучит вашу собаку к выступлению в цирке. В конце концов, собака должна уметь:

class Dog
{
    public void PerformRoutine()
    {
        this.bark();
        this.sit();
        this.walkInCircle();
        this.rollOver();
    }
    //...
}

Несмотря на то, что эта функция выполняет множество функций, единственная причина, по которой эта функция может когда-либо измениться, - это изменение процедуры. Однако, если звук, который издает собака, должен измениться, вы сюда не смотрите. Все в функции PerformRoutine находится на одном уровне абстракции.

В контексте корпоративных приложений у вас часто есть уровень службы / API, управляющий сохранением, загрузкой и вызовом объектов домена. Эти функции кажутся нарушающими СР, но все они по-прежнему являются частью одной и той же ответственности. Сохранение и загрузка - это ответственность ваших репозиториев. Фактическая логика - это ответственность ваших доменных объектов. Эти API / сервисы на самом деле просто делают одно - организуют и делегируют другим сервисам.

Я надеюсь это тебе поможет.

РЕДАКТИРОВАТЬ: Чтобы ответить на ваш вопрос о том, какова ценность всего этого:

Рассмотрим предыдущий пример собаки без SR:

class Dog
{
    public IEnumerator PerformRoutine()
    {
        this.audioController.PlaySound("c:/bar.mp3");
        this.animationControl.Play("Sit.anim");

        yield return new WaitForSeconds(2);

        this.animationController.Play("stand.anim");         

        yield return new WaitForSeconds(1);

        foreach(Vector3 pos in this.WalkPositions)
        {
            this.animationController.Play("walk.anim");
            this.position.lerpTo(pos, 5.0f); // move to position over 5 seconds.

        }

        this.animationController.Play("roll.anim");
    }
    //...
}

Теперь любой новый член команды должен точно понимать детали реализации этой функции, чтобы понять, что она на самом деле делает. Это уже сильно упрощено.

Если вы спросите нового члена команды (или даже если вы вернетесь к своему старому коду), в идеале вам захочется просмотреть его и понять, что он делает. Имя функции «PerformRoutine» не подготавливает читателя к анимации или логике движения.

Если вас вернули к этому коду из-за того, что собака ходит по квадрату, а не по кругу, будет сложнее настроить этот код.

Теперь примените те же рассуждения в корпоративном решении с сотнями тысяч строк кода и тысячами функций. Это становится настолько неуправляемым, что в конце концов хочется бросить курить.

Вот еще один пример интеграции REAL LIFE, которую я сделал для инвестиционной компании. Вот примерно сторонний код, который занял несколько дней в моем графике разработки:

public List<Event> getEventData()
{
    var toReturn = new List<Event>(this.eventData);
    this.eventData.Clear();
    return toReturn;
}

Вот. Вызов этой функции дважды подряд дает совершенно разные результаты, потому что писатель не беспокоился ни о SR, ни о правильном именовании.

С минимальными усилиями это могло быть две функции - getEventDate() и clearEventData(). Я бы даже остановился на одной функции с другим именем - getAndClearEventData(), хотя последнее нарушает SR.