에 따르면 때 원시 집착하지 않는 코드 냄새입니까? String 객체 대신 우편 번호를 나타내는 ZipCode 객체를 만들어야합니다.
그러나 내 경험상, 나는보고 싶어한다
public class Address{
public String zipCode;
}
대신에
public class Address{
public ZipCode zipCode;
}
후자는 프로그램을 이해하기 위해 ZipCode 클래스로 이동해야한다고 생각하기 때문입니다.
그리고 모든 기본 데이터 필드가 클래스로 대체 된 경우 정의를 보려면 많은 클래스간에 이동해야한다고 생각합니다. 요요 문제 (반 패턴)로 고통받는 것처럼 느껴집니다 .
따라서 ZipCode 메소드를 새 클래스로 이동하고 싶습니다. 예를 들면 다음과 같습니다.
낡은:
public class ZipCode{
public boolean validate(String zipCode){
}
}
새로운:
public class ZipCodeHelper{
public static boolean validate(String zipCode){
}
}
우편 번호를 확인해야하는 사람 만이 ZipCodeHelper 클래스에 의존합니다. 그리고 원시적 인 강박 관념을 유지하는 또 다른 "이점"을 발견했습니다. 클래스가 직렬화 된 양식처럼 보이게합니다 (예 : 문자열 열 zipCode가있는 주소 테이블).
내 질문은 "요요 문제를 피하는 것"(클래스 정의 간 이동)이 "원시적 인 집착"을 허용하는 타당한 이유인가?
9
@ jpmc26 그렇다면 우편 번호 객체가 얼마나 복잡한 지 알 수 있습니다. 그것이 옳다고 말하지는 않지만 존재합니다
—
Jared Goguen
@ jpmc26, 나는 당신이 "복잡한"에서 "나쁜 디자인"으로 어떻게 가는지 보지 못합니다. 복잡한 코드는 종종 단순한 코드가 우리가 원하는 이상적인 세상이 아니라 실제 세계의 복잡성과 접촉하는 결과입니다. "두 페이지 기능으로 돌아갑니다. 예, 저는 창을 표시하는 단순한 기능 일 뿐이지 만 머리카락과 물건이 거의 자라지 않아 아무도 이유를 알지 못합니다. 이유를 알려 드리겠습니다. 그 이유는 버그입니다. 수정. "
—
Kyralessa
@ jpmc26-ZipCode와 같은 객체를 감싸는 요점은 유형 안전입니다. 우편 번호는 문자열이 아니며 우편 번호입니다. 함수가 우편 번호를 요구하면 문자열이 아닌 우편 번호 만 전달할 수 있어야합니다.
—
Davor Ždralo
이것은 언어에 따라 다르며 다른 언어는 여기서 다른 일을합니다. @ DavorŽdralo 같은 범위에서 많은 숫자 유형을 추가해야합니다. "양의 정수만", "짝수 만"은 모두 유형이 될 수 있습니다.
—
paul23
@ paul23 그렇습니다. 그리고 우리 가 가지고 있지 않은 주된 이유는 많은 언어들이 그것들을 정의하는 우아한 방법을 지원하지 않기 때문입니다. "userAge == currentTemperature"가 넌센스로 감지되도록 "연령"을 "섭씨 온도"와 다른 유형으로 정의하는 것이 합리적입니다.
—
IMSoP