Действительно ли идиома Невиртуального интерфейса (NVI) так же полезна в C# как в C++?
В C++ мне часто был нужен NVI для получения непротиворечивости в моих API. Я не вижу, что это использовало в качестве многого среди других в C#, все же. Интересно, является ли это вызвано тем, что C#, как язык, предлагает функции, который делает NVI ненужный? (Я все еще использую NVI в C#, тем не менее, при необходимости.)
3 ответа
Я думаю, объяснение просто в том, что в C# "традиционное" ООП в стиле Java гораздо более укоренилось, а NVI противоречит этому. В C# есть настоящий интерфейсный тип, тогда как NVI полагается на то, что "интерфейс" на самом деле является базовым классом. Так это делается в C++, так что это естественно вписывается туда.
В C# это все еще можно сделать, и это все еще очень полезная идиома (гораздо более полезная, я бы сказал, чем "обычные" интерфейсы), но она требует игнорирования встроенной возможности языка.
Многие программисты на C# просто не будут считать класс NVI "правильным интерфейсом". Я думаю, что это ментальное сопротивление - единственная причина, почему он менее распространен в C#.
Я думаю, что NVI так же полезен в C #, как и в C ++. Я вижу, что он очень часто используется в моей компании.
C # создает проблему с NVI, убирая множественное наследование. Хотя я действительно считаю, что множественное наследование порождает больше зла, чем добра, оно необходимо (в большинстве случаев) для NVI. Самая простая вещь, которая приходит в голову: класс в C # не может реализовывать более одного NVI. Как только вы обнаружите этот неприятный аспект тандема C # / NVI, становится намного проще отказаться от NVI, чем от C #.
И, кстати, о аспектах . Это очень интересная концепция, и ее цель точно такая же, как у NVI, только она пытается взглянуть на «истинную суть» проблемы и, так сказать, решить ее «должным образом». Посмотрите .
Что касается .NET Framework, для этого существует механизм: вводить код, который, так сказать, «ортогонален» основной логике. Я говорю обо всем этом бизнесе MarshalByRef / TransparentProxy, я уверен, что вы о нем слышали. Однако это серьезно влияет на производительность, так что здесь не очень удачно.
Были также многочисленные попытки реализовать ту же концепцию с помощью других методов, от фасадов зданий до грязного бизнеса, упомянутого выше, до пост-обработки MSIL.
Последний подход больше всего подходит вам, поскольку его можно сделать прозрачным (путем включения необходимых шагов в процедуру сборки), он не влияет на производительность (больше, чем абсолютно необходимо для выполнения «ортогонального» "код") и не требует какого-либо "взлома" или обратного проектирования, поскольку MSIL открыт и хорошо документирован.
Здесь можно найти эти пункты, обсуждаемые более подробно, а также дополнительную информацию и ссылки на актуальные инструменты. Также допустимо использование Google для тех же целей. : -)
Удачи.