Каково объяснение позади наличия сопутствующих объектов в Scala?
В этом конкретном случае (заполнение объекта списка сокращениями / именами состояний) вам лучше будет использовать предварительно созданный объект geographyV2 или предварительно созданный объект домена Places.AbsoluteLocation. (Обратите внимание, что на момент написания этой статьи у предварительно созданного объекта geographyV2 была небольшая ошибка, поэтому лучше использовать предварительно созданный объект домена).
Причина этого двоякая:
Во-первых, географические местоположения уже запечены в LUIS, и они не сталкиваются с обычными синтаксическими словами, такими как «in», «hi» или «me». , Я проверил это в обратном порядке, создав список [Medical], который содержал «ct» в качестве нормализованного значения и «ct scan» в качестве синонима. Когда я набрал «получить мне КТ в КТ», это привело к «получить меня [медицинский] в [медицинский]». Чтобы исправить это, я выбрал второе значение «CT» и переназначил его для объекта Places.AbsoluteLocation. После переподготовки я проверил «когда в КТ показывают мне опции ct», что правильно привело к «когда в [Places.AbsoluteLocation] покажут мне [медицинские] опции». Дальнейшие примеры и обучение улучшат результаты.
Во-вторых, списки работают хорошо для слов, которые имеют разные слова, которые могут ссылаться на один. В этом уроке показан простой пример, в котором слабо связанные слова назначаются в качестве синонимов каноническому имени (нормализованное значение).
Надежда на помощь!
4 ответа
Сопутствующий объект в основном обеспечивает место, куда можно поместить "подобные помехам" методы. Кроме того, сопутствующий объект или сопутствующий модуль, имеет полный доступ к участникам класса, включая частные.
Сопутствующие объекты являются большими для инкапсуляции вещей как методы фабрики. Вместо того, чтобы иметь необходимость иметь, например, Foo и FooFactory везде, у Вас может быть класс с сопутствующим объектом, берут обязанности по фабрике.
... и это - хорошее место для хранения статических методов фабрики (не что DP) для сопровождаемых классов. Если Вы называете те перегруженные методы фабрики, применяются (/... /) Вы будете в состоянии создать/инициализировать Вас класс
-
без 'нового' (не действительно настолько важный)
-
с различными возможными наборами параметров (сравните с тем, что Bloch пишет в Эффективном Java о складывании конструктора)
-
со способностью к решить, какой производный класс, который Вы хотите создать вместо краткого обзора (сопровождал) один
Пример кода:
abstract class AbstractClass;
class RealThing(s: String) extends AbstractClass;
class AlternativeThing(i: Int) extends AbstractClass;
object AbstractClass {
def apply(s: String) = {
new RealThing(s)
}
def apply(i: Int) = {
new AlternativeThing(i)
}
}
// somewhere else you can
val vs = AbstractClass("asdf") // gives you the RealThing wrapped over string
val vi = AbstractClass(123) // gives you AlternativeThing wrapped over int
я не назвал бы объект/базовый класс AbstractXxxxx, потому что он не делает выглядит плохо: как создание чего-то абстрактного. Дайте тем именам реальное значение. Рассмотрите использование неизменный, метод меньше, классы случая и изолируйте абстрактный базовый класс.
В дополнение к вещам Saem заявил в его ответ , компилятор Scala также ищет неявные преобразования из типов в соответствующих сопутствующих объектах (или источника или цели), таким образом, преобразования не должны быть импортированы.
О причине одноэлементных объектов в общем Программирование в Scala говорит:
, Как упомянуто в Главе 1, один путь, которым Scala более объектно-ориентирован, чем Java, состоит в том, что классы в Scala не могут иметь статических участников. Вместо этого у Scala есть одноэлементные объекты (p. 65).
Сопутствующие объекты полезны для хранения состояния и методов, общих для всех экземпляров класса , но они не используют статические методы или поля. Они используют обычные виртуальные методы, которые можно переопределить посредством наследования. В Scala действительно нет ничего статичного. Есть много способов использовать это, но вот простой пример.
abstract class AnimalCounter
{
var animals = 0
def name: String
def count()
{
animals += 1
println("%d %ss created so far".format(animals, name))
}
}
abstract class Animal
{
def companion: AnimalCounter
companion.count()
}
object Dog extends AnimalCounter
{
val name = "dog"
}
class Dog extends Animal
{
def companion = Dog
}
object Cat extends AnimalCounter
{
val name = "cat"
}
class Cat extends Animal
{
def companion = Cat
}
В результате получается такой результат:
scala> new Dog
1 dogs created so far
scala> new Cat
1 cats created so far
scala> new Dog
2 dogs created so far
scala> new Cat
2 cats created so far