Что я называю этим стилем программирования?

Question

Я работаю с типом, который передает состояние через переменные экземпляра. Таким образом, вы увидите такие методы:

public MyType MyMethod() 
{ 
    DoThisMethod(); 
    DoThatMethod(); 
    AndDoThis(); 

    return _bleh; 
} 

Это признанный подход?

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

Answer 1

Если порядок этих вызовов методов важен, я бы назвал это «Плохое программирование» - как вы сказали, какой-либо метод, требующий более раннего вызова, должен использовать параметры метода, которые являются показательными для этого.

Я уверен, что Code Complete дает отличные примеры такого подхода.

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

public MyType MyMethod() 
{ 
    thisResult = DoThisMethod(); 
    thatResult = DoThatMethod(thisResult); 
    _bleh = AndDoThis(thatResult); 

    return _bleh; 
} 

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

Answer 2

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

Answer 3

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

Answer 4

Это противоположность функционального программирования. Самое близкое, что я могу придумать, - это «программирование с учетом состояния», но это, похоже, недостаточно уничижительно. Однако, вероятно, он квалифицируется как структурированное программирование.

В качестве альтернативы, если вы считаете, что HTTP-запросы аналогичны вызовам метода, а реализация «Сессия» похожа на экземпляр объекта, то это именно то, как разрабатывается множество сайтов. И (ИМХО), это тоже не хороший дизайн.

Answer 5

Существует вероятность того, что «последовательная связь» (http://en.wikipedia.org/wiki/Sequential_coupling) также может быть распознана, если ограничения на методы, вызывающие методы, ограничены.