Используя статического участника класса на производном типе?
Следуйте рисунку, чтобы решить эту проблему:
Ctrl + Shift + J
[/g0]
4 ответа
Одно место, где это могло бы вводить в заблуждение, - когда помехи являются методом фабрики, например, WebRequest, класс имеет метод фабрики Create, который позволил бы этому типу кода быть записанным, если получено доступ через производный класс.
var request = (FtpWebRequest)HttpWebRequest.Create("ftp://ftp.example.com");
Здесь request имеет тип FtpWebRequest, но это сбивает с толку, потому что похоже, что это было создано из HttpWebRequest (одноуровневый класс) даже при том, что Create метод на самом деле определяется на WebRequest (базовый класс). Следующий код идентичен в значении, но более ясен:
var request = (FtpWebRequest)WebRequest.Create("ftp://ftp.example.com");
В конечном счете нет никакой основной проблемы, получающей доступ к помехам через производный тип, но код часто более ясен, не делая так.
Это не предупреждение, обычно, просто предложение. Вы создаете зависимость от чего-то излишне.
предположим Вы позже решаете, что B не должен наследовать A. Если Вы последуете совету Resharper, то Вы не должны будете изменять ту строку кода.
B.SomethingStatic() делает оператор, который SomethingStatic является членом B лет. Это не верно. SomethingStatic недвусмысленно член A лет. То, что это доступно дисквалифицированный членам B (как будто это был член B лет) является вопросом удобства. То, что это доступно при квалификации с B, IMO, ошибка.
Да я видел это также, я всегда предполагал, что это просто предупреждало меня, потому что это было ненужным. A.SomethingStatic(); сделал бы то же самое.