SRP: зачем использовать значения полей экземпляра вместо параметров?

Я только что прочитал SRP, так же просто, как 123…, и все это находит отклик во мне, кроме одного абзаца, в разделе под названием «Сплоченность» (ранее я утверждал, что «получил» сплоченность, но этот разговор о параметрах и полях экземпляра дает мне Пауза...):

Возьми свой класс. Посмотрите на ваши методы. У них есть параметры или они используют поля экземпляра? Если они используют параметры, удалите их. Сделайте их экземплярными полями. Вы в конечном итоге с методами, которые используют только один из пяти экземпляров? Скорее всего, это предупреждение о низкой связанности между этим методом и вашим классом.

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

Или предпочтение полей экземпляра над параметрами является фактическим приемом проектирования для поддержания высокой согласованности?

Я как-то вырвал цитату из контекста?


parameters instance-variables c# single-responsibility-principle cohesion
person lance    schedule 20.12.2010    source источник
comment
Мне кажется подозрительным, как фактическое правило. Некоторые методы будут иметь параметры, независимо от того, насколько хорошо вы инкапсулируете ответственность.   -  person Kirk Woll    schedule 20.12.2010
comment
Как ни странно, я бы сказал наоборот, т.е.: если вы видите, что метод класса не использует никаких полей класса, а только параметры, продвигайте его до статического...   -  person digEmAll    schedule 20.12.2010
comment
@dig, да, это стандартное разделение OO и FP.   -  person Kirk Woll    schedule 20.12.2010

Ответы (1)


arrow_upward
2
arrow_downward

CRUD — это действительно распространенный подход к программированию на основе интерфейсов. Возьмем два конкретных класса, реализующих интерфейс CRUD: Employee и Building.

Теперь представьте, как будет выглядеть ваш код, основанный на параметрах:

Employee employeeObj = new Employee();
Building buildingObj = new Building();

string firstName = "Bob";
employeeObj.Create(firstName);

Как насчет строительства?

BuildingTypes buildingType = BuildingTypes.One;
building.Create(buildingType);

Упс... как вы собираетесь реализовать интерфейс CRUD с разными параметрами? Создавать перегрузки? Больше интерфейсов? Как насчет двух параметров (имя фамилия)?

Это станет настолько уродливым, так быстро .... потому что, как только вы используете параметры с интерфейсом CRUD, у вас есть более одной причины для изменения, что снижает целостность дизайна.

Давайте попробуем использовать наши параметры на основе объектов/экземпляров...

Employee empObj = new Employee();
empObj.FirstName = "Bob";

empObj.Create();

Building buildingObj = new Building();
buildingObj.BuildingType = BuildingTypes.One;

buildingObj.Create();

С простым CRUD и без параметров можно даже добавить полиморфизм:

someObj.Create();

Это также приводит к инкапсулированной композиции, развязке, SRP и т. д.

person P.Brian.Mackey    schedule 20.12.2010