Не очень понял про забить болт на инкапсуляцию. Я всего лишь о том, что internal метод в internal классе имеет такую же область видимости, как public метод в internal классе. И как защита от рефлексии, это использовать бесполезно. То есть, немного докрутив метод FindThroughReflection() из статьи, можно вполне спокойно находить OtherMethod() класса B, будь он хоть internal, хоть public, хоть private.
Не исключаю, что я вас не правильно понял. Тогда, пожалуйста, прокомментируйте вот этот абзац:
Автор класса A решил, что ничего страшного не случится, если метод internal-класса пометить как public, чтобы компилятор не ныл, и чтобы не пришлось городить ещё кода. Интерфейс отмечен, как internal, класс, его реализующий, отмечен как internal, снаружи до метода, помеченного как public, вроде бы никак не добраться.
И тут открывает дверь и тихонько крадётся рефлексия:
На всякий случай, чтобы исключить возможное недопонимание, я не против модификатора internal. Сам его стараюсь применять, по тем же причинам, которые вы указали в начале статьи. Трюк с extension'ом — очень интересно, спасибо. Я имел в виду, что делать метод internal, когда класс и так уже internal, считаю лишним. И не понимаю, в чем не прав автор класса A.
Спасибо, было интересно. Но у меня для вас плохая новость :)
Assembly 1
using System;
namespace TestLibrary
{
internal class TestReflection
{
internal void SomeMethod()
{
// Do something
}
}
}
Assembly 2
using System;
using System.Reflection;
namespace TestInheritance
{
class Program
{
static void Main(string[] args)
{
Assembly assembly = Assembly.LoadFrom("TestLibrary.dll");
Type type = assembly.GetType("TestLibrary.TestReflection");
ConstructorInfo typeCtor = type.GetConstructor(new Type[] { });
MethodInfo someMethod = type.GetMethod("SomeMethod", BindingFlags.Instance | BindingFlags.NonPublic);
object typeObject = typeCtor.Invoke(null);
someMethod.Invoke(typeObject, null);
}
}
}
И тогда internal метод internal класса прекрасно вызовется из другой сборки :)
Так что, делать internal методы в internal классах, мне кажется, излишне. Хотя я могу ошибаться :)
Конечно, самым большим достижением во всем этом фонтане успеха является то, что в космос полетела тяжелая ракета-носитель Falcon Heavy.
Конечно, скорее всего это ошибка выжившего, но по моим ощущениям, на фоне маленького красного автомобиля со скафандром внутри, "самого большого достижения" люди, в большинстве своем, не заметили )
Возможно. Но тогда не объясняет Лондона и Парижа. Скорее, что-то с долготой. Лондон в десятичных градусах: широта 51.5085300°, долгота -0.1257400°. Парижа в десятичных градусах: широта 48.8534100°, долгота 2.3488000°. Долгота у обоих около ноля. Например, если в реализации долгота берется по абсолютному значению, это бы объяснило проблемы с городами с США. Но не объясняет проблемы с городами в РФ, для них для всех долгота и широта положительные.
Согласен. Я не силен в МО, но эксперимент с заявками в колледж, по крайней мере, как автор его описал, выглядит не как эпический фейл, а как не корректное «ТЗ» со стороны экспериментаторов. То есть, при постановке задачи «Нам нужны хорошие студенты. Идеальный студент, это белый молодой человек, из богатой семьи, капитан футбольной команды. Ну и да, оценки, сочинения, вот это все», странно потом удивляться, что машина отобрала мало негров и Гарлема.
Первый раз, да. И это не серебряная пуля, да. Но в некоторых сценариях использования может помочь. Например, если у вас серверное приложение, редко выгружаемое из памяти.
Хотя, конечно, в идеале, хотелось бы, чтоб EF быстрее справлялся с .Include. Те числа, которые вы приводите, это уже за гранью )
Как вариант, дубль два, так сказать, форк ): система не блокирует доступ в, например, метро. Чип "валидный", доступ дается. Сутки или около того, требуются системам Протектория для выявления дубликатов. После чего уже поиски, аресты, и далее по списку.
Упрощенно, запрос на существование записи в таблице быстрее, чем анализ логов. Что критично для того же доступа в метро. Если хотите, критично для UX )
Не вброс, а, скорее, не совсем корректный перевод. Один из переводов cognitive — познавательный. Хотя в данном контексте лучше подошло бы что-то типа «игры для тренировки когнитивных способностей».
Терпение, склонность к риску, скорость принятия решений — все это «черты» мозга. Которые, согласно заверениям создателей, игра и должна тренировать. Ссылка в статье.
Не исключаю, что я вас не правильно понял. Тогда, пожалуйста, прокомментируйте вот этот абзац:
На всякий случай, чтобы исключить возможное недопонимание, я не против модификатора internal. Сам его стараюсь применять, по тем же причинам, которые вы указали в начале статьи. Трюк с extension'ом — очень интересно, спасибо. Я имел в виду, что делать метод internal, когда класс и так уже internal, считаю лишним. И не понимаю, в чем не прав автор класса A.
И тогда internal метод internal класса прекрасно вызовется из другой сборки :)
Так что, делать internal методы в internal классах, мне кажется, излишне. Хотя я могу ошибаться :)
Конечно, скорее всего это ошибка выжившего, но по моим ощущениям, на фоне маленького красного автомобиля со скафандром внутри, "самого большого достижения" люди, в большинстве своем, не заметили )
Хотя, конечно, в идеале, хотелось бы, чтоб EF быстрее справлялся с .Include. Те числа, которые вы приводите, это уже за гранью )
Как вариант, дубль два, так сказать, форк ): система не блокирует доступ в, например, метро. Чип "валидный", доступ дается. Сутки или около того, требуются системам Протектория для выявления дубликатов. После чего уже поиски, аресты, и далее по списку.
Упрощенно, запрос на существование записи в таблице быстрее, чем анализ логов. Что критично для того же доступа в метро. Если хотите, критично для UX )
Вы не правы.