abashinos/tp_2014_02_java_abashin

tp_2014_02_java_abashin's Issues

Почитать про именования классов и методов

И применить на практике.

Если программист читает userAccount, он ожидает пользовательский аккаунт. А не AccountService.

Вопрос широко освещен в литературе:

1. Совершенный код
   http://www.ozon.ru/context/detail/id/4729959/
2. Рефакторинг
   http://www.ozon.ru/context/detail/id/1308678/

Есть в библиотеке Технопарка.

UserId должна выдавать база

public class UserAccount {

    private AtomicLong userIdGenerator = new AtomicLong();

В базе итак есть increment.

Вынести общую часть у LoginServletTest и FrontEndTest

В вашей версии этого кода они называются LoginTest и SignupTest.

Нужно сделать абстрактный тест. Унаследовать от него setUp и реализовать логику.

src/main/java/services/AccountService.java - убрать из всех методов HttpServletRequest

Классы должны быть как можно более изолированными. AccountService не должен ничего знать про request'ы. Он должен получать данные для передачи в DAO, и возвращать данные для FrontEnd'а. Все исключения, возникающие в DAO, AccountService должен обрабатывать и выдавать результат в понятном для FrontEnd'а виде. Т.е. фронтенд тоже ничего не должен знать про различные DBException'ы. Если уж нужно сообщить на фронтенд об ошибке в аккаунт-сервисе, сделать AccountServiceException

Навести порядок в пакетах

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

Например, вряд ли кто-то будет использовать PageGenerator из пределов пакета Frontend. Это значит, что PageGenerator - самое место в Frontend'е.

Похожим образом предлагаю оценить необходимость и других разделений.

Переписать тесты

Посмотрите внимательно на код, который Вы написали в публичный репазиторий. Посмотрите, где copy-paste одних и тех же методов, посмотрите, где static static'ом погоняет. Посмотрите, и перепишите так, чтобы ни Вам, ни нам стыдно не было.

Посмотрите, как должны выглядеть константы, а как - просто поля класса.
Java Code Convention
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

Особенно расстраивают:

1. https://github.com/Abashinos/tp_2014_02_java_Abashin/blob/master/src/test/java/services/UserAccountTest.java
2. https://github.com/Abashinos/tp_2014_02_java_Abashin/blob/master/src/test/java/servlets/SignupServletTest.java

servlets/WaitServlet.java метод doGet() не потокобезопасный

обезопасить

Переписать работу с соединениями с базой данных

Вы вдохновлялись, заимствовали или случайно использовали код, который понимаете не до конца.

DBConnectorH2
DBConnectorMySQL

нужно как раз для того, чтобы выпилить

public enum dbType {MySQL, H2}

И уж очень странно (и знакомо) выглядит

 public DBConnectorMySQL() {
        setConfigurationProperties();
        setDataSets();
        setSessionBuilderConfiguration();
    }

В общем, не буду читать вам лекцию о вреде copy-paste, списывания и плохо кода.
Сформулирую задание:

1. Выделить интерфейс - IConnector с методом getConnectionParams.
2. AccountService ( #3 ) на вход должен принимать IConnector.
3. UserDAOimpl не должен хранить соединение - это ему не нужно. Если считаете иначе, пишите - обсудим.

поправить имена классов

messaging/MessageToAMSSS.java - один из примеров. по имени класса должно быть понятно, что это за класс.

Какой смысл у функции UserDAOimpl.add возвращать boolean?

Либо есть исключение, либо пользователь добавлен и всё хорошо.

Переписать Frontend

Ваша задумка с Frontend, Redirector и SignupServlet понятна. Но реализована неудачно.

Что необходимо сделать - разделить всю обработку на несколько Servlet'ов (явно, а не как сейчас), дав им соответствующие имена. Один url - один servlet. Если есть пара servlet'ов c похожим смыслом (например, авторизация и логин), можно выделить общую часть в отдельный Servlet и унаследоваться от него. Тогда исчезнут все эти бесконечные if, else, switch.

servlets/AbstractServlet.java - ужасно непотокобезопасный!

исправить

исправить инспекции

горят в некоторых классах