Бобы Java: сверхпрославленные ассоциативные массивы?
Используйте cvs -d/cvsroot checkout -d directory project/path/directory. Первое -d может быть опущено при установке корня со средой. Это называют, "сокращая путь" и можно избежать с -N опция к checkout.
6 ответов
На самом деле, да, здесь творится волшебство.
Это действительно глупый шаблон, но компоненты GUI (которыми являются все компоненты) были предназначены для рефлексивного анализа построителем GUI. Общедоступные поля set / get предназначены для использования в качестве «свойств», которые пользователь может использовать при создании своего графического интерфейса.
Edit: В защиту солнца, я должен сказать, что хотя шаблон оказался довольно неприятным из-за всего люди, которые скопировали его и начали использовать во всем своем коде, отличном от bean. Это позволило людям интегрировать классы с построителем GUI без использования каких-либо внешних метаданных. Вам не нужен был XML-файл или файл свойств для редактора, это было так же просто, как расширить Button и перетащить новый объект на поддон.
Этот образец использовался в других местах, и, как вы заметили, он ' в значительной степени то же самое, что и общедоступные поля. Я думаю, что это один из худших шаблонов, созданных солнцем при настройке java, но других очевидных решений не было (я думаю, что вся концепция была как бы добавлена первыми людьми, пытавшимися создать первые конструкторы GUI до выпуска java).
Теперь есть гораздо лучшее решение: используя аннотации для пометки частных полей, отражающий инструмент все еще может анализировать их и связывать с элементами управления построителя. Это будет намного чище и не сделает все ваши объекты настолько уязвимыми для изменений внешнего состояния.
s release).Теперь существует гораздо лучшее решение: используя аннотации для пометки частных полей, отражающий инструмент все еще может анализировать их и связывать с элементами управления построителя. Это будет намного чище и не сделает все ваши объекты настолько уязвимыми для изменений внешнего состояния.
s release).Теперь существует гораздо лучшее решение: используя аннотации для пометки частных полей, отражающий инструмент все еще может анализировать их и связывать с элементами управления построителя. Это будет намного чище и не сделает все ваши объекты настолько уязвимыми для изменений внешнего состояния.
Java Beans, как вы отметили, довольно тривиальное соглашение о кодировании.
Полезная часть состоит в том, что они вообще были условностью. Это позволяло создавать вспомогательные инструменты, основанные на (в то время) новых идеях, таких как точное указание имен геттеров и сеттеров и ожидание того, что определенные методы будут существовать без необходимости приписывать интерфейс. Это давало достаточно гибкости, чтобы делать все, что вы хотите, но все же позволяло использовать графический интерфейс для сборки bean-компонентов.
На этом этапе, когда полный самоанализ является нормой,
Люди злоупотребляют глупыми геттерами / сеттерами, без сомнения.
Однако представьте, сколько боли вам придется пережить через 2 года, когда вы поймете,
вам нужно удалить пробелы из строки в вашем методе setEmail (string email); , и весь ваш код жестко привязан к использованию общедоступных полей вместо вызова метода.
Помните одно из основных правил объектно-ориентированный дизайн «Код для интерфейса, а не для реализации». Доступ к публичным полям класса, безусловно, является последним и значительно усложнит рефакторинг кода.
Вы не упустили суть. Геттеры / сеттеры уродливы, но они встроены во многие инструменты, которые делают предположения об именах классов / методов / полей (например, spring), что (помимо их очевидного значения для инкапсуляции) они фактически стали почти обязательным требованием, если вы не работает в очень ограниченном и частном контексте.
«геттеры» и «сеттеры» отлично подходят, если вы хотите переопределить доступ к вашим данным, например, для регистрации / безопасности или возврата значения, отличного от исходного класса.
без установщика вы не можете проверить инварианты:
public void setFoo(Foo foo) {
if (foo == null) {
throw new InvalidFoo();
}
this.foo = foo;
}
с общедоступными членами вы не можете этого сделать. Во-вторых, внутри установщика вы можете запускать события, которые могут прослушивать другие bean-компоненты. И последнее, но не менее важное: вы можете обеспечить надлежащую проверку типов (как вы указали в своем вопросе).