Инициализация double brace

Во всех языках программирования существуют красивые, лаконичные и простые конструкции, составляющие основу языка, а есть "хаки", глядя на которые невольно вспоминаешь собеседования и вопросы вида "вот вам 5 строк кода и 10 минут на то, чтобы объяснить как это вообще работает". Об одной из таких конструкций, а именно об инициализации double brace я и хотел бы сегодня рассказать.

Ссылки в Java

Все знают что такое жесткая (strong) ссылка. Мы сталкиваемся с ними ежедневно. Например, этот код:

StringBuffer buffer = new StringBuffer();

создаст экземпляр класса StringBuffer и поместит жесткую ссылку на этот экземпляр в переменную buffer. Что же заставляет нас называть такую ссылку жесткой? И какие они еще бывают? Ответы - под катом.

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

Продолжаем популярную тему собеседований. На этот раз мне попалась компания, в которой большое внмание уделяется многопоточности. Под катом вы найдете 15 вопросов, которые были мне заданы на должность Staff Java developer.

Обзор EasyMock

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

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

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

Подготовка к собеседованию на 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 MongoDB Tutorial

Сначала я хотел написать заметку, в которой бы вкраце излогались основные моменты работы с MongoDB, но потом понял, что официальный Java QuickTour уже удовлетворяет всем моим требованиям к конспекту по технологии, так что я решил просто сделать перевод данного руководства. Итак, начнем.

Основы JDBC

JDBC (Java DataBase Connectivity) - очень простая технология, обеспечивающая вашему приложению связь с базой данных. Даже если вы не планируете использовать её напрямую, то в любом случае было бы полезно знать как на самом деле работает ваш любимый фреймворк для БД.
В данной заметке мне бы хотелось пройтись по всем методам технологии, которые вероятнее всего вы будете использовать при написании своего приложения. Начнем с установки соединения.

Основы EJB: часть 1

Сервер приложений j2ee состоит из двух основных элементов: контейнер web-приложения (JSP, JSF и т.д.) и EJB-контейнер. Первый служит для создания пользовательского интерфейса и слабо подходит для описания бизнес-логики приложения. Для этого используется вторая часть J2EE - EJB.

Технологию EJB (Enterprise Java Beans) можно рассматривать с двух точек зрения: как фреймворк, и как компонент.
С точки зрения компонента EJB - это всего-лишь надстройка над POJO-классом, описываемая с помощью аннотации. Существует три типа компонентов EJB:

1. session beans - используется для описания бизнесс-логики приложения
2. message-driven beans - так же используется для бизнесс-логики
3. entities - используется для хранения данных

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

Перед тем, как продолжить обзор основ EJB остановимся на основе любого приложения - архитектуре.

Фильтры в web-приложениях

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

Фильры запроса могут использоваться для: проведения дополнительных проверок безопасности, форматирования заголовка или тела запроса, ведения логов и т.д.
Фильтры ответа могут использоваться для: сжатия выходного потока, дополнять или подменять выходной поток и т.д.
И фильтр запроса, и фильтр ответа используют при реализации  один интерфейс – Filter.

Пример декларации фильтра в дескрипторе развертывания:

    MyAppRequest
    com.example.myapp.myappRequest
    
        LogFileName
        UserLog.txt
    


    MyAppRequest
    *.do

Вместо <url-pattern> можно было указать <servlet-name> и использовать фильтр к какому-то конкретному сервлету.

Реализация фильтра для данного примера может быть такой:

public class myappRequest implements Filter {
    private FilterConfig fc;
    private void init(FilterConfig config) throws ServletException {
        this.fc = config;
    }
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws ServletException, IOException {
        HttpServletRequest httpReq = (HttpServletRequest) req;
        String name= httpReq.getRemoteUser();
        if( name!= null )
            fc.getServletContext().log(“User: “ +name);
        chain.doFilter(req,resp);
    }
    public void destroy() {}
}

Основные тэги JSTL (JSP Standard Tag Library)

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

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Тэг <c:out>
Используется для вывода данных на экран. Лучше, чем вывод типа ${pageContext.parameter}  тем, что позволяет контролировать специальные символы html, такие как <, >, &, ‘ и “. За то будут ли они обработаны как html или просто показаны на экране отвечает свойство escapeXml, которое по умолчанию стоит в true. Пример:

<c:out value=’${pageContext.parameter}’ escapeXml=’false’ />

Если в value будет null, то c:out выведет на экран пустое место, но если задать значение аттрибута по-умолчанию, то выведется оно. Например:

<c:out value=’${user}’ default=’guest’ />

напечатает имя пользователя, если оно есть или guest, если пользователь не задан.
Или можно написать так:

<c:out value=’${user}’>guest</c:out>

Упаковка по функциональности, а не по слоям

Перевод статьи «Package by feature, not layer».

Первый вопрос при проектировании нового приложения – «Как упаковать его по пакетам?». Для обычных приложений существует два ответа на этот вопрос.

Упаковка по функциональности (Package-by-feature)

Паттерн Package-by-feature подразумевает использование пакетов для отражения фунциональности. Предпологается, что все классы, относящиеся к некоторой функциональности (и только они) упаковываются в один каталог/пакет. В результате мы получаем пакеты с высокой степенью связанности и модульности с одной стороны, и минимальной связью с остальными пакетами с другой. Элементы приложения, которые тесно взаимодействуют друг с другом, находятся в непосредственной близости и не расползаются по всему приложению. В некоторых случаях, удаление части фунционала сводится только к одной операции – удалению каталога. (Операция удаления может быть хорошим показателем степени модульности элемента приложения: максимальная модульность возможна только в том случае, если элемент может быть удален используя только одну операцию.)