java - 我们该信任接口的返回值吗？

Question

先举个例子

public Result doSomething(String balabala);


public class Result{
    private Long productId;
    ....
}

上面接口是其他部门的程序员提供给你的。没有文档，接口没有注释。
首先，我调用这个接口，

Result result= doSomething("fuck");

调用之后，我要返回的productId再去请求其他接口，做其他一些事情。

问题来了：

1. 对这个返回的result，你是直接result.getProductId(); 还是先判断一下，result！= null 然后再result.getProductId()；那productId又是Result里的引用类型，你拿到productId要不要再productId ！= null
   ，Result还有其他的引用类型，是不是我每用一个非得判空？

可能每个人的习惯不一样，比如写那个接口，有的人是哪怕什么信息都没有返回，也返回一个空的result。有的人是如果没有信息返回就返回null。如果只要是引用类型，我都判断是否为空，是不是显得“过于谨慎”了。文档，注释也不可能规定的那么细，程序员之间的约定吧，那一个几百人的团队，难免会有不遵循约定的。你们是如何处理的？

又比如一条记录，业务上规定，productId不可能为空的，但是这条记录的插入涉及到两条sql语句，一个程序员的失误没有保证原子性，导致productId为空的记录被插入进去了。这时候，我一旦涉及到处理productId，没有判空，则很有可能导致异常

Answer 1

Je n'y crois pas. S'il y a un problème, une exception sera levée. L'exception indique qu'elle est causée par l'appel de l'interface xx xx. De cette façon, s'il y a un problème, nous ne pourrons pas. pour te trouver. . .

Answer 2

En fait, vous connaissez déjà la réponse, mais vous pensez qu'écrire du code comme celui-ci est trop fatiguant, et vous voulez que quelqu'un vous dise "pas besoin".

Cependant, vous connaissez aussi les faits.

Ce problème est quelque peu similaire : ne faites jamais confiance aux données transmises depuis le front-end.
De même, ce sentiment de méfiance sera encore plus grand s'il n'y a pas de normes au sein de l'entreprise et que chacun a des niveaux de compétence différents. Le code final écrit peut être entouré de plusieurs couches de code défensif pour écrire une ligne de code métier. Le coût de maintenance de ce projet deviendra de plus en plus élevé.
Si ce problème se produit fréquemment, il devrait être laissé aux dirigeants de niveau supérieur de résoudre le problème à partir du niveau supérieur.

Opinion personnelle :
Ajoutez un champ Result dans errorCode, puis la personne qui récupère les données jugera si le résultat renvoyé est légal en fonction de cette valeur.

Prérequis :
1. errorCode=0 est légal, les autres sont illégaux

;

Hypothèses :
1. Le Result renvoyé est null : Je pense personnellement que cette situation appartient au niveau warning (mais j'ai entendu dire que la plupart des programmeurs ignorent warning ? ), lorsque vous rencontrez cette situation, il est recommandé de poser une question au fournisseur d'interface et de suggérer à l'autre partie de normaliser la valeur de retour
2. Le Result renvoyé n'est pas null, et errorCode=0, mais productId est toujours nul : Cette situation a atteint le niveau error et nécessite une négociation sérieuse avec l'autre partie à ce moment-là :
a) Si vous avez la confiance nécessaire pour vous disputer avec l'autre partie, faites-le. ;
b) Si a ne fonctionne pas, signalez ensuite le problème à vos supérieurs et demandez-leur de vous aider à résoudre le problème
c) Si b ne fonctionne pas, continuez à le faire si vous le pouvez, et partez si ; tu ne peux pas.

Answer 3

Quand j'apprenais à conduire, l'entraîneur m'a dit : « Ne faites jamais confiance aux compétences de conduite des autres. » De la même manière, ne faites jamais confiance à d'autres coéquipiers cochons pour écrire un code rigoureux, à moins que vous ne soyez d'un commun accord et que vous le confirmiez par e-mail. juger diverses situations.

Answer 4

Hé, c'est précisément cette raison qui provoque la redondance du code. Il est préférable d'en discuter à l'avance

.

Answer 5

1. est déterminé en fonction du scénario commercial, si la signification de l'interface est "obtenir les détails du produit via skuId". Dans ce scénario commercial, pour le fournisseur de services, lorsque nous transmettons un skuId cela. n'existe pas dans le système 🎜>, il est raisonnable que l'interface nous renvoie un null, il faut donc ici effectuer un jugement nul sur Result

Si le
2. dans

   ResultproductId doit être vide, vous devez consulter le fournisseur de services d'interface (si productId est vide, je recommande personnellement les interfaces exposées au monde extérieur et les champs). qui apparaissent dans les entités renvoyées. , il faut s'assurer que la valeur est significative (par exemple, productId ne doit pas être vide en termes métier, puis si l'entité renvoyée par l'interface contient ce champ, ce champ ne doit pas l'être. vide)

3. L'affiche disait que si la transaction du programmeur ne garantit pas l'atomicité, elle doit être résolue en deux parties. La prémisse productId ne doit pas être vide en affaires si un problème survient, afin de réparer rapidement. en ligneBUG, permet de traiter la dernière version urgente pour jugement nul Dans des circonstances normales, il n'est pas nécessaire de juger nul, afin que les erreurs puissent être exposées dans les plus brefs délais

4. Si ce service est un service faiblement dépendant pour vous, il est recommandé de rétrograder cette interface instable lorsque cela est nécessaire, afin que même si l'interface du fournisseur de services n'est pas écrite de manière standardisée, cela ne vous affectera pas. Le processus lui-même

Answer 6

Parce que beaucoup de gens aiment enfreindre les règles et faire les choses non conformément aux règles, ils pensent que les interfaces ne sont pas fiables.

Cependant, les interfaces sont des règles. Le but de la définition d'une interface est de faire en sorte que la classe implémentée agisse selon les règles. Vous devez donc d'abord adopter une attitude de confiance.

Bien sûr, n'importe qui et n'importe quel programme peut faire des erreurs. S'il y a effectivement une erreur dans l'implémentation de l'interface, vous devez soumettre un rapport de BUG à la partie exécutante. Avant d'attendre que l'autre partie la modifie, vous pouvez utiliser votre. propre code pour éviter l’erreur. Cependant, il s'agit d'une solution temporaire et doit être notée dans les commentaires. Cette partie du code temporaire sera supprimée une fois que l'implémenteur de l'interface aura corrigé le BUG (cela n'exclut pas la possibilité qu'elle ne soit jamais supprimée, mais les commentaires l'expliqueront). la raison aux générations futures).

En général, suivez les règles et concentrez-vous sur la confiance. Cependant, il n’est pas exclu que certaines erreurs d’implémentation d’interface nécessitent un code temporaire pour les gérer.

A ajouter : il n'y a pas d'interface documentée, c'est-à-dire que les règles ne sont pas claires. Si les règles ne sont pas claires, alors toutes les situations ne peuvent qu’être envisagées – ce qui équivaut à de la méfiance.

Answer 7

Il est recommandé de porter un jugement. Séparez-vous en une méthode privée.

Answer 8

Les programmes ont un contexte et les interfaces sont standardisées. Tout le monde a conclu des accords pertinents avant d'implémenter une certaine fonction, ils devraient donc être implémentés conformément aux spécifications au lieu d'écrire aveuglément du code pour empêcher NullPointerException.

Answer 9

**既然你们对返回的接口封装了一个类Result ，那么你们可以写一个公共的工具类，来对Result来做检查。**

Answer 10

JDK8 ou Guava de Optional peuvent être un peu utiles