Подумав, понял, что конструкторов не достаточно. Нужна фабрика, которая на CreateEllipse с аргументами, дающими равные полуоси, выдаст инстанс класса Circle.
Ну так не надо вводить метод setSize. Можно сделать типы неизменяемыми, как string в .NET. А вместо setSize будем создавать новые инстансы через конструкторы и методы, не изменяющие состояние класса.
Интересно, в каком случае может понадобиться метод setSize, когда создание нового инстанса через конструктор не оправдано. Не приведете пример?
Действительно, не хватает такого пункта. Если человек сам осознает, в чем его код плохой, почему ему должно быть стыдно?
Первое, что пришло в голову, — старый плохой код, который можно было бы написать лучше. =)
Получается продвинутая спецификация исключений, как в Java. =)
В сценарии, описанном вами, придется использовать очень много информации о вызываемом коде. В том числе нужно ввести пометки о том, что методы не меняют состояния объекта между проверками и местами, где может быть выброшено исключение в случае отсутствия этих проверок. Средствами Решарпера нельзя провести настолько глубокий анализ.
Да и такие сценарии весьма конкретны и сравнительно редки. Не то что подстановка в ненулевой параметр метода переменной, которая может внезапно оказаться null'ом.
Никто не будет расставлять атрибуты без вашего ведома. Это ваше право использовать или не использовать атрибуты Решарпера. Но, если вам захочется проаннотировать ими уже имеющийся проект, то почему бы не сделать это автоматически в тех местах, где машина может их вывести. Именно для этой цели разрабатывается упомянутый мной плагин.
Можете описать подробнее, какой лог потенциальных проблем вы хотите получить?
Нет, в текущей реализации алгоритма это сделать невозможно. Но планируется плагин, который даст возможность делать примерно то, что вы описали — запускать на ночь анализ, который расставляет атрибуты NotNull/CanBeNull в проекте автоматически.
Аннотации в XML-файлах нужны только анализатору ReSharper'а. На сборку проекта они никак не влияют. Будет ли у Вас код проаннотирован контрактами или нет, Вы получите сборки, совершенно одинаковые по своей функциональности в рантайме.
То есть, вы можете спокойно скопировать JetBrains.Annotations.dll в папку с проектом/решением или написать реализацию атрибутов в своем проекте. А дальше — MSBuild, NAnt или еще что угодно. Им не нужно знать об аннотациях. =)
Ну скажем, не эллипс сжимается прессом, а объект, имеющий форму эллипса.
Интересно, в каком случае может понадобиться метод setSize, когда создание нового инстанса через конструктор не оправдано. Не приведете пример?
Первое, что пришло в голову, — старый плохой код, который можно было бы написать лучше. =)
В сценарии, описанном вами, придется использовать очень много информации о вызываемом коде. В том числе нужно ввести пометки о том, что методы не меняют состояния объекта между проверками и местами, где может быть выброшено исключение в случае отсутствия этих проверок. Средствами Решарпера нельзя провести настолько глубокий анализ.
Да и такие сценарии весьма конкретны и сравнительно редки. Не то что подстановка в ненулевой параметр метода переменной, которая может внезапно оказаться null'ом.
Можете описать подробнее, какой лог потенциальных проблем вы хотите получить?
То есть, вы можете спокойно скопировать JetBrains.Annotations.dll в папку с проектом/решением или написать реализацию атрибутов в своем проекте. А дальше — MSBuild, NAnt или еще что угодно. Им не нужно знать об аннотациях. =)
Надеюсь, я правильно понял Ваш вопрос.
если я не ослышался, диктор его называла Икарусом.