날짜를 반환하는 함수가 있다고 가정 해 보겠습니다.내가 null을 반환하거나 "null 객체"패턴을 Date를 반환하는 함수에 적용해야합니까?
Date myFunc(paramA, paramB){
//conditionally return a date?
}
이 함수에서 null을 반환하는 것이 적절합니까? 클라이언트가 null을 확인해야하기 때문에 이것은보기 흉한 것처럼 보입니다.
"null 객체"패턴은이 문제를 해결하는 구현 패턴입니다.
null 오브젝트 패턴을 좋아하는 팬은 아니지만 그렇습니다. null을 반환하는 대신 비어있는 경우에도 항상 목록을 반환하는 것이 좋습니다.
그러나 Java에서 null 날짜는 지워지고 1970 년이되는 날짜입니다.
여기에 가장 적합한 구현 패턴은 무엇입니까?
null 개체 패턴은 수행하려는 작업이 아닙니다. 이 패턴은 객체가 null이 아니어야하는 특정 함수에 전달할 수있는 구현 기능이없는 객체를 만드는 방법입니다. Eclipse에서 NullProgressMonitor의 예가 있는데 이는 IProgressMonitor의 빈 구현입니다.
1970 년과 같이 'null'날짜를 반환하는 경우 클라이언트는 1970 년인지 여부를 확인하여 여전히 'null'인지 확인해야합니다. 그렇지 않으면 불법 행위가 발생합니다. 그러나 null을 반환하면 코드가 빨리 실패하고 null을 확인해야합니다. 또한 1970 년 은 일 수 있습니다.
메서드가 null을 반환 할 수 있음을 문서화해야합니다.
매우 흥미로운 대답이기 때문에 내가 왜 질문을 던졌는가. 하지만 많은 사람들이 내 질문에서 물어 보았 듯이 null 객체 패턴을 해석하는 것처럼 보입니다. 따라서 내가 왜 그것을 게시했는지 ... 조건부로 null을 반환하는 것은 부작용을 도입한다는 점에서 냄새 나는 것이라고 느낀다. –
null을 반환 할 수 있다고 문서화하면 메서드가 반환하는 내용을 문서화하면 코드가 정확해진다. 반환 된 Date를 확인하지 않고 NPE를 경험 한 호출자는 메서드 동작을 명시 적으로 문서화했기 때문에 올바르지 않습니다. – MetroidFan2002
null이 좋습니다. 그러나 오류에 대해 null을 반환하려면 예외를 throw하는 것이 좋습니다.
날짜가없는 것이 유효한 조건이라면 예외가 발생하지 않습니다. – 18Rabbit
날짜가 발견되지 않으면 null이 될 수 있습니다. 그렇지 않으면 사람들은 1970 년 시대와 같은 마법의 날을 보냈는데, 사람들은 단지 null을 반환하는 것 이상의 기능에 관심을 갖게되었습니다. 내가 좋아하는이 아니 성능 저하가 명시 적으로 쿼리 방법을 다음 예외를 사용하는 경우가 있지만, null을 반환 할 수
문서 ...
:
if(employee.hasCustomPayday()) {
//throws a runtime exception if no payday
Date d = emp.customPayday();
}
정말 RuntimeException을 사용 하시겠습니까? C#에서는 이것이 표준이라는 것을 알고 있습니다. 그래서 아마 여러분이 제시하고있는 예제가 될 것입니다. 그러나 RuntimeExceptions는 예를 들어, 데이터베이스가 사라지는 것처럼 원인을 많이 내지 못하는 경우를 대비하여 예약해야합니다. –
개발자가 이미 쿼리를 완료 한 경우에는 try ... catch를 수행해야합니다. 그것은 다소 관용구를 난파시킨다. 쿼리가 true를 반환했지만 예외가 발생하면 런타임 예외가 발생할 수 있습니다. –
을 나는의 팬이 아니에요 null 오브젝트 패턴.
null이 유효하고 의도 된 반환 값이면 반환하십시오. 오류 조건으로 인해 발생하는 경우 예외가 더 적합합니다.
때때로 실제 문제는 메서드가 더 많은 정보를 나타내는보다 복잡한 형식을 반환해야한다는 것입니다. 이 경우에는 함정에 빠져서 기본 유형을 반환하고 다른 상태를 나타내는 특수 마법 값을 반환하기 쉽습니다.
나는 일반적으로 동의하지만, 객체가 있으면 객체를 반환하는 것이 합리적 일 수 있으며, 그렇지 않으면 null을 반환합니다. 일반적으로 허용되는 유일한 옵션입니다. – tloach
일반적으로 발생하는 시나리오가 아닌 경우 예외를 사용하십시오.
그렇지 않으면 (예를 들어 이벤트의 종료일 인 경우) null을 반환합니다.
어떤 경우에도 마법 값을 피해주세요)
당신은 여전히 뭔가를 확인하도록 요구하면
Date theDate = new Date();
if(MyFunction(a, b ,theDate)
{
do stuff with C
}
를 호출 할 수 있습니다 출력 매개 변수 그리고
boolean MyFunction(a,b,Date c)
{
if (good)
c.SetDate(....);
return good;
}
를 사용하여 시도 할 수 ,이 시나리오에서 몇 가지 검사를 피할 방법이 없습니다.
비록 SetDate가 더 이상 사용되지 않으며 Calendar 구현은 단지 추한 것입니다.
썬이 한 바보 같은 API 변경.
그래, 자바 7에서 JODA 기반 디자인으로 이동한다는 소문이 들렸습니까? –
달콤한 것입니다. 현재의 구현은 프레임 워크 디자인의 규칙 1에 위배됩니다. "일반적인 것을 쉽고 편하게 만듭니다." –
또한 Date 매개 변수 자체가 null이 아니 었는지 확인한 다음 NPE를 던져야합니다. –
이 메서드의 예상 결과가 날짜이거나없는 것으로 보입니다. 발견되지 않은 경우는 일반적으로 null을 리턴하여 나타납니다. 일부는이 사례를 나타 내기 위해 예외를 사용하지만 예상하지 못한 결과이므로 예외로 처리하는 팬이 아닙니다.
Null 개체 패턴은이 경우 적합하지 않습니다. 사실, 제 자신의 경험으로 볼 때 많은 경우에 적절하지 않습니다. 물론, 나는 약간의 경험으로 인해 편견이있다. ;-)
"삭제 된 사람"이란 무엇을 의미합니까? –
Calendar c = Calendar.getInstance(); c.clear(); 날짜 myDate = new Date (c.getTime()) 은 날짜가 1970 년 등으로 설정됩니다. return c.getTime(); –
1970 년 1 월 1 일의 날짜가 없습니까? 나는 틀릴 수있다. 너무 오래 자바를 만진 이후로. –