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

Это более философский вопрос, который относится к платформе .NET, но, возможно, он полезен и для других языков. Я делаю много Unit Testing и особенно когда я использую сторонние компоненты, с которыми я часто сталкиваюсь. В .NET огромное требование к дизайну компонентов (er) к выбору, какой метод должен быть виртуальным или нет. С одной стороны, это использование компонента (что имеет смысл быть виртуальным), с другой - это компонент mockability . Вы можете использовать планки для моделирования сторонних компонентов, но это часто приводит к плохому дизайну и сложности. Как я помню, дискуссия о том, чтобы все методы были виртуальными (JAVA имеет это с самого начала), в .NET было около производительности. Но это все еще проблема? Почему не все методы в .NET виртуальны или почему у каждого класса нет хотя бы одного интерфейса?

8 голосов | спросил Anton Kalcik 31 Mayam16 2016, 11:31:40

2 ответа


8

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

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

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

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

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

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

ответил gbjbaanb 31 Maypm16 2016, 18:49:59
6

На ваш вопрос есть два элемента, поэтому я попытаюсь обратиться к ним по очереди:

  1. Почему по умолчанию не используются методы .NET?

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

  2. Почему все классы не реализуют интерфейс?

    Плохой дизайн - это простой ответ. Несмотря на то, что в течение очень долгого времени они обычно признаны хорошими практиками, к сожалению, многие люди все еще не разрабатывают свои системы с DI и TDD.

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

ответил David Arno 31 Maypm16 2016, 12:26:52

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132