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

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

Рассматриваем книгу Б. Мартина "Быстрая разработка программ", конкретно пытаясь понять как им и Б. Косом программировалась игра "Боулинг" (этому посвящена одна из глав). Делаем это, чтобы понять вначале контекст как возник и кто тот человек, который предложил принцип единой ответственности. Понимаем, что это "заядлый структурщик", который пробывал себя в роли ООП`шника, подробное рассмотрение "игры в боулинг" однозначно приводит нас к этому пониманию. Подтверждается, что этот принцип (единой ответственности) позволяет немного сгладить эффекты, когда на объектно-ориентированном языке программируют те, кто думают исключительно структурно. Получается немного лучше, чем полностью в структурной (процедурной) парадигме, но все же далеко, если думать сразу в терминах ООП. Показывается пример того, если программировать "игру боулинг" изначально с помощью ООП, и становится понятно чем это отличается.

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

Вторая часть.

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

Третья часть.

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