вот такой код

IList<int> arr = new int[10];
 arr.Add(5);

кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?

Здравствуйте, Аноним, Вы писали:

А>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?

А какова альтернатива?

Здравствуйте, Аноним, Вы писали:

А>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?

«Framework Design Guidelines», глава «9.7 Optional Feature Pattern».

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

A>Здравствуйте, Аноним, Вы писали:

А>>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?

A>А какова альтернатива?

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

Здравствуйте, Аноним, Вы писали:

A>>А какова альтернатива?
А>чтобы у меня были доступны методы которые я могу всегда использовать

И как вы предлагаете это реализовать? IList<> может быть поиницилизирован очень далеко, вообще в другом модуле. С какой стати компилятору запрещать вам вызывать метод?

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

A>Здравствуйте, Аноним, Вы писали:

A>>>А какова альтернатива?
А>>чтобы у меня были доступны методы которые я могу всегда использовать

A>И как вы предлагаете это реализовать? IList<> может быть поиницилизирован очень далеко, вообще в другом модуле. С какой стати компилятору запрещать вам вызывать метод?

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

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

Q>Здравствуйте, Аноним, Вы писали:

А>>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?

Q>«Framework Design Guidelines», глава «9.7 Optional Feature Pattern».

это называется "перекуем баги архитектуры в фитчи"

Здравствуйте, Аноним, Вы писали:

A>>И как вы предлагаете это реализовать? IList<> может быть поиницилизирован очень далеко, вообще в другом модуле. С какой стати компилятору запрещать вам вызывать метод?
А>как реализовать это вопрос другой.

Это основной вопрос. Если вы не можете предложить ничего лучше, то не ругайте то, что есть.

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

A>Здравствуйте, Аноним, Вы писали:

A>>>И как вы предлагаете это реализовать? IList<> может быть поиницилизирован очень далеко, вообще в другом модуле. С какой стати компилятору запрещать вам вызывать метод?
А>>как реализовать это вопрос другой.

A>Это основной вопрос. Если вы не можете предложить ничего лучше, то не ругайте то, что есть.

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

Здравствуйте, Аноним, Вы писали:

А>основной вопрос: зачем показывать то, что мне недоступно для использования?

Простите, у меня впечатление что вы первый день программируете или просто тролль.

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

A>Здравствуйте, Аноним, Вы писали:

А>>основной вопрос: зачем показывать то, что мне недоступно для использования?

A>Простите, у меня впечатление что вы первый день программируете или просто тролль.

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

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

A>Здравствуйте, Аноним, Вы писали:

A>>>И как вы предлагаете это реализовать? IList<> может быть поиницилизирован очень далеко, вообще в другом модуле. С какой стати компилятору запрещать вам вызывать метод?
А>>как реализовать это вопрос другой.

A>Это основной вопрос. Если вы не можете предложить ничего лучше, то не ругайте то, что есть.

Я тоже считаю что в интерфейсах коллекций бардак. Другое дело — я привык к нему. Предлагать ничего не буду, не готов прямо сейчас, да и бестолку это. Но уверен, что можно было сделать лучше.

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

A>>Это основной вопрос. Если вы не можете предложить ничего лучше, то не ругайте то, что есть.
S>Я тоже считаю что в интерфейсах коллекций бардак. Другое дело — я привык к нему. Предлагать ничего не буду, не готов прямо сейчас, да и бестолку это. Но уверен, что можно было сделать лучше.

Без множественного наследования — нельзя.

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

A>Без множественного наследования — нельзя.
И для чего оно тут?

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

Q>Здравствуйте, Аноним, Вы писали:

А>>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?

Q>«Framework Design Guidelines», глава «9.7 Optional Feature Pattern».

Есть рецепт, как можно понять, можно ли вызывать метод IList<T>.Add без получения исключения и даункастинга?

S>Есть рецепт, как можно понять, можно ли вызывать метод IList<T>.Add без получения исключения и даункастинга?

IList<int> arr = new int[10];
if (!arr.IsReadOnly)
{
    arr.Add(5);
}

А>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?

ICollection<T>.Add Method
Adds an item to the ICollection<T>.

Exceptions:
NotSupportedException
The ICollection<T> is read-only.

Контракт общий для readonly и обычных коллекций. Проверяете коллекцию на ReadOnly и определяете, вызывать ли Add

Здравствуйте, Аноним, Вы писали:

А>вот такой код

А>IList<int> arr = new int[10];
А>arr.Add(5);

А>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?

А какая разница — всегда или нет? Вы же вызываете Add у интерфейса и с точки зрения интерфейса вызов Add далеко не "всегда будет кидать эксепшн"
А вот с точки зрения массива у вас метода Add нет.

Если так топорно, "c т.з. пользователя", как вы демонстрируете, рассуждать, то зачем вообще могут быть (имеют ли право на существование?) методы, которые, в зависимости от внутреннего состояния объекта, могут вести себя по разному (например, при некотором состоянии всегда "кидать")? (Заметьте, что нарушением LSP тут и не пахнет, ибо говорим мы не о наследовании, а о реализации интерфейсов.)

Развивая далее: методов a-la

override void M1() {
  throw new NotSupportedException();
}

override void M2() {
  throw new NotImplementedException();
}

быть так же не должно, как вам кажется? Или какие-то оговорки на этот счёт "для пользователя" могут иметь место?

Если вы неквалифицированный "пользователь", то никакого права диктовать, _как_ должно выглядеть то, что сделано [допустим] специалистом, у вас нет. Главное, что бы вы могли решить все заявленные задачи с помощью сделанного. Квалифицированный же "пользователь" не может быть квалифицированным без знания аспектов использования предмета критики. Вы же увидели один частный пример и на основании его делаете вывод о чьих-то ошибках. Вы не квалифицированный пользователь и ваше мнение не может быть интересно.

Что бы заинтересовать, рассуждайте шире. Рассмотрите всевозможные сценарии использования коллекций. Вы увидите, что интерфейсы для readonly-списков и коллекций попросту не нужны. Массивов и ReadOnlyCollection<> часто достаточно. ReadOnlyCollection2<> (без реализации IList/IList<>), ReadOnlySet<>, ReadOnlyDictionary<> и ковариантные классы readonly-коллекций для нового фреймворка могут покрыть все задачи. Заметье, речь тут не об интерфейсах, а о классах, которые вы можете написать самостоятельно и использовать, не имея никаких проблем с тем, что где-то видно больше, чем хотелось бы. Если у вас есть какая-то задача, которую нельзя было бы решить предложенным мною способом, было бы интересно взглянуть. Но подумайте, пожалуйста, хорошенько.

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

А>>>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?
Q>>«Framework Design Guidelines», глава «9.7 Optional Feature Pattern».
S>Есть рецепт, как можно понять, можно ли вызывать метод IList<T>.Add без получения исключения и даункастинга?

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

Здравствуйте, Аноним, Вы писали:

А>это называется "перекуем баги архитектуры в фитчи"

Это способ избавиться от комбинаторного взрыва.