Приватный метод - повод для нового класса

Следующий код требует рефакторинга:

public class MailingServiceImpl implements MailingService {

    @Override
    public sendMail(Message message) {
        Message signedMessage = addDefaultSign(message);
        ...
    }

    /**
     * Добавление подписи по умолчанию
     * @param message сообщение
     * @return сообщение с подписью
     */
    private Message addDefaultSign(Message message) { ... }
}

Конкретно, метод addDefaultSign нужно вынести в отдельный сервис. Почему?

Приватный метод имеет javadoc - видимо, автор надеялся так объяснять его предназначение, ведь по-другому никак не удастся. Но, все равно, пользуясь сервисом MailingServiceImpl, надо всегда держать в голове то, что он добавляет к сообщению подпись, потому что в имени сервиса это никак не отражено. Более того, если вдруг заказчик придет и скажет, что ему нужно рендерить для модерирования письмо перед отправкой, то эту проблему можно решить только костылями: скопировать метод добавления подписи в класс отрисовки письма или добавить метод отрисовки в сервис отправки почты, или еще что-нибудь в этом духе. Оба решения - катастрофа для кода в проекте.

Потому что сервис отправки почты должен заниматься только отправкой почты и ничем другим. Конечно же, отправка почты - это размытое определение, но в него точно не входит корректировка содержания письма. Необходимо формировать сообщение заранее.

Создавая private метод, нужно подумать, действительно ли его место в этом классе

Это можно сделать, например, с помощью декоратора:

class SignedMessage {
    public SignedMessage(Message origin) { ... }
}

...

MailingService mailingService;
Message message;

...

mailingService.sendMail(new SignedMessage(message));

---

Существуют много примеров private методов, которые не нарушают SRP, но в своей практике я вижу очень часто приватный код, занимающийся совершенно не делами сервиса, в котором находится. Создавая приватный метод, нужно подумать, действительно ли его место в этом классе?