Еще один интересный вопрос со StackOverflow. Это место просто кладезь с темами для статей. Рассмотрим следующий пример:

class B
{
  public int X() { return 123; }
}
class D : B
{
  new protected int X() { return 456; }
}
class E : D
{
  public int Y() { return X(); } // возвратит 456
}
class P
{
  public static void Main()
  {
     D d = new D();
     Console.WriteLine(d.X());
  }
}

Существует два возможных сценария. Мы можем рассматривать X как B.X и компилировать этот код успешно, либо мы можем рассматривать X, как D.X и выдать ошибку «вы не можете обратиться к защищенному методу класса D из класса Program».

[Дополнение: По просьбе, которая прозвучала в комментариях, я более подробно объясню эту часть. Спасибо за отличные вопросы.]

Мы поступаем первым способом. Для вычисления набора возможных методов при поиске имен спецификация говорит следующее: «набор состоит из всех доступных членов с именем N в T, включая унаследованные члены». Но D.X недоступен снаружи класса D, поскольку является защищенным членом. Поэтому D.X не включается в этот набор.

Затем в спецификации сказано: «члены, скрытые другими членами удаляются из этого набора». Скрывается ли B.X чем-либо? Кажется, что он D.X его скрывает. Давайте проверим. В спецификации сказано «Объявление нового члена скрывает унаследованный член только в области видимости нового члена». Объявление D.X скрывает B.X внутри своей области видимости: в теле класса D и его наследниках. Поскольку P не является ни тем, ни другим, D.X не скрывает B.X, поэтому B.X является видимым и именно он будет выбран алгоритмом разрешения.

Внутри E, D.X является доступным и скрывает B.X, поэтому D.X включается в набор для перегрузки, а B.X – нет.

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

Нет, не противоречит. Нужно помнить о том, что это правило призвано смягчить проблему хрупких базовых классов (brittle base class problem). Что оно и делает! Давайте рассмотрим следующий сценарий:

FooCorp создает Foo.DLL:

public class Foo
{ 
читать далее...



						

С 1 января 2011г. в полном объеме вступает в действие федеральный закон № 152-ФЗ «О персональных данных», в соответствии с которым к информационным системам, содержащим и обрабатывающим персональные данные (ИСПДн), предъявляются специальные технические и административные требования.

Parking.ru обладает всеми необходимыми необходимыми лицензиями ФСТЭК России и ФСБ России (ФСТЭК № 0280 от 22.11.04; ФСБ №3084X от 11.04.06, №3086У от 11.04.06, №3083 П от 11.04.06), техническими и организационными возможностями для размещения ИСПДн клиентов (операторов персональный данных) классов от 4 до 2 включительно (про размещение систем 1 класса см. в соответствующем подразделе).

Подробнее на сайте parking.ru

На сайте StackOverflow прозвучал еще один интересный вопрос. Представляю его в виде диалога:

В спецификации сказано «хотя константы являются статическими членами, при объявлении модификатор static не требуется и является недопустимым». Почему не принято решение обязать использование модификатора static для констант, раз они и так являются статическими?

Давайте согласимся с тем, что вполне разумно, что константы являются «статическими», поскольку они связаны с самим типом, а не с членами определенного экземпляра. Давайте также согласимся с тем, что без «const» тоже не обойтись. Итак, у нас остается три возможных варианта объявления константы:

1) Сделать модификатор static опциональным: выражения "const int x..." или "static const int x..." оба являются корректными.

2) Сделать модификатор static обязательным: выражение “const int x…” – некорректно, “static const int x…” – корректно.

3) Сделать модификатор static недопустимым: выражение “const int x…” – корректно, выражение “static const x…” – некорректно.

Согласны?

Да. Но почему команда разработчиков языка выбрала вариант (3), а не вариант (1) или (2)?

Об этом ничего не говорится в проектных записях за 1999 год. Но мы можем предположить, что скорее всего творилась в головах проектировщиков языка.

Проблема с вариантом (1) заключается в том, что вы сможете встретить код, который использует оба варианта, и “const int x…” и “static const int y…”, и вы будете, естественно, спрашивать себя «а в чем разница?» А поскольку по умолчанию неконстантные поля и методы являются «экземплярными», а не «статическими», вы сделаете естественный вывод, что некоторые константы относятся к экземпляру, а некоторые – к типу, и этот вывод будет совершенно неверным. Этот вариант является плохим, поскольку он может вводить в заблуждение.

Проблема с вариантом (2) прежде всего, связана с избыточностью. Вам приходится больше набирать, не добавляя при этом ясности или выразительности языка. Кроме того, я не знаю насчет вас, но лично меня просто бесит, когда компилятор выдает мне ошибку «Ты забыл мне сказать волшебное слово. Я знаю об этом, и я совершенно спокойно могу узнать это слово самостоятельно, какое слово требуется в этом случае, но я ничего не буду делать, пока ты не скажешь мне это волшебное слово сам».

Проблема с вариантом (3) состоит в том, что разработчику нужно знать о том, что константность логически подразумевает отношение к типу, а не экземпляру. Однако, как только разработчик выяснит этот факт, проблема исчезнет. Это не такая уж и запутанная идея, которую невероятно сложно понять.

Решение, которое является наиболее дешевым и влечет за собой минимальное количество проблем для конечного пользователя это (3).

Звучит разумно. В языке C# этот прин...

Всего лишь короткая заметка о том, что Мэдс, Люк и я собираемся выступить на Channel 9 Live с TechEd вечером 8 июня и будем говорить о C#, F# и чем угодно другом, что взбредет в наши головы. Это живое видео, так что случиться может все, что угодно. Смотрите его на www.msteched.com; мы будем выступать в 15:30 по центральному времени. (По этому поводу возникли вопросы. Центральное летнее время (Central Daylight Time) – это не Восточное (Eastern), Горное (Mountain) или Тихоокеанское (Pacific) время.)

И, кстати, проверьте этот сайт, там уже должна быть уйма всего интересного.

Дополнение: Видео можно найти в архиве –http://channel9.msdn.com/Live/TechEd2010/NA/Day2/

Промотайте запись вперед на 4 часа 25 минут.

Оригинал статьи