Протесты Linq
Ниже приведен файл pom.xml для справки:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>json_example</groupId>
<artifactId>json_example</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>javax.json</groupId>
<artifactId>javax.json-api</artifactId>
<version>1.1.4</version>
</dependency>
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.json</artifactId>
<version>1.1.4</version>
</dependency>
</dependencies>
</project>
Затем добавьте зависимые от maven файлы jar в путь к классам.
import javax.json.Json;
import javax.json.JsonObject;
import javax.json.JsonReader;
public static void main(String[] args) {
System.out.println("Enter a valid JSON string: ");
try (// Create JsonReader from Json.
JsonReader reader = Json.createReader(System.in)) {
// Get the JsonObject structure from JsonReader.
JsonObject jsonObj = reader.readObject();
System.out.println(jsonObj.toString());
} catch (Exception e) {
e.printStackTrace();
}
}
2 ответа
Создание запроса в цикле foreach
IEnumerable<char> query = "Not what you might expect";
foreach(char vowel in "aeiou")
{
query = query.Where(c => c != vowel);
}
Вышеупомянутый код только удаляет "u" из строки из-за задержанного выполнения.
Для удаления всех гласных, необходимо сделать следующее:
IEnumerable<char> query = "Not what you might expect";
foreach(char vowel in "aeiou")
{
char temp = vowel;
query = query.Where(c => c != temp);
}
Я думаю, что LINQ довольно тверд, и нет большого количества больших протестов. Почти каждой "проблемой", с которой я столкнулся, является результат задержанного выполнения, и это не действительно проблема, а скорее другой образ мыслей.
Самой большой проблемой, с которой я столкнулся - LINQ, является переломный момент (или по крайней мере гибочный станок правила) когда дело доходит до профилирования для производительности. Задержанное выполнение может сделать намного более трудным время от времени представлять приложение и может также существенно изменить рабочие характеристики во время выполнения неожиданными способами. Определенные операции LINQ кажутся почти волшебными с тем, как быстро они, и другие берут намного дольше, чем я ожидал - но это не всегда очевидно из результатов профилировщика или кода.
Однако в целом, задержанное выполнение, больше, чем восполняют случаи, где оно замедлено кодированные рукой стандартные программы. Я очень предпочитаю более простой, более чистый код коду, который он заменил.
Кроме того, я нашел что, чем больше я использую LINQ для Объектов, тем больше я должен заново продумать свой дизайн и переделать мои наборы в целом.
Например, я никогда не понимал, как часто я выставлял IList вместо IEnumerable, когда это не было абсолютно необходимо, пока я не начал использовать linq для объектов часто. Я теперь полностью понимаю, почему руководство по проектированию MS предостерегает от использования IList слишком часто (например, не возвращайте IList только для свойства Count, и т.д.). То, когда у меня были бы методы, которые взяли IList, проходить через IEnumerable следует из запроса linq, требует.ToList () или переделка API метода.
Но это почти всегда стоит пересмотра прежнего мнения - я нашел много мест, где передача счетного и использование LINQ привели к огромным усилениям перфекта. Задержанное выполнение замечательно, если Вы думаете об этом и в полной мере пользуетесь им. Например, использование.Take () для ограничения набора первыми 2 элементами, если это - все, которое это необходимо, было немного более сложным pre-linq и существенно ускорило некоторые мои более противные циклы.