Недостаток принципа единой ответственности

Question

Я прочитал несколько книг и послушаю лекцию о разработке программного обеспечения. Но я не знаю, как решить проблемы, вызванные следующими проектами проектирования OO.

Вот несколько ситуаций. Я начинаю проектировать простой одиночный класс (ClassA). После этого ClassA растет с аналогичными обязанностями. В соответствии с принципом единоличной ответственности я извлекаю некоторую логику от ClassA до ClassB. ClassA снова становится достаточно простым. Однако ответственность ClassA может быть аналогичной с классом ClassB, , так что ClassA и ClassB имеют ссылки друг на друга в качестве полей или свойств членов для сотрудничества. Другими словами, разделение классов делает еще одну сложность. Это взаимодействие между отдельными классами. Впоследствии каждый из классов ClassA и ClassB может также развиваться с более сложными функциями ответа, , а некоторые классы (ClassC или ClassD) могут быть отделены от ClassA или ClassB. Теперь взаимодействие между классами становится намного сложнее. Каждый из классов может иметь ссылки на другие классы как поля memeber или параметры метода.

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

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

Я прочитал несколько книг по дизайну OO. Большинство из них говорят, что простой класс хорош. Ни один из них, однако, не сосредоточен на сложности взаимодействия классов, вызванных SRP.

Пропустить что-нибудь? Как решить эту проблему?

Answer 1

Ответственность означает одну причину изменения.

Возможно, вам придется изменить класс A по одной причине, и вы, вероятно, случайно измените поведение другой ответственности в классе A. Иногда вам просто нужна одна из функций класса A для использования или тестирования, но вам нужно для создания целого класса A.

Если вы не отдельный класс а в классе а, в, с и D, взаимодействие между обязанностями по-прежнему существуют, но скрыты в классе А.

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

Answer 2

Я думаю, что это не нормально думать о srp с точки зрения размера класса. Думаю, вам стоит подумать об актерах и причинах изменения.

Актеры - это роли, которые хотели бы изменить ваш класс. Например, если у вас есть такой класс:

class User 
{ 
    public function calculatePay() 
    public function save() 

} 

Две разные роли захотят изменить ваш класс. Например, бухгалтеру захочется изменить метод calculatePay, и администратор базы данных захочет изменить метод save(). Этот класс может измениться по двум причинам.

Я думаю, что лучше подумать о srp с точки зрения «группировки вещей, которые меняются по той же причине».