А почему API социальных сетей вынесено отдельным пунктом? Чем отличается от web api?
В России очень хорошо развиты компании работающие в ФинТех, соответственно, когда мы говорим об API, то традиционно подразумеваем микросервисные API, а особенно протоколы REST и SOAP.
Откуда такой вывод вдруг?
Отсутствие строгой спецификации может привести к разнообразию реализаций и сложностям в согласованности интерфейсов.
REST API обладают унифицированным интерфейсом, что означает, что клиенты и серверы могут взаимодействовать между собой, следуя общим правилам, без необходимости знания подробностей реализации.
Так просто или сложно все таки? И почему вдруг REST делает необязательнымт знания о внутреннем устройстве? Кажется любой api (нормальный) как раз делает знания необязательными, т.к. предоставляет интерфейс
Сделайте мне бота, который будет по фамилии и городу предоставлять ник пользователей в телеграм
При этом метод называется search_relatives. Кажется в REST стиле было бы что то типа nicknames/search например. Непонятно при чем тут relatives вообще
Кажется такое имело бы смысл, если бы метод расширения GetDefaultSchema (а это вроде extension метод), принимал бы на вход nullable тип и имел какую то ветку выполнения для случая, когда this равно null.
Дело в том, что 'семантическая валидация JSON' - это лишь часть задачи.
На деле могут происходить изменения, которые в моменте дёшево проверить не получится. Например, внешняя система добавила документ, а дальше по процессу выяснится, что документ уже недействительный и нужно выяснить, в какой момент и кто его добавил. Или был добавлен контакт, который почти полностью дублирует существующий. Если выяснится, что это действительно мусорный контакт-дубликат, а не полный тёзка с другой датой рождения, то нужно искать источник некорректных данных. Или внешняя система по ошибке удалила что то. Тут уж никак не проверишь.
В целом, кейсы могут быть очень разными, и, к тому же, сама структура периодически дополняется, и не все данные, присутствующие в JSON, мы используем у себя: часть мы просто пересылаем как есть и можем не знать про какую то логику, применимую к ним.
Из-за использования сахара получается то, о чем я (да и вы, в общем-то) сказал - выглядящий совершенно нормально код содержит в себе проблему
Но ведь и без сахара код выглядит совершенно нормально
Признаться, я не очень понимаю, к чему вы ведете
К тому, что, очевидно, нужно знать, что делает та или иная конструкция в языке, будь то сахар или нет.
А вся история автора выглядит очень странно, начиная от отсутствия подсказок IDE и заканчивая
Всё началось с того момента, когда в нашем проекте начали "выстреливать" ошибки NRE.
Очевидно, что код из статьи начал бы сыпаться при первом же запуске, а не неожиданно начал выстреливать где то. Либо автор чего то недоговаривает, либо намеренно упростил код и там вокруг ещё куча не очень хорошего кода. Такой код должны были обнаружить сначала при разработке, потом на ревью, а потом и при тестировании (я всё таки предполагаю, что 'в нашем проекте начали "выстреливать" ошибки NRE' - это где то на проде или на тестовом контуре, а не при локальной разработке).
Собственно, я и веду к тому, что автор на очень неудачном примере пытается показать, что сахар плохой. А плохой тут не сахар, а код, вот и всё.
По поводу ограничения сахара - мне кажется тут всё таки решается всё культурой разработки в первую очередь.
var result = new ExampleClass
{
ExString = "Тут не должно быть взрыва",
ExList = { 0, 1 },
ExString2 = "И тут",
ExInt = 24
};
Смотрите, автор указал такой код.
Если я напишу без сахара, типа как
var result = new ExampleClass();
result.ExList.Add(0);
result.ExList.Add(1);
То он так же развалится, тут не в сахаре дело.
Плюс эта ошибка всегда подсвечивается IDE, о чём автору сообщили в самых первых комментариях (не знаю, в чём он код пишет), а если ещё и настроить всё правильно, то можно даже ошибку компиляции получить.
Иными словами, вероятность того, что среднее значение выборки X̅ₙ находящееся на любом расстоянии от ожидаемого значения μ, сходится к нулю с увеличением количества выборок (n). (Подробнее мы рассмотрим это ниже.)
Что то я не смог распарсить это предложение.
Вероятность того, что ... значение ... сходится к нулю.
public class HeroesOfMightAndMagic3
{
public void Play()
{
Console.WriteLine("Запускаем классическую версию игры...");
}
}
public class HeroesOfMightAndMagic3Hd : HeroesOfMightAndMagic3
{
public void Play()
{
Console.WriteLine("Запускаем игру в высоком разрешении (HD)...");
}
}
public class HeroesOfMightAndMagic3Hota : HeroesOfMightAndMagic3
{
public void Play()
{
Console.WriteLine("Запускаем игру с двумя новыми городами...");
}
}
Это плохой пример наследования, т.к. вы не переопределили методы в наследниках, а скрыли базовые методы.
На самом деле вся 'статья' крайне низкого качества
У нас есть методы для зарядки и показа текущего значения, однако мы не даем доступ к самой переменной _batteryLife, поэтому, например, пользователи класса не смогут убавить значение нашей переменной
// Метод заряжает батарею, но не имеет доступа к уровню заряда
public void Charge(int amount)
{
_batteryLife += amount;
}
Пока пользователь не передаст отрицательное значение в метод Charge
В этом примере инкапсулирован, то есть спрятан от доступа извне класса, список наших избранных песен (_favoriteSongs). Мы предоставляем методы для управления списком, но не даем возможности работать со списком напрямую.
public List<string> GetFavorites()
{
return _favoriteSongs;
}
Вы возвращаете наружу мутабельный тип List<string>, который без проблем можно изменить
А почему API социальных сетей вынесено отдельным пунктом? Чем отличается от web api?
Откуда такой вывод вдруг?
Так просто или сложно все таки? И почему вдруг REST делает необязательнымт знания о внутреннем устройстве? Кажется любой api (нормальный) как раз делает знания необязательными, т.к. предоставляет интерфейс
При этом метод называется search_relatives. Кажется в REST стиле было бы что то типа nicknames/search например. Непонятно при чем тут relatives вообще
Как вообще что то может "превысить в геометрической прогрессии"? :)
Ваша правда, не учёл, как именно работает ?.
Просто возникла идея, что когда то там могло быть model.GetDefaultSchema() с обработкой null внутри, пока не появились NRT :)
. Сорян, ошибся
Кажется такое имело бы смысл, если бы метод расширения GetDefaultSchema (а это вроде extension метод), принимал бы на вход nullable тип и имел какую то ветку выполнения для случая, когда this равно null.
Тогда было бы логично всё)
... в месяц
Дело в том, что 'семантическая валидация JSON' - это лишь часть задачи.
На деле могут происходить изменения, которые в моменте дёшево проверить не получится. Например, внешняя система добавила документ, а дальше по процессу выяснится, что документ уже недействительный и нужно выяснить, в какой момент и кто его добавил. Или был добавлен контакт, который почти полностью дублирует существующий. Если выяснится, что это действительно мусорный контакт-дубликат, а не полный тёзка с другой датой рождения, то нужно искать источник некорректных данных. Или внешняя система по ошибке удалила что то. Тут уж никак не проверишь.
В целом, кейсы могут быть очень разными, и, к тому же, сама структура периодически дополняется, и не все данные, присутствующие в JSON, мы используем у себя: часть мы просто пересылаем как есть и можем не знать про какую то логику, применимую к ним.
Кажется, для опросов есть более подходящие профильные ресурсы :)
Очень плохой перевод, если честно.
На js вполне можно делить на ноль)
Кажется, это был сарказм :)
Кажется, было бы хорошо в самом начале дать определение, что такое CTF)
Но ведь и без сахара код выглядит совершенно нормально
К тому, что, очевидно, нужно знать, что делает та или иная конструкция в языке, будь то сахар или нет.
А вся история автора выглядит очень странно, начиная от отсутствия подсказок IDE и заканчивая
Очевидно, что код из статьи начал бы сыпаться при первом же запуске, а не неожиданно начал выстреливать где то. Либо автор чего то недоговаривает, либо намеренно упростил код и там вокруг ещё куча не очень хорошего кода. Такой код должны были обнаружить сначала при разработке, потом на ревью, а потом и при тестировании (я всё таки предполагаю, что 'в нашем проекте начали "выстреливать" ошибки NRE' - это где то на проде или на тестовом контуре, а не при локальной разработке).
Собственно, я и веду к тому, что автор на очень неудачном примере пытается показать, что сахар плохой. А плохой тут не сахар, а код, вот и всё.
По поводу ограничения сахара - мне кажется тут всё таки решается всё культурой разработки в первую очередь.
Смотрите, автор указал такой код.
Если я напишу без сахара, типа как
То он так же развалится, тут не в сахаре дело.
Плюс эта ошибка всегда подсвечивается IDE, о чём автору сообщили в самых первых комментариях (не знаю, в чём он код пишет), а если ещё и настроить всё правильно, то можно даже ошибку компиляции получить.
Имхо, во всех примерах проблема не с сахаром, а с кодом
Вы не сделали лучше на самом деле.
Вы либо вообще не принимайте отрицательные числа, либо как то ошибкой реагируйте на них.
Не нужно просто игнорить их
И почитайте про ReadOnly коллекции например, сейчас не особо лучше стало
У вас, кстати, остался ещё один пример с точно такой же ошибкой с возвратом мутабелтной коллекции
Что то я не смог распарсить это предложение.
Вероятность того, что ... значение ... сходится к нулю.
Можете расшифровать?
Это плохой пример наследования, т.к. вы не переопределили методы в наследниках, а скрыли базовые методы.
На самом деле вся 'статья' крайне низкого качества
Пока пользователь не передаст отрицательное значение в метод Charge
Вы возвращаете наружу мутабельный тип List<string>, который без проблем можно изменить
Это не авторизация, авторизация - это ограничение доступа