Java bean - synchronized method - кто тут прав?

[Palych]

Во-первых, согласно Вашему описанию, FormUtils не попадает под определение JavaBean.

Это один из классов входящих в состав универсального jar, которым мы пользуемся в классе. Препод его называет ...beans.jar Там всякие SQLUtils, GifEnсoder, класс для отправки емейлов и проч. Все что нужно для небольшого JSP приложения, которое делает базовые вещи: user self-registration, login, password reminder,etc.

Stalo byt' eto utilities. Sudya po vsemu mnogie iz nih mogut byt' zameneny na Beans.

Во-вторых, использование статических методов видится мне мягко говоря странным. JSP позволяет определить scope of the bean декларативно, а вы возлагаете это на сам класс... Проще говоря - методы не должны быть на static ни synchronized.
.

А как например декларативно?
В самом JSP обращение выглядит примерно так:

Code: Select all

String action = FormUtil.getAction(pageContext);
String sr_username = FormUtil.getValue(SR_USERNAME, pageContext);
String sr_password = FormUtil.getValue(SR_PASSWORD, pageContext);...

Как можно декларативно определить scope of the bean? Заранее прошу прощения если вопрос тупой, но все мы когда-то учимся.
Если долго объяснять, буду признательна хотя бы за линк.

Code: Select all

<jsp:useBean id="beanInstanceName" scope="session" class="package.class" />

Look for JSP Spec on java.sun.com

Izvinyayus' chto ne mogu podrobney - chto-to s pal'cAmi - bolyat sobaki... Stareyu...

[Dedal]

EJB != J2EE

. При чем тут EJB ? Вы давно спецификацию J2EE перечитывали ? A также спецификации всех технологий входящих в J2EE и общие принципы на которых они базируются ?

При том, что только EJB постулирует однопоточную модель. Но EJB -- это только часть J2EE.

[Sabina]

Code: Select all

<jsp:useBean id="beanInstanceName" scope="session" class="package.class" />

Теперь понятно, то есть это если они будут заменены на beans. Пока же это в виде импорта в декларации <%@ page import="....beans.*"%> и мне как-то в голову не пришло на предмет тага useBean.
Да и проходили мы это в прошлом семестре

Сабина

[Chelya]

Навалились то все как
Конечно у static functions есть свои хорошие использования. Теперь по очереди:

То есть вызов FormUtil из JSP можно назвать "JSP имеет business logic"?

Вызов FormUtils из JSP не есть business logic. Business logic - это layer вашего application, который отвечает за конкретныю функциональность, а не за interfaces, например. Никакого хорошего определения в голову не лезет - уверен сейчас кто-нибудь напиишет лучше и понятнее. В нашем случае я бы сказал, что session.invalidate(); в getAction является частью business logic, tak kak it logs user out.

А где обычно храниться business logic? В данный момент FormUtil входит в состав WEB-INF/lib/...beans.jar

Business Logic - это концепт, а не что-то, что физически отличается от обычных классов.

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

Придумать можно много чего. В большинстве случаев архитектура будет неправильной. К тому же Sabinу это только запутает.

Для простых программ MVC1 вполне работает. И статические функции -- это никакое не зло, а типичные библиотечные хелперы. Ничего они не ломают, не нужно сваливать их в одну кучу с глобальными переменными.

Нет ничего более постоянного, чем временный код. Нет такой маленькой плохо написанной программы, кототорая не переросла бы в большой headache. По крайбей мере из моего опыта.

Пожалуйста, объясните подробнее, почему Вы считаете, что static methods в большинстве случаев зло. По возможности аппелируя к личному опыту, а не к книгам, которые Вы прочитали про паттерны в Java или J2EE. Для меня будет весьма ценно, если вы сможете подкрепить утверждения "maintanance сложнее, extensibility хуже" описаниями конкретных проблем, с которыми Вам довелось столкнутся.
Я это все спрашиваю не из-за того, что собираюсь "зацепить" Вас. Я сравнительно недавно занимаюсь Java, но у меня уже сложилось впечатление, что большинство Java-программистов необоснованно избегают static methods, хотя стандартная библиотека Java использует их вовсю. Как например и Jakarta Commons.

Нащет Jakarta Commons не знаю - детально не приглядывался, но совневаюсь. Может какие-нибудь Common Utils. J2SE библиотечки тоже не ахти какой пример для подражания. Особенно то, что с первых версий идет.
Теперь о книгах. Всем кому интересна тема правильного программирования советую обзавестись "Expert One-on-One J2EE Design and Development" by Rod Johnson. На основе которой появился Spring Framework: http://www.springframework.org. Spring Framework на мой взгляд является эталоном дизайна.
Ну и наконец из собственного опыта. Static functions создают немало неудобств когда используются не по делу и не там, где надо. Кстати раньше по неопытности я совсем не обрашал внимания. Если static function можно избежать, то ее надо избежать. Если у вас много static functions, скорее всего это говорит о том, что что-то в дизайне неправильно.

[vlad12345]

Навалились то все как

А можно и мне тоже

Если static function можно избежать, то ее надо избежать.

А если нельзя? Например, можно ли избежать этого в классе Math?

Если у вас много static functions, скорее всего это говорит о том, что что-то в дизайне неправильно.

Согласен. Напрашивается аналогия с глобальными переменными в C++, их обилие явно дурной признак.

Static functions создают немало неудобств когда используются не по делу и не там, где надо.

Ну это утверждение будет верно применительно к чему угодно. Т.е. я к тому, что хотя надо быть осмотрительным со статическими функциями, но все-таки не такое уж зло. Иначе их вообще бы не было в java (как нету,например, goto, pointers и множественного наследования).

[Chelya]

Навалились то все как

А можно и мне тоже

Можно - если осторожно.

Если static function можно избежать, то ее надо избежать.

А если нельзя? Например, можно ли избежать этого в классе Math?

Ну если нелься, значит нельзя. Math class - это ок. FormUtils приведенные выше - это не ок.