Какие части Java-приложения должны быть написаны на Scala?

Question

Я пишу Java-приложение с использованием Struts 2, но теперь я бы хотел сделать его гибридным проектом Java & Scala. У меня нет большого опыта работы со Scala, но я изучал Haskell несколько лет назад в колледже - мне действительно понравилась парадигма с функциональной программой, но, конечно, в классе нам давали только те проблемы, которые в высшей степени подходили для функционального решения! В реальном мире, я думаю, что некоторый код лучше подходит для императивного стиля, и я хочу продолжать использовать Java для этого (я знаю, что Scala поддерживает императивный синтаксис, но я не готов идти в направлении чистого проекта Scala только пока).

В гибридном проекте, как решить, что кодировать на Java и что кодировать на Scala?

Answer 1

Две вещи:

1. 99% кода Java можно выразить в Scala
2. Вы можете писать проекты, которые поддерживают смешанную компиляцию Java + Scala. Ваш код Scala может вызывать ваш код Java, а ваш код Java может вызывать ваш код Scala. (Если вы хотите сделать последнее, я предлагаю определить интерфейс в Java, а затем просто реализовать его в Scala. В противном случае вызов кода Scala из Java может стать немного уродливым.)

Так что ответ таков: какие бы части вы ни хотели. Ваш код Scala не обязательно должен быть чисто функциональным. Ваш код Scala может вызывать библиотеки Java. Так что практически все части, которые вы можете написать на Java, вы можете написать на Scala.

Теперь несколько практических соображений. При первом запуске Scala некоторые люди выбирают относительно изолированные, не критически важные части своей программы для написания в Scala. Модульные тесты - хороший кандидат, если вам нравится такой подход.

Если вы знакомы с Java и изучали Haskell в прошлом, я предлагаю рассматривать Scala как «лучшую Java». По сути, Scala компилирует в байт-код JVM, который очень и очень похож на то, что выводит Java. Единственное отличие состоит в том, что Scala более «продуктивен»: он производит больше байт-кода на строку кода, чем Java. Scala имеет много общего с Haskell (первоклассные функции, for-comp понять - как do-нотация Haskell, ограниченный вывод типов), но она также очень отличается (по умолчанию она не ленивая, она не чистая). Таким образом, вы можете использовать некоторые из ваших идей из Haskell, чтобы вдохновить ваш стиль Scala, но «под капотом» это все байт-код Java.

Answer 2

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

Библиотека коллекций Scala является основной функциональной особенностью Scala, и вы сможете значительно сократить LoC за счет ее использования. Да, есть альтернативы Java, такие как библиотека коллекций Google, но вы спросили, что вы должны написать в Scala. : -)

Scala также имеет встроенную обработку XML. Возможно, переход будет затруднен, если вы попытаетесь взять код DOM и заставить его работать в Scala. Но если вместо этого вы попытаетесь приблизиться к проблеме и перспективе Scala и написать ее с нуля для Scala, вы получите выгоды.

Я бы посоветовал также использовать Actors, но я не уверен, насколько хорошо вы можете интегрировать это с кодом Struts 2 на Java. Но если у вас есть параллельный код, подумайте об актерах в Scala.

Answer 3

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

Answer 4

Задайте эти вопросы вашему проекту: «Какие операции требуют побочных эффектов?» и "Какая функциональность уже хорошо освещена библиотеками Java?" Затем выполните остальное в Scala.

Однако я бы предупредил, что гибридные проекты по своей природе сложнее, чем отдельные проекты, так как вам нужно использовать несколько языков / сред. Поэтому, учитывая, что у вас мало опыта работы со Scala, я бы сначала порекомендовал поиграть с некоторыми игрушечными проектами, возможно, в подмножестве вашей полной цели. Это также даст вам представление о том, где должен произойти разрыв.