ТВЕРДЫЕ принципы действительно тверды?

Изменив ваше определение «единоличной ответственности» - принципы SOLID довольно жидкие и (как и другие запоминающиеся акронимы аббревиатур) не означают то, что они, кажется, означают.

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

О принципах проектирования следует помнить: всегда есть исключения, и вы не всегда обнаружите, что ваш сценарий / реализация соответствует заданному принципу на 100%.

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

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

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

Я не думаю, что быть сериализуемым или одноразовым равнозначно множественной ответственности.

Чтобы лучше понять принципы SOLID, вы должны понять проблему, которую они решают:

Объектно-ориентированное программирование выросло из структурированного/процедурного программирования - оно добавило новую организационную систему (классы и др.), а также поведение (полиморфизм, наследование, композиция). Это означало, что ОО не было отделено от структурированного/процедурного, а было прогрессом, и что разработчики могли делать очень процедурные ОО, если они того хотели.

Так... SOLID появился как что-то вроде лакмусовой бумажки, чтобы ответить на вопрос: «Действительно ли я делаю ОО, или я просто использую процедурные объекты?» 5 принципов, если они соблюдаются, означают, что вы довольно далеко до ОО-стороны спектра. Несоблюдение этих правил не означает, что вы не делаете ОО, но это означает, что оно гораздо более структурное / процедурное ОО.

Что ж, я полагаю, первое, что нужно отметить, это то, что это просто хорошие принципы разработки программного обеспечения - вы также должны применять суждение. Так что в этом смысле - нет, они не являются прочными (!)

Я думаю, что вопрос, который вы задали, поднимает ключевой вопрос - как вы определяете единственную ответственность, которую должен иметь класс?

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

Однако, пожалуйста, продолжайте это делать.Хотя это, вероятно, невозможно применить во всех случаях, это все же лучше, чем наличие в вашем коде одного «объекта Бога» (Anti-Pattern).

Если у вас возникли проблемы с этим, я бы порекомендовал прочитать следующее:

• Рефакторинг - Мартин Фаулер: Хотя, очевидно, что речь идет о рефакторинге, эта книга также очень полезна для демонстрации того, как разложить проблемы на их логические части или возможности - что является ключом к SRP. Эта книга затрагивает и другие принципы, но делает это гораздо менее академично, чем вы, возможно, видели раньше.

• Чистый код - Роберт Мартин: Кто может лучше читать, чем величайший представитель принципов SOLID. Серьезно, я нашел эту книгу действительно полезной во всех областях разработки программного обеспечения, а не только о принципах SOLID. Как и книга Фаулера, эта книга предназначена для всех уровней подготовки, поэтому я рекомендую всем.

Здесь есть законное беспокойство, поскольку эти сквозные проблемы (сериализация, ведение журнала, уведомление о привязке данных и т. Д.) В конечном итоге приводят к добавлению реализации к нескольким классам, а это только там для поддержки какой-то другой подсистемы. Эта реализация должна быть протестирована, поэтому класс определенно обременен дополнительными обязанностями.

Аспектно-ориентированное программирование - это один из подходов, который пытается решить эту проблему. Хорошим примером в C # является сериализация, для которой существует широкий спектр различных атрибутов для разных типов сериализации. Идея здесь в том, что класс не должен реализовывать код, выполняющий сериализацию, а должен декларировать, как он должен быть сериализован. Метаданные - очень естественное место для включения деталей, которые важны для других подсистем, но не имеют отношения к тестируемой реализации класса.