Est-il possible d'étendre un objet?

En scala, nous ne pouvons pas prolonger object:

object X 
object Y extends X

donne une erreur error: not found: type X

Dans mon cas, quelqu'un a défini certaines fonctionnalités dans un objet et j'ai besoin de l'étendre (essentiellement ajouter une autre méthode). Quel serait le moyen le plus facile d'étendre cet objet?

InformationsquelleAutor Jus12 | 2011-10-02

scala

80

Comme c'est souvent la bonne réponse dépend de la réelle exigence de l'entreprise. S'étendant à partir d'un objet dans un certain sens, défier le but de cet objet, car il ne serait pas un singleton plus.

Ce qui pourrait être une solution est d'extraire le comportement dans l'abstraction d'un trait. Et de créer des objets à l'extension de ce trait de caractère, comme suit:
```
trait T{
    //some behavior goes here
}

object X extends T

object Y extends T {
    //additional stuff here
}
```
- C'est ce que j'ai fait. Il fait réellement sens pour ne pas être en mesure d'étendre un objet en raison de l'singleton exigence.
- Le problème, c'est que X et Y ont pas de sous-classement de la relation, qui était la raison de la sous-classe à la première place.
InformationsquelleAutor Jens Schauder
34

Si vous souhaitez utiliser des méthodes et des valeurs à partir d'un autre objet, vous pouvez utiliser de l'importation.
```
object X{
  def x = 5
}

object Y{
  import X._
  val y = x
}
```
- Ma façon préférable d'. Aussi, j'aime la façon dont il composites dans le code. Très lisible.
InformationsquelleAutor YoK
11

Vous ne pouvez pas étendre un objet, parce que ce serait de créer deux, et un objet, par définition, n'existe qu'une seule fois (edit: eh bien, ce n'est pas tout à fait vrai, parce que la définition de l'objet peut être dans une classe ou une méthode).

Pour vos besoins, essayez ceci:
```
object X {
}

object Y {
    def a = 5
}

implicit def xToY(x: X.type) = Y

println(X.a)
```
Il ne fait pas les étendre, mais il ne vous permet pas d'appeler à de nouvelles méthodes sur ce qu'ont été initialement définies.
- IMO, c'est le mal, ne jamais utiliser les conversions implicites comme ça ou vous vous demandez quels sont les problèmes.
- Première phrase est dénuée de sens.
- Pouvez-vous donner une explication pour cela?
- Je voudrais aussi savoir pourquoi c'est mal.
- Je pense que le problème est que lors de la lecture de quelqu'un de code et de voir X.a, il est plus difficile de trouver ce X.a fait référence, parce que vous avez besoin de savoir ce que implicites sont dans la portée. Au moins, c'est ce qui me frustre à ce sujet. Mais j'ai pensé que je voudrais vous suggérer de toute façon.
- En général, les conversions implicites doivent être utilisés avec précaution. Comme @Owen l'a dit, ils ne de rendre votre code plus difficile à lire. Souvent, il est difficile de savoir ce que l'implicite est appliquée à un endroit donné (n'oubliez pas que les règles implicites de la résolution sont très impliqués, et il pourrait être très difficile de deviner lequel est appliqué en regardant uniquement la source. Cependant, les choses vont certainement s'améliorer lorsque IDEs soutien implicite mettre en évidence). Mais dans ce cas, la principale raison est tout simplement que X devrait vraiment pas être considéré comme Y, vous voulez vraiment savoir lequel vous manipulez.
- Pour la question que l'OP demande, l'implicite, à partir de Y à X, que l'objectif était de disposer d'Y étendre X, de ne pas forcer un objet préexistant X pour avoir des fonctionnalités supplémentaires. Implicitement, la modification d'un objet existant serait beaucoup plus risqué que d'en créer un nouveau qui toujours hérite de certaines fonctionnalités en passant par les conversions automatiques, à condition que ces conversions automatiques doivent toujours être importés avec le nouvel objet, donc on n'a pas à examiner si la conversion automatique dans le champ.
- Il y aurait une grande différence entre cette conception et OO-héritage, mais...auto-appels par X serait encore pour X, et non pas à la redéfinition de méthodes Y.
InformationsquelleAutor Owen
6

La seule façon de partager du code entre deux objets, c'est d'avoir un ou plusieurs super-classe/trait.
- Non, ce changement permet à un membre de l'objet de la super-classe d'être écrasé par un membre de l'objet dans une sous-classe. class A { object a }; class B extends A { override object a }; ((new B): A).a // access B.a
- Oups, merci pour la correction de moi.
InformationsquelleAutor Mirco Dotta
2

Vous pouvez convertir des parents en classe + compagnon de l'objet, puis demander à l'enfant de s'étendre de la classe E. g.

dans le Parent.scala
```
class Parent {}

object Parent extends Parent {}
```
Puis de l'Enfant.scala
```
object Child extends Parent {}
```
Oui, c'est plus un hack qu'une solution.

InformationsquelleAutor Stevo Slavić
1

Noter qu'avec Dotty (fondation de Scala 3), vous pouvez également utiliser la composition (au lieu de l'héritage) via l'exportation des clauses qui permettent de définir des alias pour les membres sélectionnés de l'objet:
```
object X { def f = 5 }

object Y {
  export X._
  def g = 42
  def h = f * g
}

Y.f //5
Y.g //42
Y.h //210
```
Notez que vous pouvez également limiter le nombre de membres que vous souhaitez exporter:
```
object X { def f = 5; def g = 6 }
object Y { export X.f }
Y.f //5
Y.g
^^^
value g is not a member of Y
```
InformationsquelleAutor Xavier Guihot

Vous devez vous connecter pour publier un commentaire.