Я студент, в пятницу собеседование на junior java developer.
дали на дом написать проект :Создать Иерархию конфет и прочих сладостей. создать неколько обьектов-конфет.собрать детский подарок с определением его веса.

При этом не использовать никаких внешних источников данных, то есть тупо показать знания ооп.

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

оставил пару коментов что как мне кажеться лучше переделать.
И еще надо вставить исключительные ситуации,  интерфейсы, и может еще че, но это уже завтра.Очень был бы рад если бы подсказали куда привинтить интрефейс , сам думаю  создать интерфэйс с методами добавки примисей типа Chocolate.add(орехи), там надо бы параметризацию что б нельзя было бобавить орехи в карамель, которую я не помню как делать, если подскажете тоже буду рад; 

 Ввобщем вот:



еще анологичные Chocolate, классы Caramel, Wafer, Zephyr
дальше 

Я не гуру, но выскажу свое мнение.
Мне класс Sweet кажется странным. По смыслу,  это должна быть некая абстрактная конфета, ОДНА конфета. А у тебя получается, что это вовсе не конфета, а пачка конфет. Если задание звучит именно так, как ты написал, то я бы убрал количество из самой конфеты. Т.е. хочешь положить в подарок 10 шоколадных конфет - создаешь 10 экземпляров и добавляешь.
Название GiftGenerate мне тоже кажется странным. Почему не назвать просто Gift или SweetGift?
Мне кажется, что нужно проверять аргументы конструктора на null. Да и не только конструктора, и не только на null =) и бросать InvalidArgumentException или какие-то свои исключения. Но тут надо без фанатизма, в меру.
Еще я бы переопределил equals(), hashcode() и toString() у Sweet.
Javadoc - комментарии написал бы.

так писать не стоит. нужно использовать интерфейс Collection или List.
P.S.> А где это в Минске такие задания дают, если не секрет?

1. Sweet - это интерфейс, а то, что у тебя написано, - это AbstractSweet. Далее Caramel, Chocolate, Wafer, Zephyr - абстрактные наследники AbstractSweet. А вот от них уже реализовывать конкретные конфеты, шоколадки и прочее...

2. Report по-умному должен бы работать хотя бы через String.format(), но лучше через  MessageFormatter.
3. У enum-ов есть замечательный метод valueOf(String).

2 Temdegon, это на  Epam дают такие задания, не совсем на работу это на курсы с  возможным последующим трудоустройством))

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

Обясни, пожалуйста, почему.

Я этими вещами с ArrayList тоже никогда не загружаюсь. Может зря.

Это сообщение отредактировал(а) _Y_ - 24.2.2011, 09:46

вот я сделал String.Format вот так нормально?


Это сообщение отредактировал(а) Che0 - 24.2.2011, 10:32

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

Например тот же Hibernate явно запрещает объявлять поля с конкретными классами коллекций, только базовые интерфейсы.

И насчет эксэпшенов: зачем проверять если у меня  параметры задаються через конструктор, задать не тот тип или null нельзя  и так
Или я что то не так понял?? 

Che0, ты меня не слушай. То, что Temdegon с LSD говорят для твоего случая подходит без обсуждений. Я эти вопросы задаю с целью повышения лично своего морального уровня.



Что касается всяких других коллекций, я согласная. Хоть и такие надобы чрезвычайно редки у меня. А вот ArrayList в 99% случаев используется только как массив переменной длины. Нужно ли снижать читаемость кода в угоду религиозно-идеологическим убеждениям?


Здесь я могу только согласиться; по той простой прочине, что с Hibernate не работал.

Это сообщение отредактировал(а) _Y_ - 24.2.2011, 14:07

Если вместо первого аргумента передать null, то в строке 
if(!nameSweet.isEmpty()&& countSweet>0){
вылетит NullPointerException


А в чем ухудшение читабельности, если вы обьявите List list = new ArrayList() ? по мне так одно и то же. Ну и массивы же можно по разному использовать, и для одних задач лучше подойдет LinkedList, чем ArrayList

А в чем снижение читабельности?

по аналогии в енаме null первые два параметра тоже ошибку выбивают.
 и какие еще опасные места и какие там ошибки ,посоветуейте, а то я их в упор не вижу?

Это сообщение отредактировал(а) Che0 - 24.2.2011, 18:42

И еще вопрос, если я не использую нигде хэшкод и иклс то зачем мне его переопределять?

Можно конечно не переопределять. Но с такой же позиции, можно и исключения не обрабатывать, и параметры не проверять, ссылаясь на то, что "ну я же буду передавать правильные аргументы!". 
Если вы пишете класс, то подразумевается, что пользовать его можете не только вы, а любой другой программист. Sweet - это сущность. Обычно такие классы загружаются/сохраняются, хранятся в коллекциях, сравниваются. Что бы их можно было легко и правильно сравнивать, нужно переопределить equals. Что бы хранить в коллекциях типа HashMap и HashSet нужен hashCode. toString, даже в примитивном виде тоже весьма полезен. Когда вам нужно будет вывести что-то в лог, вам не нужно будет постоянно  писать фигню типа

а просто

Temdegon, LSD, вряд ли вы меня убедите, что кастинг классов улучшает читабельность кода. ИМХО где он нужен - там нужен, а где нет - нафиг.