Шаблон пирога Scala для объектов с разным временем жизни

Рассматривали ли вы следующие альтернативы:

• Используйте внутренние классы в Scala, так как они автоматически имеют доступ к своим переменным-членам родительского класса.

• Реструктуризация вашего приложения на основе актора, потому что вы сразу же получите следующие преимущества:

  • Hierarchy / supervision
  • Прослушивание создания/смерти компонентов
  • Правильная синхронизация, когда дело доходит до доступа к изменяемому состоянию

Вероятно, будет полезно иметь еще немного кода, чтобы обеспечить лучшее решение. Можете ли вы поделиться компилируемым подмножеством вашего кода?

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

у нас есть:

trait FooBarInterface {
    def printFoo: Unit
    def printBar: Unit
}

trait PrinterInterface {
    //def color: RGB
    def print(s: String): Unit
}

Для внедрения логики fooBar шаблон торта определяет:

trait FooBarComponent { 
    //The components being used in this component:
    self: PrinterComponent => 

    //Ways for other components accessing this dependency.    
    def fooBarComp: FooBarInterface

    //The implementation of FooBarInterface 
    class FooBarImpl extends FooBarInterface {
        def printFoo = printComp.print("fOo")
        def printBar = printComp.print("BaR")
    }
}

Обратите внимание, что эта реализация не оставляет ни одного поля нереализованным, и когда дело доходит до смешивания всех этих компонентов вместе, у нас будет: val fooBarComp = new FooBarImpl. В тех случаях, когда у нас есть только одна реализация, нам не нужно оставлять fooBarComp нереализованным. вместо этого мы можем иметь:

trait FooBarComponent { 
    //The components being used in this component:
    self: PrinterComponent => 

    //Ways for other components accessing this dependency.    
    def fooBarComp: new FooBarInterface {
        def printFoo = printComp.print("fOo")
        def printBar = printComp.print("BaR")
    }
}

Не все компоненты такие. Например, Printer, зависимость, используемая для печати foo или bar, должна быть настроена, и вы хотите иметь возможность печатать текст разными цветами. Таким образом, зависимость может потребоваться для динамического изменения или установки в какой-то момент программы.

trait PrintComponent {

    def printComp: PrinterInterface

    class PrinterImpl(val color: RGB) extends PrinterInterface {
        def print(s:String) = ...
    }
}

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

val printComp = PrinterImpl(Blue)

Теперь поля для доступа к зависимостям не обязательно должны быть простыми значениями. Это могут быть функции, которые принимают некоторые параметры конструктора реализации зависимости, чтобы вернуть ее экземпляр. Например, у нас может быть Baz с интерфейсом:

trait BazInterface {
    def appendString: String
    def printBar(s: String): Unit
}

и компонент формы:

trait BazComponent { 
    //The components being used in this component:
    self: PrinterComponent => 

    //Ways for other components accessing this dependency.    
    def bazComp(appendString: String) : Baz = new BazImpl(appendString)

    //The implementation of BazInterface 
    class BazImpl(val appendString: String) extends BazInterface {
        def printBaz = printComp.print("baZ" + appendString)
    }
}

Теперь, если бы у нас был компонент FooBarBaz, мы могли бы определить:

trait FooBarBazComponent { 
    //The components being used in this component:
    self: BazComponent with FooBarComponent => 

    val baz = bazComp("***")
    val fooBar = fooBarComp

    //The implementation of BazInterface
    class BazImpl(val appendString: String) extends BazInterface {
        def PrintFooBarBaz = {
            baz.printBaz()
            fooBar.printFooBar()
        }
    }
}

Итак, мы увидели, как можно настроить компонент:

• статически. (в основном зависимости очень низкого уровня)
• изнутри другого компонента. (обычно это один бизнес-уровень, настраивающий другой бизнес-уровень, см. «ЗАВИСИМОСТИ, КОТОРЫЕ ТРЕБУЮТ ПОЛЬЗОВАТЕЛЬСКИЕ ДАННЫЕ» в здесь)

Что отличалось в этих двух случаях, так это просто место, где происходит конфигурация. Один предназначен для низкоуровневых зависимостей на самом верхнем уровне программы, другой — для промежуточного компонента, настраиваемого внутри другого компонента. Вопрос в том, где должна происходить настройка такой службы, как Print? Два варианта, которые мы исследовали до сих пор, исключены. На мой взгляд, единственный вариант, который у нас есть, — это добавить Components-Configurer, который смешивает все компоненты, которые нужно настроить, и возвращает компоненты зависимостей, изменяя реализации. Вот простая версия:

trait UICustomiserComponent {
    this: PrintComponent =>

    private var printCompCache: PrintInterface = ???
    def printComp: PrintInterface = printCompCache
}

очевидно, у нас может быть несколько таких компонентов конфигуратора, а не только один.