Обсуждение:JavaBeans

Термины неспециалиста

Какой, черт возьми, дилетант знает, что такое POJO, сериализуемость, конструкторы и методы getter/setter? Я думаю, формулировку можно улучшить. — Предыдущий неподписанный комментарий добавлен 128.146.248.165 (обсуждение) 15:37, 19 февраля 2009 (UTC) [ ответить ]

Что это за дилетант, который ищет такую ​​статью и не знает хотя бы, что такое конструктор? 72.227.165.191 (обсуждение) 04:09, 13 января 2010 (UTC) [ ответить ]

Я только начинаю изучать Java и установил NetBeans 7 и не знаю, что такое конструктор. Зачем это знать неспециалисту? В руководствах (с сайта NetBean.org) я встречаю утверждения, в которых говорится «поместите код xxx после конструктора», но не показывается код конструктора, чтобы я знал, где это. 24.23.254.32 (обсуждение) 03:31, 12 ноября 2011 (UTC) [ ответить ]

В статье не говорится, что такое Bean , а это главное, что должна делать статья энциклопедии. Я знаком с объектами и даже с конструкторами, но перечисление свойств — это не то же самое, что определение. Если абстрактное определение становится слишком сложным, может быть полезно привести (базовый) пример использования bean. Rbakels ( talk ) 08:19, 18 мая 2019 (UTC) [ ответить ]

Я думаю, что связь с COM , которая гипотетически оправдывает ссылку на статью, должна быть явной. Я считаю, что ссылка на компонентную программную инженерию была бы более уместной. -- Гийом ( обсуждение ) 12:32, 18 января 2008 (UTC) [ ответить ]

Согласен 24.23.254.32 (обсуждение) 03:17, 12 ноября 2011 (UTC) [ ответить ]

Третья ссылка (Обзор Enterprise JavaBeans 3.0) кажется неработающей.. (Я не настолько уверен, чтобы удалить ее самостоятельно!)

POJO

Тот факт, что обработка событий требует классов поддержки, интерфейсов и определенных базовых классов, не отменяет того факта, что по сути Java Bean — это просто старый-добрый объект. И добавление интерфейсов, базовых классов и классов поддержки в новый класс без соглашений Java Bean не делает класс чем-то большим, чем любой другой объект. 128.114.57.91 19:26, 24 октября 2006 (UTC) [ ответить ]


Двигаться??

JavaBeans перенести в JavaBeans??? Я что-то упускаю? -- so U m y a S ch 15:06, 7 мая 2006 (UTC) [ ответить ]

  • Поддержать ход. -- Solipsist 12:47, 24 января 2006 (UTC) [ ответить ]
  • Поддержка . В названии технологии нет пробела. – Doug Bell talk • contrib 19:04, 24 января 2006 (UTC) [ ответить ]


JavaBeans следует перенести в JavaBean , но для этого нужен администратор, поскольку перенаправление имеет историю. — Доклад Дуга Белла  • вклад 15:55, 8 мая 2006 (UTC) [ ответить ]
  • Oppose . Официальное название от Sun — JavaBeans. RedWolf 18:12, 2 июня 2006 (UTC) [ ответить ]
  • Против . Поддерживаю. capnmidnight 18:16, 8 июля 2006 (UTC) [ ответить ]
  • Поддержка . Другие заголовки страниц тоже в единственном числе. Это один JavaBean, два JavaBeans. Wouter Lievens 14:37, 6 июня 2006 (UTC) [ ответить ]

Я удалил свой голос. --Bonafidehan 16:30, 10 июня 2006 (UTC)d [ ответить ]

Я переместил статью (обратно) в JavaBeans , потому что так она официально называется. Бездумное применение какого-то правила, требующего единственного числа для названия статьи, в противном случае потребовало бы также, например, Strut , JavaServer Face , и, для этой известной операционной системы Microsoft... Window . Это просто не имеет смысла. RFST ( talk ) 18:31, 22 января 2012 (UTC) [ ответить ]

Разработка

Эта страница серьезно нуждается в расширении и разработке. Как и большинство бесполезных страниц помощи по программированию, все, что она делает, это объясняет, что требуется для того, чтобы что-то считалось Java bean и как оно используется - но никогда не объясняет, что это такое на самом деле ! 68.55.218.175 16:17, 25 мая 2006 (UTC) [ ответить ]

Я не вижу, какое дальнейшее объяснение "что есть" можно сделать помимо "что требуется" и "как это используется". Кроме того, есть описание: "многоразовый компонент, которым можно манипулировать визуально в инструменте-конструкторе". capnmidnight 18:15, 8 июля 2006 (UTC)... [ ответить ]

Я полностью согласен с автором оригинальной статьи — на мой взгляд, статья допускает распространенную ошибку в компьютерной науке, забывая «почему», когда подробно описывается «как». Она не описывает общую картину и сразу же теряется в деталях, таких как соглашения об именовании методов. Я прочитал страницу и ушел, думая: «Но при каких обстоятельствах вы их используете? Зачем кому-то отказываться от pojo в пользу Java Beans?» — Совет: в технических статьях убедитесь, что слово because появляется в первой строке. — 193.99.145.162 18:33, 21 ноября 2006 (UTC) [ ответить ]

Java Beans *являются* POJO со стандартным соглашением об именовании. Что касается " зачем" , то это для того, чтобы у вас был "переиспользуемый компонент, которым можно управлять визуально в инструменте-конструкторе". Вам нужно разъяснение, почему кому-то может понадобиться повторно используемый компонент? Как насчет разъяснения, почему кому-то может понадобиться визуально управлять им в инструменте-конструкторе? Вы жалуетесь на то, что в статье чего-то не хватает, хотя *это не так*. Если вы ожидали чего-то большего от JavaBeans, извините, в них просто не так много всего. capnmidnight 22:05, 30 ноября 2006 (UTC) [ ответить ]
"[JavaBeans] используются для инкапсуляции множества объектов в один объект (компонент), так что компонент может передаваться, а не отдельные объекты". Разве эта концепция не бесконечно рекурсивна? То есть, что предшествует компоненту? Что следует после? Как новичок в JavaBeans, я определенно согласен, что в этой статье не хватает контекста. -- Гийом ( обсуждение ) 13:43, 18 января 2008 (UTC) [ ответ ]
"Разве эта концепция не бесконечно рекурсивна?". Конечно, так и есть, хотя, строго говоря, прилагательное "рекурсивный" заслуживают только функции. Но как это может быть проблемой? Классы могут иметь поля, тип которых является классом, даже того же типа, который определяется. Это никого не беспокоит. Любая реализация шаблона Composite попадает под ваш вопрос и мой контрпример (например, org.3wc.dom.Node). Да, это так, но это неважно, поскольку то же самое относится к классам в объектно-ориентированных языках... Ваши вопросы применимы и к ним; так почему же в этой статье должен быть особый недостаток, потому что нет упоминания о том, что идет до или после? В любом случае, я не вижу ни одного программиста в здравом уме, который бы вкладывал бины в бины в бины и так далее до такой степени, что это стало бы проблемой. Я, например, никогда не вставляю бины в бины. Amenel ( talk ) 13:12, 15 июля 2010 (UTC) [ reply ]
На основе моего первоначального исследования Javaland, похоже, что есть те, кто использует термин POJO для обозначения того же, что и Java Bean. Мой пример взят из примера кода в "Beginning Spring Frameworks 2", Wrox Press, 2008. В главе 2 объекты, которые авторы описывают как POJO, имеют все соглашения Java Beans — сериализуемость, конструктор без аргументов, методы получения и установки. Есть ли что-то, что есть у Java Bean, чего определенно НЕТ у POJO? Или эти два термина постепенно сливаются в одну концепцию? Другими словами, я согласен с первым постером. dabeamer42 14 июля 2008 г. — Предыдущий комментарий был добавлен в 21:12, 14 июля 2008 г. (UTC)[ отвечать ]
JavaBean — это POJO. Но обратное неверно. Amenel ( talk ) 13:12, 15 июля 2010 (UTC) [ ответить ]
Что касается «почему», я могу дать ответ, который отражает, почему я использую JavaBeans в своем коде, будь то профессиональный или личный: просто чтобы избежать хлопот с постоянно растущими списками параметров в сигнатурах функций. Это происходит, когда одни и те же параметры передаются по цепочке вызовов функций с дополнительными параметрами или без них. Добавление нового фрагмента информации на одном конце цепочки требует изменения всех сигнатур до точки потребления. Выше определенного количества параметров просто мучительно менять сигнатуры всех функций в цепочке только для того, чтобы вновь добавленный фрагмент информации мог передаваться до тех пор, пока он не будет потреблен. Используя JavaBean, мне нужно просто 1- добавить поле, инициализированное либо null, либо подходящим значением по умолчанию, и его пару setter/getter, 2- установить его там, где он становится доступным, и 3- использовать его там, где он должен использоваться: набор изменений и модификаций файлов, если он ниже. Вот и все... хотя не всегда осуществимо/разумно в зависимости от контекста. Итак, определение «многоразовые программные компоненты для Java, которые можно визуально изменять в инструменте-конструкторе» было мне неизвестно (и никогда не встречалось), пока я не прочитал статью несколько минут назад. Amenel ( обсуждение ) 13:23, 15 июля 2010 (UTC) [ ответить ]

Как разработчик с опытом работы в основном с .NET/C#, я также нахожу эту статью слишком расплывчатой, вероятно, потому, что в ней не хватает контекста и глубины. Во-первых, мне кажется, что важным высокоуровневым следствием соглашения JavaBean является то, что начальное состояние задается не через конструкторы, а через сеттеры (что имеет последствия для внедрения зависимостей). Это явно не упоминается и может быть очевидно для того, кто действительно что-то построил с их помощью, но не сразу становится очевидным при беглом прочтении. Кроме того, следует дать техническое обоснование для каждого из отдельных требований JavaBean. Во-вторых, фразы «визуально манипулируемый» и «инструмент конструктора» слишком аморфны, однако их должно быть достаточно для объяснения существования JavaBeans. Какими способами визуально манипулируются JavaBeans? (Как структурные диаграммы классов? Разве исходный код не может считаться визуальным представлением, которым можно манипулировать? Следует ли перефразировать это как «графически манипулируемый»?) Каковы преимущества визуальной манипуляции, которую в конечном итоге поддерживают JavaBeans? (Управление сложностью? Построение диаграмм для улучшения документации и коммуникации? Быстрое прототипирование? Сокращенная кривая обучения Java?) О каких «инструментах конструктора» идет речь? (Eclipse? IntelliJ IDEA? javac и ant — это «инструменты конструктора», но поддерживают ли они упомянутую «визуальную манипуляцию»? Знают ли эти инструменты конструктора изначально, что квалифицируется как JavaBean посредством статического анализа кода? Вовлечено ли в это отражение?) В-третьих, являются ли JavaBeans стандартной практикой? (Они становятся или теряют популярность у основных разработчиков? У ведущих разработчиков?) В-четвертых, как JavaBeans соотносятся с другими технологиями или шаблонами? (Используются ли они в распределенных вычислениях? Поддерживают ли они прокси-компоненты? Каково их отношение к Enterprise JavaBeans?) Lunalot ( обсуждение ) 17:10, 28 июля 2011 (UTC) [ ответить ]

Соглашение об именовании

Насколько мне известно, булевы свойства пишутся с заглавной буквы так же, как и другие типы. Сравните спецификацию JavaBeans от Sun [[1]] и метод java.beans.Inspector.decapitalize(String). - leo 03 августа 2012 г. — Предыдущий комментарий без знака добавлен 80.218.115.95 (обсуждение) 22:05, 2 августа 2012 г. (UTC) [ ответить ]

Сериализуемые классы

Должны ли сериализуемые классы иметь строку типа "private static final long serialVersionUID = 7526471155622776147L;" Кажется, я читал, что serialVersionUID должен быть объявлен для сериализуемых классов. Отличается ли это для bean-компонентов? Просто мысль.

Возможность повторного использования

Что насчет JavaBean, что делает его более пригодным для повторного использования, чем любой другой класс или иерархия классов? Наивный читатель может подумать, что всеми классами можно манипулировать в инструменте-конструкторе, поэтому в статье следует указать, какие ограничения могут быть у не-Bean. Если простое соблюдение соглашений делает его пригодным для повторного использования, то, пожалуйста, так и скажите, и упомяните случаи использования, в которых он более пригоден для повторного использования, чем любой другой класс. Также может помочь определить, являются ли Enterprise JavaBeans подмножеством JavaBeans. -- Hroðulf (или Hrothulf) ( Talk ) 08:48, 4 октября 2007 (UTC) — Предыдущий неподписанный комментарий добавлен Hroðulf ( talk • contribs )[ отвечать ]

Картина

Мне нравится пример, но было бы неплохо увидеть картинку вывода. 138.162.8.58 ( обсуждение ) 14:01, 20 мая 2009 (UTC) [ ответ ]

Нужно переписать…

Я думаю, что некоторые из авторов этой страницы были дезинформированы. Во-первых, статья должна быть о технологии JavaBeans, а не об отдельных программных компонентах. Во-вторых, компоненты называются beans, а не JavaBeans. Так что, если не ссылаться на компонентную модель JavaBeans, эта страница должна называться Bean (Java). Просто мое мнение. -- Я Jake9 "Da' Pie!" 05:10, 17 ноября 2009 (UTC) [ ответить ]

Преимущество «запись один раз и запуск в любом месте» слишком велико

«Bean получает все преимущества парадигмы Java «написано один раз, запущено где угодно».

Любой код, написанный на Java, пользуется этим преимуществом (на большинстве ОС). Это преимущество не является специфичным для bean-компонентов. — Предыдущий неподписанный комментарий добавлен 217.37.69.169 ( обсуждение ) 15:53, 29 мая 2012 (UTC) [ ответить ]

Да! Информатика — мир хвастливых лозунгов, без какой-либо связной терминологии. Я тоже это ненавижу! Rursus dixit. ( m bork 3 !) 09:15, 21 ноября 2012 (UTC) [ ответить ]

История?

Когда были изобретены JavaBeans? Были ли какие-либо существенные изменения в концепции с тех пор? RenniePet ( обсуждение ) 02:25, 23 июля 2013 (UTC) [ ответить ]

Неправильно

В первом предложении говорится: «JavaBeans — это классы, которые инкапсулируют множество объектов в один объект (компонент)». Я считаю, что это очень плохая фраза по трем причинам:

Нет необходимости вовлекать несколько объектов в JavaBean. Отличный пример (хотя и малополезный) —

импорт java.io.Serializable;

открытый класс JBExample реализует Serializable {

 публичный JBExample(){}

}

Кроме того, хотя класс может «инкапсулировать множество объектов», обычно наибольший интерес представляют экземпляры классов. Инкапсуляция (или отсутствие) объектов непосредственно в классе не имеет значения для того, является ли он компонентом.

Наконец, если бы фактическим намерением было говорить об экземплярах класса: не только не нужно инкапсулировать много объектов, этого также недостаточно. Объекты Java могут инкапсулировать много других объектов, но им не обязательно быть экземпляром класса JavaBean, чтобы делать это.

Randallbsmith ( обсуждение ) 19:02, 10 марта 2016 (UTC) [ ответ ]

Разделы «Преимущества/Недостатки»

Мне кажется, что разделы «преимущества/недостатки» следует переписать более нейтрально. Я не считаю нейтральным называть что-либо преимуществом или недостатком, поскольку теоретически преимущество для одного человека может быть недостатком для другого. Кто-то удалил раздел «Недостатки» [[2]], и я думаю, что этот контент следует восстановить более нейтрально. CLCStudent ( talk ) 18:40, 24 августа 2018 (UTC) [ reply ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:JavaBeans&oldid=1259534449"