С названием темы непонятно как точно назвать, но смысл относительно простой.
В разных языках существуют различные ограничения при определении интерфейса.
Например, в VB.NET можно определять дополнительные типы как события, делегаты и енумы, а в C# нет.
Чем руководствовались разработчики принимая то или иное решение?
Если рассматривать некие абстрактные ситуации, то можно еще что то придумать.

Но вот не могу сообразить какие негативные последствия можно ожидать от "монолитной проги" на VB.NET использующую в интерефейсах события, делегаты и енумы.
Хотелось бы найти весомые аргументы отчего это лучше не делать.

Здравствуйте, AlexNek, Вы писали:

AN>С названием темы непонятно как точно назвать, но смысл относительно простой.
AN>В разных языках существуют различные ограничения при определении интерфейса.
AN>Например, в VB.NET можно определять дополнительные типы как события, делегаты и енумы, а в C# нет.

Покажите пожалуйста пример кода — что вы имеете в виду? А то недостаток практики на ВБ.НЕТ мешает понять.

Здравствуйте, AlexNek, Вы писали:

AN>Чем руководствовались разработчики принимая то или иное решение?
AN>Если рассматривать некие абстрактные ситуации, то можно еще что то придумать.

Если вас интересуют конкретные вопросы по дизайну языка под дотнет — см волшебные абреввиатуры CTS и CLS, а конкретно — ECMA-335.

Если вопрос про разработку в общем, то есть два основных подхода, solution-driven и problem-drven.

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

У такого подхода есть куча недостатков, особенно если решение сформулировано неправильно/не полностью, но тем не менее знать о нём стоит. Особенно удобен такой подход, когда нужно быстро набросать прототип кода: пишем скелет в виде цепочки вызовов, как будет понятно, что решение более-менее рабочее — дополняем реализацией.


Второй заточен на написание публичного API и всегда основан на трёх китах: доскональном знании языка, реальных сценариях использования и официальных рекомендациях по дизайну API. Для дотнета это, разумеется, FDG, для всего остального , не интересовался.


P.S. Я бы переползал с VB.Net всеми силами. Язык мало того что полуживой, так ещё и не все команды хотят его поддерживать. Самый шикарный взбрык был от ASP.Net team, со временем и остальные подтянутся, думаю.

Здравствуйте, xy012111, Вы писали:

X>Здравствуйте, AlexNek, Вы писали:

AN>>С названием темы непонятно как точно назвать, но смысл относительно простой.
AN>>В разных языках существуют различные ограничения при определении интерфейса.
AN>>Например, в VB.NET можно определять дополнительные типы как события, делегаты и енумы, а в C# нет.

X>Покажите пожалуйста пример кода — что вы имеете в виду? А то недостаток практики на ВБ.НЕТ мешает понять.
ну есть где- такой код на VB

interface ISample
{
  enum Days {Sat=1, Sun, Mon, Tue, Wed, Thu, Fri};

  delegate void SampleEventHandler(object sender, SampleEventArgs e);

  event SampleEventHandler SampleEvent;

  Days GetDays {get;}
}

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, AlexNek, Вы писали:

AN>>Чем руководствовались разработчики принимая то или иное решение?
AN>>Если рассматривать некие абстрактные ситуации, то можно еще что то придумать.

S>Если вас интересуют конкретные вопросы по дизайну языка под дотнет — см волшебные абреввиатуры CTS и CLS, а конкретно — ECMA-335.

S>Если вопрос про разработку в общем, то есть два основных подхода, solution-driven и problem-drven.
ни то, ни другое.
Отчего дизайнеры/архитектор с# избрали именно такой подход?

S>P.S. Я бы переползал с VB.Net всеми силами. Язык мало того что полуживой, так ещё и не все команды хотят его поддерживать. Самый шикарный взбрык был от ASP.Net team, со временем и остальные подтянутся, думаю.
Меня можно не уговаривать. Просто на фирме Х лет писали только на VB и певести это все без ошибок на шарп не представляется возможным.
И поддерживать не хочется, так что будет еще камушек для VB

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, xy012111, Вы писали:

X>>Здравствуйте, AlexNek, Вы писали:

AN>>>С названием темы непонятно как точно назвать, но смысл относительно простой.
AN>>>В разных языках существуют различные ограничения при определении интерфейса.
AN>>>Например, в VB.NET можно определять дополнительные типы как события, делегаты и енумы, а в C# нет.

X>>Покажите пожалуйста пример кода — что вы имеете в виду? А то недостаток практики на ВБ.НЕТ мешает понять.
AN>ну есть где- такой код на VB
AN>

AN>interface ISample
AN>{
AN>  enum Days {Sat=1, Sun, Mon, Tue, Wed, Thu, Fri};

AN>  delegate void SampleEventHandler(object sender, SampleEventArgs e);

AN>  event SampleEventHandler SampleEvent;

AN>  Days GetDays {get;}
AN>}
AN>

Ну, эвенты в C# можно в интерфейсы помещать:

    public interface IEvented
    {
        event EventHandler SampleEvent;
    }

С другой стороны, делегаты и энумы — это определения типов используемых в интерфейсе, а не самого интерфейса.

Зачем определения типов помещать внутрь интерфейса (добавлять дополнительный уровень вложенности), если их можно определить рядом, в том же файле?
Так что, имхо, вполне логичное ограничение, по Оккаме

Почему в VB так разрешено — не знаю, возможно по историческим причинам.

Здравствуйте, AlexNek, Вы писали:

AN>Отчего дизайнеры/архитектор с# избрали именно такой подход?
Подход к чему? К дизайну языка, к API, к взаимодействию с другими языками?

Если коротко: была проведена огромная исследовательская работа, на удивление удачная, если учитывать результат.

Если подробно — начните с ответа на "что конкретно вы хотите услышать?". Тема конечно большая, но никакого практического интереса тут я пока не вижу

Здравствуйте, AlexNek, Вы писали:

AN>>>С названием темы непонятно как точно назвать, но смысл относительно простой.
AN>>>В разных языках существуют различные ограничения при определении интерфейса.
AN>>>Например, в VB.NET можно определять дополнительные типы как события, делегаты и енумы, а в C# нет.

X>>Покажите пожалуйста пример кода — что вы имеете в виду? А то недостаток практики на ВБ.НЕТ мешает понять.
AN>ну есть где- такой код на VB

Спасибо! Если из шарпа можно с этим работать — то никаких проблем, если вам так кажется правильнее. Если не знаете, правильно ли вам кажется — посмотрите общие рекомендации по использованию nested types во фреймворке.

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

Ещё один формальный критерий на подобное — это обеспечить своим кодом CLS-Compliant. Практика на самом деле уже давно сомнительная, но какой-то формальный критерий даст.

Здравствуйте, SDiez, Вы писали:

SD>Зачем определения типов помещать внутрь интерфейса (добавлять дополнительный уровень вложенности), если их можно определить рядом, в том же файле?
SD>Так что, имхо, вполне логичное ограничение, по Оккаме

Если enum или делегат кроме интерфейса нигде не используется, что ему список IntelliSence лишний раз замусоривать. Тоже логичная причина.

Здравствуйте, alexzz, Вы писали:

A>Здравствуйте, SDiez, Вы писали:

SD>>Зачем определения типов помещать внутрь интерфейса (добавлять дополнительный уровень вложенности), если их можно определить рядом, в том же файле?
SD>>Так что, имхо, вполне логичное ограничение, по Оккаме

A>Если enum или делегат кроме интерфейса нигде не используется, что ему список IntelliSence лишний раз замусоривать. Тоже логичная причина.

Это для классов логично, и для их приватных типов.

А в случае с интерфейсами — все эти типы обязательно будут использоваться во внешнем коде, в этом смысл интерфейсов

Здравствуйте, SDiez, Вы писали:

A>>Если enum или делегат кроме интерфейса нигде не используется, что ему список IntelliSense лишний раз замусоривать. Тоже логичная причина.
SD>Это для классов логично, и для их приватных типов.
SD>А в случае с интерфейсами — все эти типы обязательно будут использоваться во внешнем коде, в этом смысл интерфейсов

Ну да, использоваться в контексте использования конкретно этого интерфейса и нигде больше. К примеру, когда я набираю на клавиатуре string, мне удивительно видеть во всплывающем списке enum StringSplitOptions, который не используется нигде, кроме метода Split типа string. Был бы он внутри System.String, даже печатать не пришлось бы больше: StringSplitOptions vs String.SplitOptions.