Comment éviter de passer lorsque l'on essaie d'étendre un objet Java

Question

Je reçois plusieurs objets de type Foo à partir d'un appel à une API externe.En local je veux traiter ces objets avec un peu d'informations donc, j'ai une sous-classe FooSon qui ajoute les champs supplémentaires.Comment puis-je convertir tous ces objets que je reçois, à mon nouveau type héréditaire?Passer ne semble pas être une option, car ces objets ne sont pas vraiment FooSon.

La seule solution que j'ai est la création d'une fonction de conversion qui prend l' Foo objet comme argument et copie tous publics/valeurs protégées pour une nouvelle FooSon objet qui est ensuite renvoyé.

Les inconvénients sont les suivants:

• De perdre de l'information (valeurs privées)
• Avoir à adapter la fonction de conversion si Foo est jamais modifié.

La classe Foo n'est pas mise en œuvre d'un constructeur de copie ou de clone de l'opérateur.J'ai le Foo code source, mais je voudrais éviter de le changer afin de maintenir la compatibilité avec les futures versions.Néanmoins, si c'est la seule alternative viable je voudrais changer les Foo mise en œuvre pour obtenir ce dont j'ai besoin.

Answer 1

Fooson pourrait avoir un champ dedans c'est une foo.Ensuite, il suffit d'attribuer la valeur renvoyée dans ce champ.Vous pouvez ensuite créer des méthodes dans FOOSON qui déléguent leurs appels vers le champ FOO pour les informations dont vous avez besoin de la FOO de l'extérieur.

Answer 2

Je pense que le motif de décorateur devrait fonctionner ici:

class Foo implements FooApi {...}

class FooSon implements FooApi {
    private FooApi decoratedFoo;
    private String additional;

    public FooSon(FooApi decoratedFoo) {
        this.decoratedFoo = decoratedFoo;
    }
    ...
}

Mais vous ne pouvez le faire que si vous avez une interface pour votre objet FOO.

Answer 3

Peut-être que je n'ai pas complètement compris le problème, mais pourquoi au lieu de sous-classement FOO (héritage) ne vous stockez-vous pas comme un type de champ en Fooson (composition)?

En anycasse, si vous ne pouvez pas modifier le contrôle d'accès à FOO Type, car les objets sont définis dans une bibliothèque externe, vous ne pouvez pas obtenir un accès direct aux champs privés (c'est exactement la propriété d'un champ privé).Si ces champs privés sont accessibles à partir de la méthode des getters and Setters, enveloppez ainsi cette méthode de votre classe Fooson.

Answer 4

Eh bien, comme vous l'avez déjà découvert en bas de la coulée n'est pas applicable dans cette situation.Je vois les options suivantes:

• La bibliothèque externe fournit une usine mécanisme que vous pourriez utiliser pour le faire instancier FooSon au lieu de cela Foo.

• Le destinataire des enveloppements Foo les objets en FooSon objets, éventuellement à l'aide du schéma délégataire.

• Le destinataire logiquement attache de l'information supplémentaire pour Foo les objets à l'aide d'une carte avec Foo en tant que clé.

Answer 5

Vous ne devriez pas être baissé, vous n'avez aucune garantie qu'il réussira et il y a de meilleurs moyens de faire face à ce problème. Pour un, vous pouvez envelopper l'objet FOO dans une autre classe et déléguer les rappels de méthode appropriés à l'objet FOO.

Je vous suggère de prendre du temps pour vous assurer de bien comprendre des concepts de base OO. En particulier, Google pour "Composition par rapport à l'héritage", ce lien semble être une explication décente.