Java-шкодер

Ходят слухи, что нельзя переопределять статические методы. Но компилятор не говорит об ошибках, когда видит следующий код:

Код компилируется и работает без ошибок. Так в чем, собственно, прикол? Кто сказал, что нельзя переопределять статические методы? Практика показывает обратное!

( Не все так просто :) )

Любимая детская забава - путаться в JOIN'ах. Прекращаем!

Тип	Описание
SELF JOIN	Объединение таблицы с самой собой.
CROSS JOIN	Группирует строки таблиц по принципу "каждая с каждой" (первая строка первой таблицы с первой строкой второй таблицы и т. д.) до тех пор, пока в левой*) таблице не закончатся строки.
NATURAL JOIN	Объединение по равенству. Связанными столбцами считаются те, которые в обеих таблицах имеют одинаковые имена. Обединяются только те строки, в которых значения связанных столбцов левой таблицы попарно совпадают со значениями связанных столбцов правой таблицы.
INNER JOIN	Связанными столбцами считаются те, которые упомянуты в условиях сравнения. Обединяются только те строки, в которых значения связанных столбцов левой таблицы попарно находятся в заданном оператором сравнения отношении со значениями связанных столбцов правой таблицы.
LEFT OUTER JOIN	Принцип работы как у INNER JOIN, но в результат объединения включаются все строки левой таблицы, а не только те, которым нашлось соответствие в правой (если некоторой строке левой таблицы нет соответствия в правой, то она объединяется со строкой с null'евыми значениями).
RIGHT OUTER JOIN	LEFT OUTER JOIN в зеркальном отображении. В результат включаются все строки правой таблицы, соответвующие им строки левой таблицы или null-строки, если соответсвия нет).
FULL OUTER JOIN	Включает все строи и левой, и правой таблицы. Если для какой-либо строки нет соответвующей в другой таблице, то она объедиеняется с null-строкой.

Стоит помнить, что обьединение строк можно реализовать как через JOIN-синтаксис, так и через SELECT-синтаксис.
--
*) Операнды объединения (две таблицы, которые подаются на вход) обычно называют левой таблицей и правой таблицей (в порядке следования).

Стихийным ресерчем выяснил дикую вещь: те классы, которые я при разработке по-привычке называл "бинами"... ими вовсе не являются! На самом деле это POJOs.

Вношу ясность:
JavaBean - это многократно используемый программный компонент, которым можно манипулировать визуально в средах разработки. Самый яркий пример бина - JButton.

JavaBean имеет конструктор по умолчанию (без параметров), осуществляет доступ к закрытым полям с помощью acessor methods, имена которых формируются из функции метода и имени поля по всем известному простому правилу, а также поддерживает интроспекцию, кастомизацию, события и persistence (последнее выражается в обязательной имплементации бином интерфейса java.io.Serializable).

Термин POJO (Plain Old Java Object) обычно используется для обозначения того факта, что объект не следует никаким моделям, конвенциям, фреймворкам. То есть POJO не наследует никаких предопределенных классов, не реализует никаких предопределенных интерфейсов и не содержит специальных аннотаций. Доступ к попертям осуществляется с помощю accessor methods, правила именования которых роднит POJOs с JavaBeans.

Линки:
JavaBeans API specification
POJOs @ wikipedia

В Java принято, чтобы сеттер возвращал void. В Smalltalk типа void нет, поэтому Smalltalk-программисты - любители вернуть из сеттера сам изменяемый объект. Такая практика привела к следующему стилю написания программ:

У такого стиля есть ряд недостатков, в их числе плохая читаемость кода и трудности при дебаге. Чтобы пофиксать последнее, достаточно каждый новый вызов метода писать в следующей строке:


Method chaining используется во многих Hibernate-интерфейсах, а также в jDOM. И если в Hibernate это принесло только удобство, то при использовании jDOM+Struts вылезло боком.

( Read more... )

Ну, здравствуйте всем!