Vous recherchez des commentaires sur une utilisation du motif Adapter

Question

Dans un projet en cours, nous avons une certaine classe de types de valeur dans notre modèle de domaine qui inclut un très grand nombre d'attributs ...

public class BigValueType {
    private Foo foo;
    private Bar bar;
    private Baz baz;

    //...
}

Nous avons compris que nous aimerions & "mettre au point &"; ceci dans un certain nombre de classes différentes, un peu plus spécialisées, qui ne possèdent qu'un sous-ensemble des attributs de cette classe. Je pense que nous aimerions avoir quelque chose comme des & "; Vues &"; de ces données.

public class SpecializationA {
    private Foo foo;
    private Baz baz;
    //...
}

public class SpecializationB {
    private Bar bar;
    private Baz baz;
    //...
}

private class SpecializationC {
    private Foo foo;
    private Bar bar;
    //...
}

Cependant, ce modèle de domaine se veut plutôt général et n'est pas spécifique à ce projet. Des extensions spécifiques à un projet y seront ajoutées lors de futurs projets, mais le modèle de domaine commun restera séparé de ces extensions. Si nous définissons simplement un groupe de classes maintenant, il est probable que d'autres projets utilisant le modèle de domaine devront simplement écrire leurs propres projets légèrement différents par la suite. (Nous ne pouvons pas facilement prédire quelles vues de ces données seront utiles.)

Je pense que ce que nous devrions faire, c'est écrire pour cette grande classe des adaptateurs spécifiques au projet qui présentent les différentes vues des données. Ainsi, les futurs utilisateurs du domaine ne doivent rien toucher dans le & Quot; commun & Quot; modèle de domaine pour définir de nouvelles vues de ces informations.

public class AdapterA {
    private BigValueType wrapped;
    //...

    public ViewA(BigValueType wrapped) {
        //...
    }

    public Foo getFoo() {
        return wrapped.getFoo();
    }

    //...
}

Cela me semble plus logique que l'héritage normal car notre classe / interface de niveau supérieur n'aurait presque rien.

Des commentaires sur cette approche?

Answer 1

Tout d'abord, il est important de comprendre le problème que vous souhaitez résoudre. Avoir une classe avec un grand nombre d'attributs n'est pas nécessairement mauvais et si vous voulez faire le refactoring uniquement pour vous conformer aux "bons" principes de conception, je reconsidérerais la décision.

Ceci étant dit, il s'agit d'un concept assez courant dans le monde de la SOA. Vous avez un grand service qui prend un message complexe avec un assez grand nombre d'attributs comme demande. Ce service est ensuite «adapté» pour répondre aux besoins des clients. Donc, votre conception devrait bien fonctionner. Bien entendu, cela suppose que vous connaissiez déjà toutes les "vues" possibles ou que vous deviez écrire de nouveaux adaptateurs pour les nouveaux clients.

Cette "adaptation" peut être effectuée à deux niveaux - le niveau de l'interface utilisateur (qui est essentiellement votre conception - pour adapter la classe) ou à un niveau inférieur, tel qu'au niveau de la base de données, ce qui modifie votre classe principale aussi. Cela dépend de votre application, des utilisateurs de votre infrastructure, etc.

.

Une autre approche à envisager pourrait également être la méthode REST pour ce faire: exposer les données (Foo, Baz, etc.), bien qu'elles proviennent de la classe principale, et laisser les clients traiter eux-mêmes les données avec la classe principale. fournissant essentiellement des fonctionnalités CRUD sur ces données. Ensuite, votre classe se comporte davantage comme une structure sans véritable logique métier.

N'importe lequel de ces trois approches devrait être acceptable, à mon humble avis.

Answer 2

bien .. me semble bien. Je pense que votre solution utilisant la composition est bien meilleure que l’héritage, elle affectera votre modèle beaucoup de temps et générera beaucoup de classes peu cohérentes.

Answer 3

J'ai constaté que l'objectif de partage de code entre plusieurs projets est plus difficile qu'il n'y paraît. Du moins, il est difficile de le comprendre correctement ! C’est précisément pour les raisons que vous avez évoquées que vous avez évoquées: ne pas savoir exactement quelles fonctionnalités vous pourriez avoir besoin dans un nouveau projet. Le problème est que le problème de l'adaptateur ne résoudra pas le problème à votre place (si les objets sous-jacents ne prennent pas en charge l'ensemble de fonctionnalités requis, c'est-à-dire).

Je vous suggérerais d'utiliser interfaces pour vos projets distincts, mais de coder les implémentations séparément. Si vous vous retrouvez à écrire exactement le même code 3 fois, extrayez-le dans une bibliothèque commune. Essayez de garder votre bibliothèque aussi légère que possible.

La gestion de plusieurs dépendances peut s'avérer coûteuse par la suite, si vous devez ajouter des fonctionnalités - éventuellement en conflit - et que vous avez la complication d'affecter de nombreuses applications.