Когда блокировка типов является хорошей идеей? - PullRequest
Новая
       46

Когда блокировка типов является хорошей идеей?

2 голосов
/ 21 ноября 2011

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

Ответы [ 3 ]

4 голосов
/ 21 ноября 2011

Это почти всегда плохая идея:

  • Любой может заблокировать типы из любого места кода, поэтому у вас нет возможности быть уверенным, что вы не получите тупик, не просмотрев весь код.
  • Блокировка для типа может даже вызвать взаимные блокировки между доменами приложений. См. Статью Джо Даффи: Не блокируйте маршал за кровотечением.

Это разрешено, потому что практически нет ограничений на то, что вы можете использовать в качестве объекта блокировки. Другими словами, это не было специально разрешено - просто в коде .NET отсутствует код, который запрещает его.

Книга "Отладка приложений Microsoft .NET" содержит исходный код правила FxCop DoNotLockOnTypes, которое предупреждает вас, если вы пытаетесь это сделать. ( спасибо Кристиану. K )

2 голосов
/ 21 ноября 2011

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

Это разрешено, потому что разработчики языка / фреймворка решили иметь возможность блокировать все, что происходит от System.Object. Никто не может предотвратить это, потому что System.Type происходит от System.Object (как и любой другой тип .NET).

Возьмите эту подпись: 

void Foo(object o)

Как компилятор может принудительно установить, что o не System.Type? Конечно, вы можете проверить это во время выполнения, но это повлияет на производительность.

И, конечно, могут быть супер-экзотические ситуации, когда может потребоваться заблокировать тип. Может быть, CLR делает это внутренне.

2 голосов
/ 21 ноября 2011

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

Некоторые примеры:

  1. Хейлсберг хотел (Оригинальная статья: A-Z языков программирования: C # - Computerworld ), он добавил ненулевые ссылки на классы в C #. (Хотелось бы, чтобы он также откусил проблему с константой.)
  2. Комитет C ++ облажался с valarray и экспортировал, среди множества других мелких и крупных сожалений.
  3. Шаблоны Java представляли собой неуклюжую работу (OMG, type elision!), Предназначенную для того, чтобы избежать изменения виртуальной машины, и к тому моменту, когда они поняли, что виртуальная машина должна была измениться, было слишком поздно, чтобы сделать необходимые переделки.
  4. Правила области видимости Python являются постоянным раздражителем, так как многочисленные попытки улучшить его не очень помогли (немного, но не сильно).
...