2010-09-24 4 views
0

Il existe une classe nommée "Foo" qui contient normalement plus de 100 champs. C'est un objet domaine et je dois le personnaliser pour chaque client car les spécifications des champs sont presque totalement différentes d'un client à l'autre (pas plus de 10 champs sont identiques). Certains clients ont plus de 200 champs.Besoin d'aide pour la modélisation d'objets de domaine contenant plus de 100 champs

Actuellement, je dois mettre à jour la définition de classe de "Foo" dans IDE selon la spécification pour chaque client. Parce que je dois utiliser ces champs dans "Foo" pour faire un calcul dans la couche de gestion, il est parfois très sujet aux erreurs et prend beaucoup de temps.

Je me demande si quelqu'un connaît une façon élégante de le faire? Par exemple, je peux écrire toute la définition des champs (nom, type, longueur, valeur par défaut, échelle, précision, formule de calcul (principalement + - * /)) en dehors du code java (supposer un fichier xml), puis utiliser un outil générer le code source Java. Après cela, je compile et empaquette le code généré sous forme de foo-customized.jar et le place dans mon application.

+1

Avez-vous essayé l'application des règles UML de base au-dessus de cette exigence? Vous devriez obtenir plus de classes IMO. –

Répondre

2

Ne générez pas le Java.

Si c'est extrême, faites le XML pour définir les données appropriées par client. Puis construisez des objets Field à partir des données XML. Mettez-les dans une carte à Foo. Maintenant, au lieu de foo.getName(), vous utiliserez foo.get ("nom");

Créez une fabrique qui lit le fichier XML approprié et vous renvoie une instance de Foo chargée à partir du fichier XML.

Essayer de mettre différentes données dans la même classe est très impropre.


Vous pouvez aussi créer des classes spécifiques à chaque client. Oui c'est fastidieux mais il suffit de le faire une fois. Ceux-ci devraient implémenter une interface qui spécifie toutes les méthodes nécessaires dans la couche de gestion. Maintenant, votre usine détermine ce qui est approprié, l'instancie et renvoie l'interface.

Maintenant, votre couche de gestion ignore le client. C'est une bonne chose.

Maintenant, si votre couche d'affaires est très dépendante du client alors que nous pouvons faire un peu plus pour soulager la douleur ...

+0

_ Essayer de mettre différentes données dans la même classe est très impropre. Je n'essaie pas de dire que c'est une solution structurelle - c'est un quasi-hack qui peut vous permettre de répondre à vos besoins. –

+0

Merci, Tony. La première solution est exactement ce que j'essaie de comprendre. Je vais implémenter un conteneur hétérogène pour ce "Foo" qui peut contenir différents types de champs. La deuxième solution: l'interface est bonne, mais dans mon cas, il est vraiment difficile d'extraire une interface que Foos concret peut implémenter. Plus de réflexions: Comment puis-je gérer les calculs? Est-il possible de définir une formule pour un champ au lieu de coder en dur le calcul dans la méthode getter si les variables dans la formule se réfèrent uniquement aux champs de Foo lui-même? –

+0

Nous avons deux problèmes. 1. comment gérer 100 champs. Je pense que nous avons ce matraqué dans la soumission pour l'instant. Mais, soyez ouvert d'esprit sur une solution plus concrète. 2. Comment exécuter la logique métier. Maintenant, quelles sortes de choses calculez-vous? Calculez-vous la valeur pour tous les clients (peut-être différemment, mais c'est bon ...) Où je vais, nous aurons besoin d'un moyen élégant de déterminer les méthodes d'affaires à appeler. –

2

Je pense que vous devez prendre du temps et essayer de mieux comprendre (ou au moins expliquer) ce que cette classe a l'intention de capturer. Quel objet dans le monde réel correspond cette classe? Il est certain qu'il y a beaucoup de champs dans ces centaines de champs qui ne sont pas réellement liés les uns aux autres, ou qui pourraient être groupés en leurs propres classes - comme (je suppose) plusieurs champs individuels qui pourraient être groupés en un Address classe.

Je ne peux pas imaginer un "objet" qui a vraiment 100s de champs/propriétés.

+0

@Sagar V @matt b Merci. :) J'ai déjà essayé ça. En fait, Foo a plusieurs composants, tels que A, B, C ..., le nom des composants ne doit pas être changé pour chaque client, mais toutes les définitions de champs doivent être changées. Donc, le regroupement de ces champs ou non est la même charge de travail, sauf OO. –

+0

_Je ne peux pas imaginer un "objet" qui a vraiment 100s de champs/propriétés._ ouais. J'ai vu des applications où les clients voulaient marteler beaucoup de données et ils se fichaient de la structure.Ils veulent le faire comme ils l'ont toujours fait, de la façon qui exige le moins d'entraînement. La façon dont cela ressemble à l'ancienne forme de papier. J'ai eu des applications qui avaient des centaines de champs sur eux. Le client a insisté sur le fait que c'était ce qu'ils voulaient, et quand j'ai livré, ils étaient ravis./shrug –

+0

* le nom du composant lui-même ne doit pas être changé pour chaque client, mais toutes les définitions de champs doivent être changées * ce qui signifie que vous devez continuer à changer les champs des composants eux-mêmes? Il semble que les données modélisées dans ces composants ne soient pas assez abstraites à ce moment-là. Dans un monde idéal, vous seriez capable de modéliser ces données/applications de telle sorte que la structure ne change pas par client, seulement les données stockées dans les classes. –

Questions connexes