Альтернативы XAML
Многие объяснения уже присутствуют, чтобы объяснить, как это происходит и как это исправить, но вы также должны следовать рекомендациям, чтобы избежать NullPointerException вообще.
См. также: A хороший список лучших практик
Я бы добавил, очень важно, хорошо использовать модификатор final. Использование "окончательной" модификатор, когда это применимо в Java
Сводка:
- Используйте модификатор
finalдля обеспечения хорошей инициализации. - Избегайте возврата null в методы, например, при возврате пустых коллекций.
- Использовать аннотации
@NotNullи@Nullable - Быстрое завершение работы и использование утверждений, чтобы избежать распространения нулевых объектов через все приложение, когда они не должен быть пустым.
- Сначала используйте значения с известным объектом:
if("knownObject".equals(unknownObject) - Предпочитают
valueOf()поверх toString (). - Используйте null safe
StringUtilsStringUtils.isEmpty(null).
5 ответов
Существуют альтернативы:
XUL, Flash, синтаксис ресурсов Delphi, синтаксис C # Form.Designer.cs, синтаксис формы VB6
Конечно, нет убедительных есть альтернативы.
Это похоже на человеческие тела - сплошной мусор со всеми его соками и запахами, но это, безусловно, лучшая из известных форм жизни. XAML явно действительно очень плох, но нет ничего и вполовину лучше.
Одна альтернатива - вообще не создавать пользовательский интерфейс, а поручить это дизайнеру в Blend.
Это может быть что посмотреть. Однако с веб-сайта пока нет ничего для загрузки.
D'oh: Супер производительный язык графического интерфейса Windows
XAML действительно кажется слоном в комнате. Хотя я большой поклонник WPF, многословность XAML может быть немного сложной для глаз. Хотя Blend и VS2010 значительно уменьшили потребность в кодировании XAML с нуля, я все еще считаю, что редактирование вручную необходимо почти во всем, что я делаю.
Я считаю, что power boot легки для глаз, а CSS подобный синтаксису JavaFX весьма привлекателен. Это кажется вдохновением для D'oh.
Каким бы многословным ни был XAML, по крайней мере, есть инструментальная поддержка, позволяющая пройти 90% пути, любая другая альтернатива вернет нас к ручному кодированию всего пользовательского интерфейса. Не очень привлекательное предложение для этого кодировщика.
Теперь я знаю, почему ваш значок выглядел знакомым в последний День инноваций.
Это было бы много работы, но вы могли бы начать с малого - нет причин, по которым вам нужно используйте XAML, просто нужно что-то, создающее частичные классы.
Итак, вы могли бы написать DSL, заменяя XAML чем-то, что было законным C #, или пойти на все и написать инструмент VS, который генерирует C # так же, как это делает процессор XAML . Это зависит от того, сколько вы хотите, чтобы файл с выделенным кодом был доступен во время компиляции.
Хммм, с IronRuby, возможно, DSL в IronRuby
(DSL = Domain Specific Language для всех, кто читает, кто испытывает трудности с аббревиатурой).