Java 패키지 이름 규칙에 결함이 있습니까? [닫은]

우리는 도메인 이름을 바꾸는 Java 패키지 이름 규칙을 잘 알고 있습니다. 즉 www.evilcorp.com, 관례 적으로 Java 패키지를 선택했습니다 com.evilcorp.stuff.

점점 더 쇠약 해지고 있습니다. 상용 프로그래머로서, 브랜드 패키지, 인수 또는 이와 유사한 이유로 소프트웨어 패키지 이름이 완전히 관련이 없다는 것을 몇 번이고 알게되었습니다.

오픈 소스 세계에서는 이름 변경이 적으므로 의미가 있습니다. 그러나 많은 (상업용 / 내부) 소프트웨어의 유효 기간이 소프트웨어를 만드는 조직의 수명보다 훨씬 길다.

문제는 종종 이름을 사용하는 마케팅 부서의 우위를 복용 소프트웨어 프로젝트에 의해 악화되어 금일 가 특정 프로젝트에 참조를 사용합니다. 틀림없이, 황제의 새 옷을 신선하고 새로운 느낌으로 만들기 위해 3 개월 동안 줄을 바꾸는 이름.

이로 인해 나는 대부분 리버스 도메인을 패키지 이름으로 사용하는 것을 중단했습니다. 물론, 대규모로 수행 할 경우 이름 충돌의 위험이 있지만 "고유 한"소프트웨어 이름을 사용하거나 일반적인 단어를 사용하지 않거나 라이브러리로 판매 / 릴리스하려는 프로젝트에 역 도메인을 사용하면 이러한 문제가 완화됩니다. .

다른 생각들?

도메인 이름 규칙이없는 네임 스페이스 (.NET 패키지)에 대해 Microsoft가 제공 하는 조언 을 인용 하겠습니다 . 도메인 이름이 견고하고 안정적인 ID를 나타내는 것으로 믿지 않기 때문에 Java 패키지에도 좋은 조언이라고 생각합니다.

네임 스페이스 이름의 일반적인 형식은 다음과 같습니다.

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

예를 들면 다음과 같습니다 Microsoft.WindowsMobile.DirectX.

다른 회사의 네임 스페이스가 동일한 이름과 접두사를 갖지 않도록하려면 네임 스페이스 이름에 회사 이름을 접두어로 사용하십시오.

네임 스페이스 이름의 두 번째 수준에서 안정적인 버전 독립적 제품 이름을 사용하십시오.

회사 내의 그룹 이름은 수명이 짧은 경향이 있으므로 조직 계층을 네임 스페이스 계층 구조의 이름의 기초로 사용하지 마십시오.

네임 스페이스 이름은 오래 지속되고 변경되지 않는 식별자입니다. 조직이 발전함에 따라 이름 공간 이름이 더 이상 사용되지 않아야합니다.

회사 이름이 불안정한 경우 제품 이름으로 시작하면됩니다.

다른 문제에 대한 해결책을 찾고 있습니다. 즉, 동일한 패키지에 파일을 넣어서 프로그래머 X와 프로그래머 Y가 서로 발가락을 밟는 것을 어떻게 피할 수 있습니까?

"도메인 이름을 반대로 바꾸는 것"은이를 우아한 방식으로 해결합니다. X와 Y가 관련이 없으면 동일한 패키지 이름 공간을 선택하지 않을 것입니다.

컨벤션에는 결함이 없습니다. 당신이 잘 설명해 준 것처럼 사람들은 결함이 있습니다.

두 가지 이점을 생각할 수 있습니다.

1. 독립 개발자 간의 충돌을 피합니다. 도메인은 고유합니다. 두 사람이 서로 다른 두 프로젝트의 이름을 지정할 수 있지만 도메인에는 정확히 한 명의 소유자가 있습니다.
2. 관리자를 쉽게 찾을 수 있습니다. 일부 오픈 소스 라이브러리를 사용하는 코드베이스를 상속하는 경우 패키지를 찾는 것이 더 좋습니다. 구글은 확실히 구글을 할 수 있기 때문에 지금은 중요하지 않습니다. 그러나 10 년 전, 이것은 분명하지 않았습니다.

다른 조직이 라이브러리에서 동일한 클래스 이름을 사용하는 경우 이름 충돌을 피하기 위해 역 도메인 이름이 사용되었습니다. 그것은 간단한 해결책이며 off cource에는 몇 가지 단점이 있습니다 (예 : 같은 조직의 클래스에 대한 이름 충돌은 어떻습니까?).

당신은 그것을 사용할 의무가 없으며, 행동 ​​규칙이나 규칙이 아닙니다. 예를 들어, 일부 Java 프로그래머는 Java 코드 규칙을 존중하지 않습니다 .

그러나 대안을 고려하십시오. 예를 들어 LogFactory에 대해 두 개의 정규화 된 클래스 이름을 어떻게 원하십니까?

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

또는

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

따라서 제 생각에는 상식과 도서관 이용자를위한 고려가 포함되어 있다면 원하는 것을 사용하십시오.

새 프로젝트를 시작할 때 마케팅 담당자는 소스 코드에서만 참조되므로 알거나 모르는 내부 이름과 변경 불가능한 이름을 항상 고집합니다. 그렇게하면 프로젝트 이름 변경과 네임 스페이스 오염에 대해 걱정할 필요가 없습니다.

이 시나리오는 소스 코드가 일반적으로 제품의 중요한 부분이 아니므로 프로젝트가 일반적으로 폐쇄 소스의 독점 시스템이기 때문에 적합합니다. 그러나 소스 코드가 제품인 오픈 소스 프로젝트에서는 이것이 불가능할 수 있습니다.