Scala сочетает функциональное и объектно-ориентированное программирование многими приятными способами. Вы можете использовать обе FP как OO-подобные конструкции, в зависимости от того, что лучше подходит для текущей задачи Но всегда есть возможности для улучшения! Вот одна вещь, я думаю, отсутствует ( короткая версия внизу).
Сторона FP
В Scala легко преобразовать метод в функцию. Например, если у вас есть метод:
мы можем получить соответствующую функцию, используя символ подчеркивания:
Кроме того, Scala поддерживает несколько списков параметров, которые иногда также называют каррированием и которые облегчают частичное применение:
Оо сторона
В каждом классе есть конструктор. Но что на самом деле конструктор? Вы даете значения для аргументов конструктора и получаете взамен новый экземпляр класса. Так что это действительно просто функция!
Ссылка на сайт?
Однако в Scala комбинация OO и FP терпит неудачу: вы не можете использовать две функции методов (преобразование в функцию, каррирование), упомянутые выше, с конструкторами. Оба из них не будут работать :
Вы можете обойти это, используя сопутствующие объекты и применить (или любой другой фабричный метод, применить просто имеет более хорошие обозначения впоследствии):
Но для этого нужно повторить подпись конструктора в объекте-компаньоне, и никто не любит дублирование кода, верно? ?
Использование регистра
Где это может быть полезно? Например в классическом заводском примере. Представьте, что у вас есть класс, который зависит от некоторых служб, а также от некоторых данных, доступных во время выполнения. Конечно, мы используем IoC, поэтому экземпляры других сервисов предоставляются нашему классу:
Это также связано с моим постом о DI и OO , а также о том, как современные структуры DI затрудняют определение сервисов, которые зависят от данных и сервисов, для которых мы хотели бы иметь несколько копий.
Примечание
При просмотре конструкторов как методов / функций (какими они на самом деле являются;)), я предполагаю Ruby-подобную нотацию:
было бы лучше, и добавление поддержки _ и нескольких списков параметров было бы очевидно.
Итог для поклонников TL; DR
Почему бы не рассматривать конструкторы классов как любой другой метод / функцию? Сделайте это законным:
Адам