Принцип SRP vs private class data design pattern. Хто правий?

Нещодавно, при виконанні тестового завдання я отримав критику, щодо архітектури проекту. Зокрема мова була про недотримання SRP.

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

Пройшов деякий час і я повернувся до SOLID. Вирішено було осягати все на практиці: з кодом, прикладами і IntellijIdea.
Загуглив перший з цієї санскріптної мантри принцип, ткнув в першу урлу з результатів, потрапив на вікі:

ru.wikipedia.org/...​нственной_ответственности

На цьому ресурсі нам намагаються втюхати пояснити цей, перший принцип, на наступному прикладі:

Маємо сутніть (геттери/сеттери відпускаю)

public class Report {
    private String date;
    private String header;
    private String content;
    private String footer;
}

Маємо дії які повинні вміти робити з цією сутністю:

toPrint();
toHtml();
toJson();

Спочатку нам говорять, що можна ці методи додати в класс Report і що це не правильно і я тут повністю погоджуюсь.

public class Report {
    private String date;
    private String header;
    private String content;
    private String footer;

    public void toPrint() {
        //print resport;
    }

    public void toHtml() {
        //generate to html;
    }

}

Далі слідує рішення:

public class Response {

    private Report report;

    public void toPrint() {
        //print resport;
    }

    public void toHtml() {
        //generate to html;
    }

}

Так, рішення не досконале і можна булоб додати реалізацію інтерфейсів і всяке таке, але логіка здавалось би вірна, але ні — на вікі кажуть, що

Вроде классы разделены по назначениям, но у Response есть признак нарушения SRP. Он зависим от Report. Изменяя Report, например, удалив метод получения заголовка, потребуются внести изменения в Response. А ведь изначально не подразумевалось изменять код формата отчёта. Код проекта не готов к быстрым и безболезненным изменениям.

і пропонується вирішити питання за допомогою паттернів проектування, зокрема

Выделение частного класса данных

ru.wikipedia.org/...​ие_частного_класса_данных

Переходимо за посиланням, і що ми бачимо у висновку?:

(приклад надається на C#)

    class CircleData
    {
        private double radius;
        private Color color;
        private Point origin;
    }

    class Circle
    {
        private CircleData circleData;
        
        public Circle(double radius, Color color, Point origin)
        {
            circleData = new CircleData(radius, color, origin);
        }
        public double Circumference
        {
            get { return 2 * Math.PI * this.circleData.Radius; }
        }
        public double Diameter
        {
            get { return 2 * this.circleData.Radius; }
        }
        public void Draw(Graphics graphics)
        {
            //...
        }

    }

А бачимо те, що замінивши класи CircleData на Report, а Circle на Response, і замінивши також методи Circumference, Diameter, Draw на toPrint(), toHtml(), toJson() - ми отримаєм в рішенні той шаблон, який називався «невірним рішенням».

На цьому місці хотілось би зупинитися і розібратися.

Як так виходить що патерни проектування суперечать принципам SOLID?