Рамификации виртуальных методов/свойств

Question

Ола «поток!

Я недавно использовал Moq в своем процессе разработки, и мне нравится то, что я могу достичь.

Однако, я нахожу, что делаю свои методы (и свойства для большинства) виртуальными, чтобы заменить их макетами в моих тестах.

Помимо «вы делаете все свои методы и свойства переопределяемыми», каковы реальные последствия для этого курса действий?

Спасибо за ваше время,

Dan

Answer 1

Ну, вы предотвращаете большинство видов оптимизации. Во-первых, JITTER может не знать, какая реализация будет вызвана, (И он не может, поскольку вы можете использовать Mock, правильно?) Итак, все эти аксессоры свойств, которые были бы встроены, будут реальными звонит сейчас. Thx to inline, простые свойства не будут добавлять реальные издержки во время выполнения. Виртуальные свойства не будут встраиваться, поэтому они и делают.

Это была сторона эффективности вещей, другая проблема заключается в том, что вы не можете доверять свойствам работать, как вы думаете, они работают. Каждое свойство может быть переопределено. Даже самим собой, потому что «в этот раз это действительно имело смысл, верно?». Таким образом, вы обнаружите, что чаще проверяете дерево вызовов, чем обычно, чтобы проверить, какие реализации применимы к коду, над которым вы работаете.

Answer 2

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

Я думаю, что возможность подставить один класс объекта другому (например, макет объекта) - это хорошо, и для этого вам нужен базовый класс с виртуальными методами/свойствами. Это напоминает мне использование абстрактных базовых классов для привязки к Open Closed Principle.