case против построителей методов, используя именованные параметры по умолчанию - PullRequest
Новая
       10

case против построителей методов, используя именованные параметры по умолчанию

0 голосов
/ 04 мая 2011

Я собирался использовать классы с именованными параметрами по умолчанию в качестве компоновщиков. Для простого примера: 

case class Person(name:String)
case class PersonBob(name:String = "Bob") {
   def build = Person(name)
}
val casePerson = PersonBob("case").build

Но я мог бы также использовать методы: 

object Builder {
  def personBob(name:String = "Bob"):Person = Person(name)
}
val methodPerson = Builder.personBob("method")

Некоторые компромиссы:

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

Другие соображения? Как построить лучшего строителя другим способом?

1 Ответ

0 голосов
/ 04 мая 2011

Я в замешательстве: не является ли фабрика класса запеченных в ящиках всем, что вам здесь нужно, или я что-то упускаю.IOW: 

scala> case class Foo(bar:String="ab")
defined class Foo

scala> val f = Foo()
f: Foo = Foo(ab)

scala> f.bar
res2: String = ab
...