Принцип единой ответственности (SRP) - что с ним не так?

Этот принцип из набора SOLID любят часто разбирать, доходит даже до требования его знать при приеме на работу. Но действительно ли Вы знаете о нем все, что требуется? В серии видео подробно разбираются все проблемы, которые он вам доставит, если будете ему следовать. Заглянем в историю и поймем как это принцип формулировался и остается ли он актуальным по сей день? Мой ответ нет!

Часть первая. Игра "Боулинг"

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

Часть вторая. Б. Мартин vs. Г. Буч

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

Часть третья. Что вместо этого принципа?

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

4K4K показов
1.1K1.1K открытий
36 комментариев

Комментарий недоступен

Ответить

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

Ответить

Ну эта концепция не так сложна, как Dependency Injection

Ответить

Ну, DI самая базированная вещь как мне кажется и не столь сложно.

Ответить

Да и внедрение зависимостей не так сложна, как грамотное отношения между объектами и данными)

Ответить

Вкратце можно?

Ответить