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

믿지 않습니다. 문제가 있으면 예외가 발생합니다. 이 예외는 xx 인터페이스 xx를 호출하여 발생했음을 나타냅니다. 당신을 찾기 위해. . .

Answer 2

사실 당신은 이미 답을 알고 있지만, 이렇게 코드를 작성하는 것이 너무 피곤하다고 느끼고, 누군가가 "필요없다"고 말해주기를 원합니다.

그러나 당신도 사실을 알고 있습니다.

이 문제와 다소 유사한 점은 프런트 엔드에서 전송된 데이터를 절대 신뢰하지 않는다는 것입니다.
마찬가지로, 회사 내에 규범이 없고 모든 사람의 기술 수준이 다양하다면 이러한 불신감은 더욱 커질 것입니다. 작성된 최종 코드는 비즈니스 코드 라인을 작성하기 위해 여러 계층의 방어 코드로 둘러싸여 있을 수 있습니다. 이 프로젝트의 유지관리 비용은 점점 더 높아질 것입니다.
이 문제가 자주 발생하면 상위 수준의 문제 해결을 상위 리더십에 맡겨야 합니다.

개인 의견:
Result에 errorCode 필드를 추가하면 데이터를 검색하는 사람이 이 값을 기준으로 반환된 결과가 적법한지 여부를 판단하게 됩니다.

전제 조건:
1. errorCode=0은 합법적이고 나머지는 불법입니다.

가정:
1. 반환된 Result은 null입니다. 개인적으로 이 상황은 warning 수준에 속한다고 생각합니다(그런데 대부분의 프로그래머가 warning를 무시한다고 들었습니다. ), 이러한 상황이 발생하면 인터페이스 제공자에게 질문을 제기하고 상대방이
반환 값을 표준화하도록 제안하는 것이 좋습니다. 2. 반환된 Result은 null 및 errorCode=0이 아니지만; productId은 여전히 ​​0입니다: 이 상황은 error 수준에 도달했으며 상대방과 진지한 협상이 필요합니다. 이때:
a) 상대방과 다툴 자신이 있으면 그냥 하십시오.
b) a가 작동하지 않으면 상사에게 문제를 보고하고 문제 해결에 도움을 요청하세요.
c) b가 작동하지 않으면 가능하면 계속하고, 없으면 떠나십시오. 캔트.

Answer 3

제가 운전을 배울 때 코치님이 "다른 사람의 운전 실력을 절대 믿지 마세요."라고 말씀하셨죠. 마찬가지로, 서로 동의하고 이메일로 확인하지 않는 한 다른 돼지 팀원들이 엄격한 코드를 작성하는 것을 절대 믿지 마세요. 다양한 상황.

Answer 4

아, 바로 이것이 코드 중복을 일으키는 이유입니다. 사전에 논의하는 것이 가장 좋습니다

Answer 5

1. 은 인터페이스의 의미가 "skuId을 통해 제품 세부정보 가져오기"인 경우 비즈니스 시나리오에 따라 결정됩니다. 이 비즈니스 시나리오에서 서비스 제공업체의 경우 skuId을 전달합니다. 시스템에 존재하지 않는 🎜>인 경우 인터페이스가 null을 반환하는 것이 합리적이므로 여기서는 Result

에 대해 null 판단을 수행해야 합니다.

2. Result의 productId가 비어 있어야 하는지, 인터페이스 서비스 제공업체에 문의해야 합니다(productId가 비어 있는지). 저는 개인적으로 외부에 노출된 인터페이스와 필드를 추천합니다. 반환된 엔터티에 나타나는 값은 의미가 있는지 확인해야 합니다. 예를 들어 비즈니스 측면에서 productId는 비어 있으면 안 되며, 인터페이스에서 반환된 엔터티에 이 필드가 포함되어 있으면 이 필드가 비어 있으면 안 됩니다. 비어 있음)

3. 포스터에는 프로그래머의 트랜잭션이 원자성을 보장하지 않는 경우 두 부분으로 나누어서 해결해야 한다고 나와 있습니다. 문제가 발생하면 빠른 복구를 위해서는 productId가 비어 있어서는 안 됩니다. 온라인으로BUG, 마지막 긴급 버전을 처리하여 null 판정을 하도록 합니다. 일반적인 상황에서는 null 판정을 할 필요가 없으므로 최대한 빨리 오류가 노출될 수 있습니다

4. 본 서비스가 귀하에게 약하게 의존적인 서비스인 경우, 서비스 제공자 인터페이스가 표준화된 방식으로 작성되지 않더라도 귀하에게 영향을 미치지 않도록 필요에 따라 이 불안정한 인터페이스를 다운그레이드하는 것이 좋습니다. 과정 그 자체

Answer 6

많은 사람들이 규칙을 어기고 규칙에 어긋나는 일을 하기를 좋아하기 때문에 인터페이스를 신뢰할 수 없다고 생각합니다.

그러나 인터페이스를 정의하는 목적은 구현된 클래스가 규칙에 따라 작동하도록 하는 것입니다. 따라서 먼저 신뢰하는 태도를 취해야 합니다.

물론 누구나, 어떤 프로그램이든 실수할 수 있습니다. 실제로 인터페이스 구현에 오류가 있는 경우 상대방이 수정하기를 기다리기 전에 BUG 보고서를 구현자에게 제출해야 합니다. 오류를 방지하려면 자신의 코드를 사용하세요. 그러나 이는 임시 해결책이므로 주석을 통해 언급해야 합니다. 임시 코드의 이 부분은 인터페이스 구현자가 BUG를 수정한 후에 제거됩니다(절대로 제거되지 않을 가능성을 배제하지는 않지만 주석에서 설명할 것입니다). 미래 세대에 대한 이유).

일반적으로 규칙을 따르고 신뢰에 중점을 둡니다. 그러나 일부 인터페이스 구현 오류를 처리하기 위해 임시 코드가 필요할 수도 있다는 점을 배제할 수는 없습니다.

추가 사항: 문서화된 인터페이스가 없습니다. 즉, 규칙이 불분명합니다. 규칙이 불분명하면 모든 상황을 고려할 수밖에 없으며 이는 불신에 해당합니다.

Answer 7

판단을 해 보시는 것이 좋습니다. 프라이빗 메소드로 분리하세요.

Answer 8

프로그램에는 컨텍스트가 있고 인터페이스가 표준화되어 있습니다. 특정 기능을 구현하기 전에 모두가 관련 합의를 했기 때문에 NullPointerException를 방지하려면 맹목적으로 코드를 작성하는 대신 사양에 따라 구현해야 합니다.

Answer 9

으아악

Answer 10

JDK8 또는 Guava의 Optional이 조금 도움이 될 수 있습니다