Java for fun: Утиная типизация в Java

На написание этого поста меня вдохновила статья "Утиная типизация в Java" (автор Yaroslav Pogrebnyak).

Но с первым абзацем мне стала ясна суть идеи и я решил не дочитывать до конца, а попробовать самому решить эту задачу. После последнего коммита, я прочитал всю статью и отметил те моменты, которые были для меня новыми.
Внимание! Дальше будет много кода, если интересно - кликни меня...

Исходный код можно скачать тут, а все ревизии в SVN репозитории - тут.

Итак, лог разработки про то, как создавался ProxyFactory на TDD:

Ну что, если бы я делал проксик, то наверное хотел бы видеть его API как-то так

А вот и интерфейсы

Как помощники при тестировании, кроме jUnit на благо нового метода трудятся FestAssertions и Maven

Если мы запустим этот тест, то увидим что он не работает

"

По всем правилам TDD простой фикс, который можно сделать чтобы код компилился и работал – это

Тест пройдет

Но давайте протестируем все же поведение – я хочу знать что мой прокси вызовет другой объект а не то, что он вернет что-то...

Мне понадобится Mock-фреймворк Mockito

А вот и сам тест

Естественно он перестанет работать (я исправил старый)

Но небольшой фикс поможет

Идем дальше – меня интересует, что для других типов уток все будет работать!

Вот и тест

Он идентичен прошлому, с той лишь разницей, что в метод object передается объект другого класса...

Тест естественно не пройдет

Для реализации этой штуки мы подготовимся и выделим метод, который будем менять

А потом сделаем фикс

Тесты? Зеленые! Коммитимся

А теперь проверим, что наши чудо утки приводятся к другим интерфейсам тоже

А вот новый тест

Его основное отличие в типе интерфейса к которому приводится объект

И он не работает :)

Но фикс поможет!

Не пугайся, тут я воспользовался одной библиотечкой (1) fest reflect – чтобы не играться с ужасным api java.reflect.*

Так же тут используется прокси-класс (2), который обернет любой интерфейс и перенаправит все вызовы на метод invoke класса ObjectProxy (3)

Тесты проходят, а пока не сильно испортил код – лучше закоммичусь. Сложновасто уже :)

Дальше я хочу проверить как на совместимом интерфейсе вылетит Exception. Вот он интерфейс

А вот и тест.

Странно, но он проходит сразу – не верю!

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

Вот, это уже другой разговор!

Пошли его фиксить

Все, коммитимся

Дальше я хочу проверить, кейс, когда два метода в интерфейсе, а потому задам некого монстра, который может и квакать и мукать... И сходный с ним интерфейс. Внимание тут нет связи между классом и интерфейсом – по правилам java их с первого взгляда идентичные методы – разные!

А вот и тест, ничего нового, квакнули на прокси, проверили что монстр квакнул, мукнули на прокси, проверили что монстр мукнул...

Странно, но и это работает. Не верю!

А потому поломаю, добавив временный код. Увижу, что слетело и успокоюсь...

Ну ладно, проверю на всякий еще что-то...

Теперь можно сделать как было и проверить, что все работает

Коммитимся!

Но теперь давай сделаем другого монстра, который умеет еще и гавкать

Проверим что к его типу нельзя привести простого монстра...

Блин, опять все работает!

Не верю! А потому заремарю код проверяющий это и успокоюсь, когда увижу, что код слетел как я ожидал

Потом все верну как было, еще раз запущу и закоммичу, если зеленое

А теперь давай проверим кейсы с методами с параметрами

Вот и тест

Ну хоть тут тест слетел! :)

А фикс достаточно простой

И все! :) Зеленое – коммитимся!

Монстр методы которого возвращают другой тип чем в исходном, оборачиваемом классе

Вот и тест

Ура! Это еще не реализовано!

А потому реализуем

И все работает! А потому коммитимся!

Дальше поиграемся с примитивами

Все должно быть в шоколаде

Так и есть. Но надо перепроверить!

Добавим немного тестового кода и проверим что тест поломался

А после Ctrl-Z все работает

Коммит!

Дальше потестим, что примитивы и их обертки не распознаются как одни и те же типы (как было со String и Object)

Вот тест

Все прошло. Коммитимся (на самом деле я перепроверял, ломая код, просто тут не привел, ибо демонстрировал это уже) .

И еще один кейс – то же, но задом наперед

Вот и тест (так же работает - перепроверял)

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

Хотя нет! Появилась идея. А что, если интерфейсы наследуются друг от друга. Смогу ли я представить объект в виде суперинтерфейса и интерфейса наследника?

А вот и тест.

И он проходит! (я перепроверял, через поломку)

В вот второй тест, который делает то же но для суперинтерфейса

У него суперинтерфейса нет метода bowWof а потому блок заремарен :) (я копипастил)

Все проходит, а потому commit

Ура!