Каковы преимущества или недостатки объявления функции / метода в сопутствующих объектах по сравнению с объявлением их по признакам? - PullRequest
0 голосов
/ 28 октября 2019

Я новичок в Scala, и теперь я начал проект в Scala, и я вижу похожую на следующую конструкцию:

trait SomeTrait extends SomeOtherStuff with SomeOtherStuff2 

object SomeTrait {
   def someFunction():Unit = { ??? } 
} 

Я понимаю, что для класса сопутствующие объекты содержат методы, которые используются в"static", как методы Factory в Java или что-то подобное, но как насчет черт, почему бы не поместить эти методы в черты?

Ответы [ 2 ]

2 голосов
/ 28 октября 2019

Первый стиль называется mixin, раньше он был несколько популярен.

Его можно заменить следующим кодом:

object SomeOtherStuff {
   def someMethod(): String
}

object SomeObj {
  import SomeOtherStuff._

  //now someMethod is available
  def otherMethod(): String = someMethod + "!"
}

object Caller {
  import SomeObj._
  import SomeOtherStuff._

  //utility methods from both objects are available here
}

Плюсы миксинов:

Если SomeTrait расширяет 10 других миксинов, то расширение этой черты позволит отказаться от 10 import операторов

Минусы миксинов:

1) создает ненужную связь междучерты

2) неудобно использовать, если вызывающий не расширяет сам миксин

Избегать миксины для кода бизнес-логики - безопасный выбор.

Хотя яизвестно о 2 допустимых случаях использования:

1) импорт DSL, например, код ScalaTest:

class SomeSuite extends FunSuite with BeforeAndAfter {...}

2) работа (как автора библиотеки) с неявными параметрами: например, object Clock extends LowPriorityImplicits

(https://github.com/typelevel/cats-effect/blob/master/core/shared/src/main/scala/cats/effect/Clock.scala#L127)

1 голос
/ 29 октября 2019

Другой перспективой этого является принцип ООП «Композиция над наследованием».

Плюсы сопутствующих объектов (композиция) :

  • Композиция может бытьсделано во время выполнения, пока черты определены во время компиляции
  • , вы можете легко иметь несколько из них . Вам не нужно иметь дело с особенностями множественного наследования: скажем, у вас есть две черты, у каждой из которых есть метод с именем foo - какая из них будет использоваться или она будет работать вообще? Для меня проще увидеть делегирование вызова метода, множественное наследование имеет тенденцию очень быстро становиться сложным, потому что вы теряете путь, когда метод был фактически определен

Плюсы признаков (mixins):

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

Сомневаюсь, я предпочитаю сопутствующие объекты, но это всегда зависит от вашей среды.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...