Читаемость vs. Проверка на этапе компиляции

6yrop

Есть ветвистый алгоритм, которые реализуется через набор вложенных объектов
int result = new Class3(new Class2(new Class1.Do;
т.е. мы дергаем метод класса Class3, а он по цепочке вызывает методы класса Class1. Но собственно result определяется уже методами класса Class1, а методы классов Class3 и Class2 просто транслируют результат наружу.
Можно избавить классы от трансляции результата и ввести свойство Result у класса Class1
Class1 class1 = new Class1;
new Class3(new Class2(class1.Do;
int result = class1.Result;
Тогда Class3 и Class2 будут иметь void методы, т.е. не надо описывать что возвращают эти методы, и читающий не будет задумываться над этим. Но при этом мы теряем проверку на этапе компиляции, что вызов вообще дойдет до класса Class1, и что свойству Result будет что-то присвоено.
Mожно даже по новомодному
int result = default(int);
new Class3(new Class2(new Class1(x => result = x.Do;
Вопрос: стоит ли жертвовать проверкой на этапе компиляции?
Вопрос возник в связи с тем, что я, действительно, случайно закрыл фигурную скобочку у оператора if чуть ниже, чем надо было, и вызов не доходил до Class1. А еще не хочется тестить все веточки алгоритма и даже юнит тесты писать не охота (тесторы оттестят )

vall

а почему нельзя создание этих магических стеков систематизировать?
вынести в какую-нить факторю.

6yrop

а почему нельзя создание этих магических стеков систематизировать?
вынести в какую-нить факторю.

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

vall

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