Обзор EasyMock

Юнит-тестинг - тестирование классов или их методов в изоляции от других объектов системы. Обычно классы в Java зависят от других классов, таким образом чтбы протестировать какую-либо функциональность вам нужно будет создать экземлпяр класса, отличного от тестируемого, что само по себе противоречит идее юнит-тестинга. Mock-объект - интерфейс или класс-пустышка, в котором вы определяете результат вызова методов. Эти объекты и передаются классу, который мы хотим протестировать, т.к. при юнит-тестинге мы должны избегать зависимостей от любых внешних данных.

Мы можем писать такие классы-заглушки сами, а можем воспользоваться одним из Mock-фреймворков для симуляции таких классов.

В Java к самым популярным Mock-фреймворкам можно отнести EasyMock и jMock. Сегодня мы рассмотрим первый из них.

Вопросы на интервью по технологиям Java Spring и Hibernate

Продолжаем тему интервью. В прошлых статьях мы рассмотрели основные концепции, которые вы должны знать для прохождения интервью по Java, но основ языка недостаточно. Обычно компании предпологают, что вы уже владеете каким-либо популярным фреймворком и способы самостоятельно реализовать реальное приложение. На сегодня самыми популярными фреймворками являются Spring и Hibernate. Возможно скоро к этому must have списку добавиться GWT, а пока что давайте рассмотрим какие вопросы могут быть заданы вам при прохождении интервью на уровень staff developer.

Подготовка к собеседованию на java-программиста (уровень Middle)

Продолжим тему собеседований. В этот раз рассмотрим что вы обязаны знать, если претендуете на должность middle (staff) java developer (описание для уровня junior смотри тут).
Отдельные части текста нагло взяты из википедии, необъятных просторов интернета и, что самое страшное, головы.

Подготовка к собеседованию на java-программиста (уровень Junior)

Недавно в руки попала табличка, по которой в одной замечательной компании рекомендуют собеседовать java-программистов. Опуская моменты специфичные для данной конкретной вакансии попробуем очень вкраце пробежаться по вопросам, которые я бы рекомендовал повторить перед собеседованием на java-программиста. Это описание для уровня junior, описание для уровня middle (staff) смотри тут.

SOLID в 5 предложениях

Single Responsibility Principle
Не должно существовать более одного мотива для изменения данного класса.

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

Liskov Substitution Principle
Наследующий класс должен дополнять, а не замещать поведение базового класса.

Interface Segregation Principle
Клиент не должен вынужденно зависеть от элементов интерфейса, которые он не использует.

Dependency Inversion Principle
Абстракции не должны зависеть от деталей, в то время как детали должны зависеть от абстракций.

<? super E> и <? extends E> в коллекциях

Многие программисты путают (а некоторые и не знают) эти конструкции при работе с коллекциями. Что же они означают?

Первая означает, что объекты коллекции будут предками для Е, а вторая - объекты, которые являются подтипами Е. Таким образом при использовании <? extends E> мы точно знаем, что объект коллекции будет типа E или его потомком (т.е. совместимым с Е).
Пусть у нас есть такая иерархия:

Parent extends Object
Child extends Parent

и есть очередь LinkedBlockingQueue<Parent>. Мы можем вызвать конструктор данной очереди, передав ей List<Child>, потому что каждый Child является Parent, и мы не можем передать List<Object>, потому что Object может быть не совместим с Parent.

Так же вы можете перенести эту очередь в List<Object>, потому что каждый Parent является Object, но вы не можете перенести очередь в List<Child>, потому что этот лист будет ожидать того, что все элементы будут совместимы с Child.

Таким образом имеем простое правило: extends - для вычитки из коллекции, super - для занесения в коллекцию.

Пишем планировщик на Java

Недавно возникла необходимость чтобы приложение в назначеное время выполняло работу по поддержке своей базы (обновляло информацию). Конечно можно было написать маленькую утилитку и вызывать её из крона, но этот вариант показался неудобным в поддержке - сервер приложений может переезжать и настраивать на каждом новом сервер крон желания не было, т.е. хотелось бы чтобы приложение само себя обслуживало, без лишних телодвижений.

К счастью существует несколько способов создать свой планировщик в enterprise-приложении. Об одном из них (а именно как это сделать с помощью ServletContextListener) я далее и расскажу.