Почему внутренний защищенный не более строгий, чем внутренний?
попробуйте это
Intent intent = new Intent(android.content.Intent.ACTION_VIEW, Uri.parse("http://maps.google.com/maps?saddr="+src_lat+","+src_ltg+"&daddr="+des_lat+","+des_ltg));
intent.setClassName("com.google.android.apps.maps", "com.google.android.maps.MapsActivity");
startActivity(intent);
7 ответов
Он эффективно защищен или внутренний , а не и . Он доступен и производным классам и типам в одной сборке. Распространенное заблуждение - думать, что защищенный внутренний означает доступный только производным классам в той же сборке.
На уровне .NET существует два похожих, но разных уровня доступа:
- FamilyAndAssembly: более строгий, чем защищенный или внутренний
- FamilyOrAssembly: менее строгий, чем защищенный или внутренний
«защищенный внутренний» в C # означает FamilyOrAssembly; для FamilyAndAssembly нет модификатора.
Итак, ваш защищенный внутренний сеттер менее строг, чем общее свойство внутреннее . Что вы можете сделать:
protected internal bool IP { internal get; set; }
Но тогда ваш сеттер менее ограничен, чем ваш геттер, что нечетно ...
Другая (несколько эквивалентная) альтернатива:
internal bool IP { get; set; }
protected void SetIP(bool ip)
{
this.IP = ip;
}
защищенный внутренний менее строгий, чем защищенный или внутренний , потому что он позволяет использовать оба своих подкласса ( защищенный ) и что-либо в той же сборке ( внутреннее ) для доступа к чему-либо.
защищенные внутренние средства, видимые классам в той же сборке или классам, производным от содержащего класса - другими словами, они видны тем, кто соответствует внутренним требованиям ИЛИ защищенным требованиям, а не И. Здесь нет модификатора доступа, означающего «защищенный И внутренний».
Я бы подумал об этом мошенничестве, так как Эрик Липперт сам является членом SO, но он написал отличное сообщение в блоге, в котором рассматривается эта проблема.
Почему я не могу получить доступ к защищенному члену из A Производный класс, часть третья
В конечном счете, его ответ во многом такой же, как и на плакатах здесь, но он приводит некоторые интересные доводы в пользу дизайна языка и реализации этих функций.
защищенный внутренний означает защищенный ИЛИ внутренний, незащищенный и внутренний. Таким образом, область видимости ограничена одной и той же сборкой ИЛИ производными классами, не обязательно обоими.
модификатор доступности должен быть более строгим, чем свойство
Internal является более ограничительным, чем защищенное: потому что защищенные объекты могут быть видны (подклассами) вне сборки.
Компилятор говорит что нет смысла говорить, что набор защищен (т.е. виден подклассам за пределами сборки), когда все свойство IP является внутренним (т.е. невидимым вне сборки).