Quelle est la meilleure pratique pour faire référence à des objets imbriqués?
Dites que j'ai ce qui suit: et dans mon contrôleur ou classe de service, j'ai besoin de vérifier les sulstions Chaîne variable de la classe innerb pour s'assurer qu'elle n'est pas nulle ou non vide, alors je le fais: pour moi cela semble désordonné et pourrait avoir des problèmes si les objets imbriqués eux-mêmes. SONT NULL. DO I Créer des getters Setteurs ANS dans les objets parents pour les objets enfants vérifiant pour NULL? Je me demandais simplement ce que la meilleure pratique était la suivante et / ou sur ce que certains d'entre vous font dans votre code?
11 Réponses :
Je ne pense pas que les utilisateurs d'extérieur devraient avoir une connaissance de l'extérieur.innera.innerb.someString - il est enterré de profondément. Vous ne pouvez pas modifier la mise en œuvre de InnerB sans toucher les clients de niveaux extérieurs 3 séparés - alors quel est le point de même avoir des classes intérieures? Les situations comme si vous décrivez sont laides et ne devraient pas survenir.
Je vous recommanderais d'abord de déterminer si une sulstation appartient à Innerb ou innera ou externe.
Supposons maintenant que votre hiérarchie est correcte, mais si SaString a cette propriété unique d'être requise par des clients extérieurs (si une personne n'est pas unique de cette façon, la hiérarchie est définitivement fausse). Dans ce cas, externe.getsomestring () ou mieux encore, extérieur.issomestringNullorempty (), de sorte que, de sorte que, au moins, les clients d'extérieur ne soient pas obligés de savoir sur Innera et Innerb
ps. sulsinging.equalsignorecase ("") coûte cher, n'utilisez pas ça. Beaucoup moins cher est une sapestring.Length () == 0
C'est désordonné, mais si vous n'aviez que je devais le faire au même endroit, je pourrais vivre avec elle. Sinon, je voudrais implémenter un Cela vous permet également de traiter un cas où l'une des classes intermédiaires intermédiaires est NULL, sans avoir à effectuer un certain nombre de contrôles séquentiels chaque fois que vous essayez d'accéder à externe.getsomestring () qui masque le chemin interne, car votre classe externe est celle que vous exposez comme interface.
suls . .
Si l'un de ces objets peut être null, vous devez vérifier NULL avant d'appeler un getter sur cet objet, bien sûr.
Mais ce type de chaînage est une mauvaise odeur d'un manque d'encapsulation (objets anémiques ayant simplement des données, et aucun comportement). Vous violez le Law of Demeter : Ne parlez pas à des étrangers.
Alors, persondao.geperson (123) .getaddress (). getcity (). LoadMap () est une erreur?
JB NIZET Pouvez-vous commenter Nishant question s'il vous plaît?
C'est une odeur, ce n'est pas une preuve. Et la loi de Demeter est un principe, qui est souvent bon à suivre, mais pas nécessairement toujours. Il présente des avantages et des inconvénients. Dans le cas de Nishant exemple, vous pourriez avoir une chariot () directement en personne, déléguer à son adresse. Il pourrait même mettre en œuvre une interface mappable. L'exemple de l'OP est un peu différent, car tout cela est accessible aux données.
Vous avez deux options:
ma conviction est que vous ne devriez pas exposer les éléments "interne-interne" par des procédés de la classe extérieure, à moins que vous ajoutez une sorte de fonctionnalité ou de comportement différent, ou la valeur est «essentielle» à l'utilisation de la classe extérieure. . Cependant, il s'agit également d'une question de jugement et peut varier en fonction de l'utilisation et de l'architecture de votre code.
sur une note latérale Si vous voulez que le code d'une longue chaîne d'invocations soit "moins laide", je suggère de voter pour ajouter le elvis opérateur pour la pièce de monnaie de projet dans la prochaine version de Java (j'aimerais qu'il en avait fait en 7: - ().
Vous pouvez utiliser Apache Commons Beantutils pour naviguer dans vos propriétés imbriquées comme ceci:
Méthode Ajouter Je ne me souviens pas si ce J'espère que cela vous aide! Getsomestring () à votre classe extérieure et écrivez quelque chose comme
propertériceutils.getneSProperty (ceci, "innera.innerb.somestring");
Procienticules CLASSE Cochez Null Properties, mais je regarderais Apache Commons Beantutils Site.
Je recommanderais de lire sur le Loi de Demeter .
Je recommanderais de devenir familier avec le monde merveilleux des documents XML mappés dans les pojos. Juste un exemple où LOD n'est pas applicable du tout.
J'ai écrit une méthode Java 8: maintenant, vous pouvez appeler: p> si C'est assez utile, si vous devez simplement aller un niveau plus profond. p> pour plusieurs niveaux, il devient laid: p> MyObject.getsomeObject () code> est null code> La méthode retournera null code>, alors qu'il appelle myObject.getsomeotherObject (). Tostring () code>. Helper.returnNullOrCallFunction(
Helper.returnNullOrCallFunction(
myObject.getSomeOtherObject(),
SomeOtherObject::getAnotherObject
),
AnotherObject::toString
);
Ceci est une limitation de Java. Vous devez implémenter des méthodes d'assistant dans le parent "OUTEROBJECT" si cela vous aide à réduire la duplication de code.
Ces méthodes d'assistance sont utiles pour l'objet qui regroupant un autre objet et que vous devez vérifier uniquement si la valeur imbriquée n'existe pas. P >
code: p> qui ferait toutes les vérifications nulles. p> Ce problème se produit souvent avec des objets générés à partir de * .xsd.
Dans une structure XML compliquée, cela se produit souvent qu'il existe un nombre de nœuds optionnels imbriqués. Et ce qui est généralement intéressant, c'est le dernier nœud.
Ensuite, il est préférable d'écrire des méthodes d'assistant qui répondront aux questions si le nœud existe pour la réutilisation. P> S'il appartient à votre échantillon de morde, j'écris habituellement quelque chose comme ça P> if (hasSomeString(getOuter())) {
//do something
}
dans Java 8+, cela peut être géré en utilisant en option code> .
String value = Optional.ofNullable(outer).map(x -> x.getInnerA())
.map(x -> x.getInnerB()).map(x -> x.getSomeString())
.orElse(DEFAULT_VALUE);
Depuis la sortie de Java SE 8 (mars 2014), il est recommandé de gérer de tels scénarios.
Si vous utilisez déjà le ressort, considérez beanswrapper ou configurablePropertyAccessor : getPropertyvalue Exception si l'une des propriétés imbriquées est null . Vous pouvez attraper cette exception et retourner ce que vous voulez.