ООП - SRP, есть упоротость.

SOLID это вообще смех - несколько принципов выдранных ради того, чтобы получилось красивое слово.

Выстраданные практикой. Такой же словарик как и GoF. Позволяют не мычать в попытках доказать свою объективность коллегам.

у тебя книга слишком много на себя берет, все эти setContent, save, getContent никакого отношения не имеют. Зачем нужны лишние функции? Представь себе автомобиль с функцией смены двигателя ... Весьма не практично ... Придется постепенно сменить весь автомобиль ...

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

setContent это больше builder, reader как угодно.

Используй больше абстракций и определись с прямым назначением книги и главными атрибутами.

Можно задать модель с разумной степенью детализации.

Например: книга, частный случай носителя информации типа hard copy или что-то в этом роде ...

ОПушка, слушай в треде только этого ленивца плюс данный коммент. Все остальные тут (полу?)фрики.

// FizzBuzz пример на github просто пародирующая репа.

Выстраданные практикой.

Что значит «выстраданные практикой»? Это баззворд, который никакого отношения к реальности не имеющий.

Представим себе сказочную страну, где стоматологи лечат зубы через жопу. Идет время, прогресс не стоит на месте, умные инженеры придумывают зело мудреные техсредства для такого лечения. Уже дошли до того, что стоматолог, ставя пломбу через жопу, видит этот зуб на мониторе так, как будто он заглядывает поциэнту в рот, а поциэнт при манипуляциях не чувствует запах говна во рту. естественно, статистика улучшается, наверх бодро рапортуют, что методика подкреплена практикой, ДОКАЗАНО опытом, подтверждается статистикой. Для этой сказочной страны, данные факты являются ПРУФ ОФ КОНЦЕПТ.

Парадокс в том, что мы именно в такой сказочной стране и живем, только вместо лечения зубов через жопу у нас SOLID, и ряд других «доказанных» технологий. И это не шутка. И касается не только программирования.

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

индивидам с потенцией.

Это ты так энтерпрайзное быдло называешь? А Алан Кей, значит, потенцией не обладает? Я даже боюсь представить что тут под «творчеством» подразумевается, не буду спрашивать. Да и вообще, лучше не отвечай на это сообщение, творец.

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

Или это комплимент был?:)

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

более нагляднее представить себе волшебный мир неосиляторов ...

Я придумал еще пример:
Нам нужно сделать такой компонент, который бы показывал дату, а при нажатии на него появлялся диалог с выбором даты.

class DateEditView extends EditTextView implements DateEditDialog.OnDateListener {
    public void onClick() {
        DateEditDialog d = new DateEditDialog();
        d.setOnDateListener(this);
        d.show();
    }

    public void onDateListener(Date date) {
        this.setText(date.toString("dd-MM-yyyy"));
    }
}

Можно получить контент книги
Можно распечатать на принтере

В таком случае книге не требуется уметь себя печатать, это задача принтера.

При редактировании контента, книга сохраняется в БД

Этим должен заниматься класс БД.

Вроде бы 2 обязанности

Вообще очень плохой термин responsibility. А на русский он вообще не в ту сторону переводится. В данном примере onClick и onDateListener тесно связаны по reason to change.

В твоём примере ООП не имеет смысла. Тебе надо сделать структуру, содержащую в себе поля и отдельные процедуры для сохранения и чего угодно.

class Book {
    public int id;
    public String content;
}

public void print(Printer printer, Book book) {
        // предположим, что тут сложная логика из 15 строк для работы с принтером. Но больше ни один класс печататься не умеет
    printer.selectPrinterAndPrint(book.content);
}

public void save(Database database, Book book) {
    // предположим тут сложная логика сохранения в бд, но больше ни один класс не сохраняется
    database.updateOrInsert(book.id, book.content);
}

Как такой вариант:

class Book {
    private String content;
    private BookStorage storage;
    private BookPrinter printer;
    
    public void setContent(String content) {
        this.content = content;
        save();
    }
    
    public String getContetnt() {
        return this.content;
    }
    
    private void save() {
        storage.save(this);
    }
    
    public print() {
        printer.print(this);
    }
}

class BookStorage {
    private SqliteDatabase db;
    
    public void save(Book book) {
        // сложная логика по сохранению
    }
}

class BookPrinter {
    public void print(Book book) {
        // сложная логика
    }
}

новая версии пытается знать еще больше ...

Убери все функции до предела, для начала

Заморочка в том, что клиент класса book не хочет ничего знать о BookPrinter и BookStorage, для печати и сохранения при изменении.

Для этого есть IoC. Не хочет знать (и правильно не хочет) — пусть просто объявит у себя поле BookPrinter printer и использует его. А кто-нибудь умнее уже запишет в это поле то, что надо.

Методы просто делегируют выполнение нужным классам.
Такой вариант нормальный? Или тут тоже нарушение SRP, кроме нарушения OCP?

Ты пытаешься делать ОО-решение, когда книга сама умеет делать что-то осмысленное. Я (и некоторые другие в этом треде) придерживаются взгляда, что если язык умеет ООП (или ФП или ещё что-нибудь), это не означает, что весь код обязан быть написан в этом стиле. Надо выбирать подходящий для каждого случая. Для твоего случая, как мне кажется, подходящим стилем будет процедурный вариант.

Если даже делать ОО-решение, всё равно книга не должна держать у себя Printer и Storage, т.к. это не её зона ответственности, откуда она знает, куда её хотят сохранить. Это решает тот, кто её сохраняет. Если у тебя в проекте единственный Storage, проще его синглтоном сделать (замаскировав в паттерне «Service Locator», чтобы тестировать можно было) и пусть книга его использует.

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

Вот такой пример:

class ComplexObject {
    private String field1;
    private int field2;
}

class ComplexObjectRepository {
    private SqliteDatabase db;
    private ComplexObjectSerializer serializer;

    public void save(ComplexObject object) {
        String serializedData = serializer.serialize(object);
        // сложная логика сохранения в БД
    }
}

class ComplexObjectSerializer {
    public String serialize(ComplexObject object) {
        // сложная логика сериализации в особый формат
    }
}

Но как это делать она не знает.

это не освобождает от ответственности

Ну вообще нормальный подход. Разделение на мелкие сущности есть зло. Потому что можно легко дойти до абсурда и вместо полноценной абстракции «человек» получить набор непонятных IГоер (а потом и IЛевыйГоер, IПравыйГоер), IХватаер и прочее.

Короче говоря, ООП это абстракция, инкапсуляция, наследование и полиморфизм. Где абстракция это выражение бизнес моделей в коде так, как они изложены в описании предметной области.

Вообще, объект это штука, которая обладает состоянием и поведением, которое оперирует этим самым состоянием. И суть инкапсуляции заключается в том, чтобы состояние наружу не торчало. В примере с книгой инкапсуляция нарушена. Содержимое книги (а это состояние, как я понял) торчит наружу совершенно беспрепятственно. Ну сделать тогда его public полем и не заморачиваться.

Я бы сделал так:

class Book {
    private final int id;
    private final String content;

    // или вообще всю эту логику вынести в Database
    public static Book loadFrom(Database db, int id) {
        String content = db.select(id);
        return new Book(id, content);
    }

    public Book(int id, String content) {
        this.id = id;
        this.content = content;
    }

    public void printWith(Printer printer) {
        printer.selectPrinterAndPrint(content);
    }

    public void saveTo(Database db) {
        db.updateOrInsert(id, content);
    }
}

Страдал как-то tell don't ask и доходило до абсурда. Но вообще в целом эта идея больше ООП, чем все остальные.

Где абстракция это выражение бизнес моделей в коде так, как они изложены в описании предметной области.

Ню-ню. Нет никаких описаний предметной области. Есть бизнес задачи, и чем меньше ты потратишь времени на формализацию и напишешь рабочий код тем быстрее выкатишь фичу. Привет 90-ым.

Эта идея говно, потому что нет ни одной причины почему loadFrom, printWith и saveTo должны быть в Book.

Поправочка, printWith еще можно допустить. Остальное это просто лишнее делегирование.

Почему бы и нет. SaveTo интерфейс можно было бы использовать и для печати. Только название нужно придумать получше. Вот только все это Гуано очень сложно вяжется, когда нужно данные показать в GUI.

Эта идея говно, потому что нет ни одной причины почему loadFrom, printWith и saveTo должны быть в Book.

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

Тестируется юнит тестами? Да. Позволяет изменять поведение печати и БД не трогая книгу? Да.

Равно как и нет причин почему их там быть не должно.

Внутре дергается один метод и это очень похоже на тупое делегирование, которого можно не делать. Все же просто.

Страдал как-то tell don't ask и доходило до абсурда. Но вообще в целом эта идея больше ООП, чем все остальные.

Фаулер об этом и пишет, что не стоит доводить до абсурда. Это не серебряная пуля.

Внутре дергается один метод и это очень похоже на тупое делегирование, которого можно не делать. Все же просто.

Внутре у ней неонка. Я не понял, что такое «тупое делегирование», но идея в том, что зависимости отдается состояние. Которое доступно только книге. И зависимость ваще не в курсе, кому она отдается и кто в нее печатает, сохраняет или что то там делает.

Но тема ООП холиварная ага :).

Вот только все это Гуано очень сложно вяжется, когда нужно данные показать в GUI.

Обычно вводят дополнительные абстракции, типа MVP (для формочек) и MVC (для веба). Где M это модели (например, книга), P штука, которая связывает между собой M и V. Ну, а V это морда. Хз, насколько это правильно.

Нет, не в этом дело. Иногда нужно уметь запрашивать данные, что бы не городить ужасные конструкции. MVP/MVC тут вообще не связано с этой концепцией.

А, ну может я неправильно понял.

Просто я встречал такую штуку. Презентер создает/получает модель и ей отдает интерфейс с методом showContent или printText или еще что-то в этом роде. А за интерфейсом скрывается Вид. В итоге ситуация получается сходна с принтером. Мы отдаем Вид, который может показывать текст, а текст это состояние модели. Которое она успешно отдает в сообщении printText. Слои получаются низкосвязными (Вид не знает о Модели, он только реагирует на сообщение вывода текста, не зная откуда он берется) и нет необходимости явно выдергивать состояние из Модели. И мне понадобилось совсем немного времени на то, чтобы понять, что происходит и закрыть задачу при таком подходе.

А вот как отображать текст - это зависит от Вида и от его параметров.

Но тема ООП холиварная ага

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

Вообще пример FizzBuzz EE очень показательный. Из него можно вынести два урока. Первый состоит в том, что накладные расходы, связанные с внесением дополнительных уровней косвенности, довольно значительны. Нужно каждый раз оценивать, когда это даёт выгоду, а когда приводит к ненужной сложности. Второй урок более важен - нужно каждый раз думать головой, применяя любые принципы/паттерны/методики/ООП. Когда от них будет больше вреда, чем пользы, а когда наоборот? Когда стоит применять, а когда нет?

Если проанализировать песни кукаретиков, то можно заметить, что все они на один лад - «вот, посмотрите, я пытался не думая головой применить ваши принципы/паттерны, и получилось плохо, значит ваши принципы/паттерны говно»!

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

Принципы/паттерны не заменяют умение проектировать, не заменяют голову. Слепое их применение ведёт к дополнительным расходам и следовательно к разочарованию и боли. Не повторяйте ошибок анонiмуса.

Но как гласит принцип, у класса должна быть только одна причина для изменения.

с этого момента поподробнее. кто это сказал и где?

в плюсах, джаве и шарпе, классы вообще неизменны в рантайме, кстати