Сервер приложений
Самое главное в EJB это сервер приложений. Без него у Вас ничего работать не будет. Клиентские приложения будут общаться с ним через RMI или CORBA. Обычно сервер приложений предоставляет Вашим EJB компонентам соответствующую среду. Например: хранит права доступа к Вашим компонентам (а точнее логины с паролями по доступу к серверу приложений), поддерживает RMI и CORBA взаимодействие с ними, предоставляет JNDI сервис (сервис именования EJB компонентов), координатор транзакций и контейнер, в котором будут храниться ваши EJB компоненты, сервис асинхронных сообщений JMS. Специалисты, которые это прочтут, будут возмущены грубыми ошибками. Дело в том, чтобы не грузить читателя, я довольно упростил и смешал некоторые вещи. Сервер Приложений

Часть 4

HOME-интерфейс
Как уже говорилось выше, вся работа с компонентами начинается с обращения к Home-интерфейсу. Каждый тип компонент должен его иметь. Пример Home-интерфейса изображен на рис. 8.

Сразу хочу предупредить вот о чем. Здесь не будет криков "как все круто" или "как все плохо". Я отношусь к Java именно с точки зрения философской. Это – данность. Потому – рассуждать о том, хорош язык или плох, бессмысленно. Язык может удовлетворять предъявляемым требованиям, либо не удовлетворять им. Ежели удовлетворяет – прекрасно, пользуемся. Нет – выбираем другой. А то получается как в том анекдоте: "Мыши плакали, кололись, давились, но продолжали грызть кактус" . Если Java для вас – кактус, возможно, стоит задуматься о выборе другого языка. А если все-таки грызете, несмотря на то, что это кактус, – значит, плюсов в этом занятии для вас больше чем минусов. Тогда не жалуйтесь.

Сказать по правде, изначально я этой статьи не планировал. Я считал вопросы, которые хочу тут обсудить, тривиальными, не стоящими даже упоминания. Однако в процессе написания статей для этого сайта я поднял в одном из форумов обсуждение множественного наследования. В результате чего выяснилось, что большая часть разработчиков имеет весьма смутное представление о наследовании. И, соответственно, допускает очень много ошибок. Поскольку наследование является одной из важнейших черт ООП (если не самой важной!) – я решил посвятить этому явлению отдельную статью.

Существует, на мой взгляд, несколько правил, которыми стоит руководствоваться при разработке программного обеспечения, вне зависимости от того, что разрабатывается и для кого. Здесь я исхожу из мысли, которая очевидна: программное обеспечение разрабатывается людьми и для людей. Из этой мысли и вытекают все правила, о которых пойдет речь. Я бы назвал эти правила аксиомами, ибо для меня они аксиомами и являются. Возможно, эти аксиомы и просты, но меня поражает количество людей, которые о них не знают либо не следуют им.

В этой статье речь пойдет об использовании констант. При всей внешней простоте этот вопрос содержит немало тонкостей, как идеологического, так и чисто реализационного плана. Когда и почему стоит использовать константы? Когда этого можно не делать, и почему? На эти вопросы я хочу дать ответы. Сразу оговорю – речь идет в основном о числовых константах. Использование неизменяемых объектов вызвано несколько другими причинами.

Прежде всего я хочу задать тривиальный на первый взгляд вопрос: а что такое константа с точки зрения программирования? Подчеркиваю, вопрос тривиален лишь на первый взгляд. Ибо то, что называется константой в программировании, часто не является таковой в привычном смысле этого слова.

Я пришел к этому выводу на том основании, что число два
бессмысленно и существовать не может.

Айзек Азимов. "Сами Боги"

Вопрос, который я хочу рассмотреть в этой статье, относится больше к области разработки архитектуры программного обеспечения. Мой опыт показывает, что чаще всего об этом не задумываются, в результате чего может возникнуть масса проблем. Речь пойдет о числах в проектировании.

Итак. Представим себе приложение, имеющее одну рабочую область. Скажем, панель, на которой можно визуально раскладывать узлы графа. Для этой работы есть целая панель инструментов, достаточно большая. Представили? Замечательно! Приложение развивается, и вот нам понадобилась вторая такая же панель, на которую, скажем, можно скопировать фрагмент основного графа. Вопрос. Что делать с панелью инструментов?

Для начала я вообще хочу определить, о чем пойдет речь. Ибо качество кода многие неразрывно отождествляют с качеством приложения – устойчивостью, скоростью, безопасностью и т.п. Я хочу поговорить несколько о другом – о качестве именно программного кода. Это не одно и то же. К сожалению, есть много примеров быстрых, устойчивых приложений, качество кода в которых оставляет желать лучшего. И наоборот – код может быть очень качественным, а приложение никуда не годится. И если качество приложения в основном зависит от продуманности его архитектуры, то качество кода зависит непосредственно от разработчиков.