WikiProject Java | (Номинальный класс заглушки, средняя важность) |
---|---|
Условия непрофессионала
Какой, черт возьми, непрофессионал, знает, что такое POJO, сериализуемые, конструкторы и методы получения / установки? Думаю, формулировку можно улучшить. —Предыдущий комментарий без знака добавлен 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-компонентов. Rbakels ( разговорное ) 08:19, 18 мая 2019 (UTC)
Ссылка на COM
Я думаю, что отношение к 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 ??? Что-то мне не хватает? - так U м Y с S ч 15:06, 7 мая 2006 (UTC)
- Поддержка движения. - Солипсист 12:47, 24 января 2006 г. (UTC)
- Поддержка . В названии технологии нет места. - Дуг Белл разговор • вно 19:04, 24 января 2006 (UTC)
- JavaBeans следует переместить в JavaBean , но для этого требуется администратор, поскольку перенаправление имеет историю. - Дуг Белл разговор • вно 15:55, 8 мая 2006 (UTC)
- Против . Официальное название Sun - JavaBeans. RedWolf 18:12, 2 июня 2006 г. (UTC)
- Против . Прикомандированный. capnmidnight 18:16, 8 июля 2006 г. (UTC)
- Поддержка . Остальные заголовки страниц тоже в единственном числе. Это один JavaBean, два JavaBean. Воутер Ливенс 14:37, 6 июня 2006 г. (UTC)
Я снял свой голос. - Бонафидехан, 16:30, 10 июня 2006 г. (UTC) d
Я переместил статью (назад) в JavaBeans , потому что так она называется официально. Бездумное применение некоторого правила, которое требует единственного числа для названия статьи, в противном случае также потребовало бы, например, Strut , JavaServer Face и, для этой хорошо известной операционной системы Microsoft ... Window . В этом нет никакого смысла. RFST ( разговор ) 18:31, 22 января 2012 (UTC)
Проработка
Эта страница серьезно нуждается в расширении и доработке. Как и в случае с большинством бесполезных страниц справки по программированию, все, что он делает, это объясняет, что требуется для того, чтобы что-то считалось Java-компонентом и как его использовать, - но никогда не объясняет, что это такое на самом деле ! 68.55.218.175 16:17, 25 мая 2006 г. (UTC)
- Я не понимаю, какое дальнейшее объяснение того, «что есть», можно было бы сделать в прошлом, «что требуется» и «как это используется». Кроме того, есть описание: «компонент многократного использования, которым можно визуально управлять с помощью инструмента построения». capnmidnight 18:15, 8 июля 2006 г. (UTC) ...
Я полностью согласен с оригинальным постером - имхо в статье делается обычная ошибка comp-sci, когда забывается «почему» при объяснении «как». Он не говорит об общей картине и сразу теряется в деталях, таких как соглашения об именах методов. Я прочитал страницу и ушел, думая: «Но при каких обстоятельствах вы их используете? Зачем кому-то отказываться от pojos в пользу Java Beans?» - Совет: в технических статьях убедитесь, что слово потому что отображается в первой строке. - 193.99.145.162 18:33, 21 ноября 2006 г. (UTC)
- Java Beans * - это объекты POJO со стандартным соглашением об именах. Что касается причины , это значит, что у вас может быть «возобновляемый компонент, которым можно визуально манипулировать с помощью инструмента построения». Вам нужна дополнительная информация о том, зачем кому-то нужен многократно используемый компонент? Как насчет уточнения того, почему кто-то может захотеть визуально манипулировать им в инструменте построения? Вы жалуетесь на то, что в статье чего-то не хватает, а * это не *. Если вы ожидали чего-то большего от JavaBeans, извините, их просто не так уж и много. capnmidnight 22:05, 30 ноября 2006 г. (UTC)
- «[JavaBeans] используются для инкапсуляции множества объектов в один объект (bean-компонент), так что bean-компонент может передаваться, а не отдельные объекты.». Разве эта концепция не бесконечно рекурсивна? т.е. что предшествует бобу? Что будет после? Как новичок в JavaBeans, я определенно согласен, что в этой статье отсутствует контекст. - Гийом ( разговор ) 13:43, 18 января 2008 г. (UTC)
- «Разве эта концепция не бесконечно рекурсивна?». Конечно, хотя, строго говоря, только функции заслуживают «рекурсивного» прилагательного. Но в чем проблема? Классы могут иметь поля, тип которых является классом, даже тем же типом, который определяется. Это никого не беспокоит. Любая реализация шаблона Composite подпадает под ваш вопрос и мой контрпример (например, org.3wc.dom.Node). Да, но это не имеет значения, поскольку то же самое относится и к классам объектно-ориентированных языков ... Ваши вопросы применимы и к ним; Так почему в этой статье должен быть особый недостаток, потому что нет упоминания о том, что происходит до или после? В любом случае, я не вижу ни одного программиста в здравом уме, который вкладывал бы beans в beans в beans и так далее до такой степени, что это было бы проблемой. Я, например, никогда не добавляю бобы в бобы. Аменель ( разговор ) 13:12, 15 июля 2010 (UTC)
- Основываясь на моем первоначальном исследовании 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. Но обратное неверно. Аменель ( разговор ) 13:12, 15 июля 2010 (UTC)
- Что касается «почему», я могу дать ответ, который отражает, почему я использую JavaBeans в своем коде, будь то профессиональный или личный: просто для того, чтобы избежать хлопот, связанных с постоянно растущими списками параметров в сигнатурах функций. Это происходит, когда одни и те же параметры передаются по цепочке вызовов функций с дополнительными параметрами или без них. Добавление новой части информации на одном конце цепочки требует изменения всех подписей до точки потребления. Если количество параметров превышает определенное, очень сложно изменить сигнатуры всех функций в цепочке, чтобы только что добавленную информацию можно было передавать до тех пор, пока она не будет использована. Используя JavaBean, мне просто нужно: 1 - добавить поле, инициализированное либо нулевым, либо подходящим значением по умолчанию, и его пару сеттер / получатель, 2 - установить его там, где он становится доступным, и 3 - использовать его там, где он должен быть использовано: набор изменений и модификаций файла, если он ниже. Вот и все ... хотя это не всегда возможно / разумно в зависимости от контекста. Таким образом, определение «повторно используемые программные компоненты для Java, которыми можно управлять визуально с помощью инструмента построения», было мне неизвестно (и никогда не было) до тех пор, пока я не прочитал статью несколько минут назад. Аменель ( разговор ) 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)
Соглашение об именовании
Насколько мне известно, логические свойства пишутся с заглавной буквы так же, как и другие типы. Сравните спецификацию Sun JavaBeans [ [1] ] и метод java.beans.Inspector.decapitalize (String). - Лев, 3 августа 2012 г. - Предыдущий неподписанный комментарий добавлен 80.218.115.95 ( обсуждение ) 22:05, 2 августа 2012 г. (UTC)
Сериализуемые классы
Если в сериализуемых классах есть строка вроде «private static final long serialVersionUID = 7526471155622776147L;» Думаю, я читал, что serialVersionUID следует объявлять для сериализуемых классов. Это другое для бобов? Просто мысль. привет —Предыдущий комментарий без знака добавлен 203.197.25.11 ( обсуждение ) 12:01, 6 сентября 2007 г. (UTC)
Возможность повторного использования
- Что насчет JavaBean делает его более пригодным для повторного использования, чем любой другой класс или иерархия классов? Наивный читатель может подумать, что всеми классами можно управлять с помощью инструмента построения, поэтому в статье следует указать, какие могут быть ограничения у не-bean-компонентов. Если простое соблюдение соглашений делает его многоразовым - скажите, пожалуйста, - и укажите варианты использования, в которых его можно использовать повторно, чем любой другой класс. Также можно сказать, являются ли Enterprise JavaBeans подмножеством JavaBeans. - Hroulf (или Hrothulf) ( Обсуждение ) 08:48, 4 октября 2007 г. (UTC) - Предыдущий неподписанный комментарий, добавленный Hroulf ( обсуждение • вклад )
Картина
Мне нравится пример, но было бы неплохо увидеть картинку на выходе. 138.162.8.58 ( разговорное ) 14:01, 20 мая 2009 г. (UTC)
Требуется переписать…
Я думаю, что некоторые авторы этой страницы были дезинформированы. Прежде всего, статья должна быть посвящена технологии JavaBeans, а не отдельным программным компонентам. Во-вторых, компоненты называются bean-компонентами, а не JavaBeans. Итак, если не относится к компонентной модели JavaBeans, эту страницу следует называть Bean (Java). Только мое мнение. - Я Jake9 "Da 'Pie!" 05:10, 17 ноября 2009 г. (UTC)
Преимущество записи один раз в любом месте слишком велико
«Бин получает все преимущества парадигмы Java« написать один раз, запустить где угодно ».
Любой код, написанный на Java, пользуется этим преимуществом (в большинстве ОС). Это преимущество не относится к бобам. - Предыдущий беззнаковый комментарий добавлен 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 - это классы, которые инкапсулируют множество объектов в один объект (bean-компонент)». Я считаю, что это действительно плохо по трем причинам:
В JavaBean нет необходимости задействовать несколько объектов. Совершенно хороший пример (хотя и малопригодный):
import java.io.Serializable;
открытый класс JBExample реализует Serializable {
public JBExample () {}
}
Кроме того, хотя класс может «инкапсулировать множество объектов», обычно больше интересуют экземпляры классов. Инкапсуляция (или нет) объектов непосредственно в классе не имеет значения для того, чтобы быть компонентом.
Наконец, если фактическое намерение состояло в том, чтобы говорить об экземплярах класса: инкапсулировать многие объекты не только необязательно, но и недостаточно. Объекты Java вполне могут инкапсулировать многие другие объекты, но для этого они не обязательно должны быть экземпляром класса JavaBean.
Рэндаллбсмит ( разговор ) 19:02, 10 марта 2016 (UTC)
Разделы о преимуществах / недостатках
Мне кажется, что разделы о преимуществах / недостатках следует переписать в более нейтральной форме. Я не считаю нейтральным называть что-либо преимуществом или недостатком, потому что теоретически преимущество для одного человека может быть недостатком для другого. Кто-то удалил раздел «Недостатки» [ [2] ], и я думаю, что контент следует восстанавливать более нейтральным образом. CLCStudent ( разговор ) 18:40, 24 августа 2018 (UTC)