클래스와 네이티브 클래스 간의 이름 유사성을 어떻게 피합니까? [닫은]

9

방금 "흥미로운 문제"에 부딪 쳤습니다.

나는 시스템을 개발하고 있으며 여러 가지 이유로 (추상화, 기술 독립성 등) 정보 교환을 위해 자체 유형을 만듭니다.

예를 들어 : SendEmail이라는 메소드가 있고 비즈니스 로직에 의해 호출되는 경우, OurCompany.EMailMessage 유형의 매개 변수를 갖습니다.이 매개 변수는 완전히 기술 독립적이며 "비즈니스 관련 데이터"만 예를 들어, 정보가 헤드 인코딩에 인접하지 않음).

SendEmail 함수 내에서, 우리는 EMailMEssage 객체로부터이 정보를 얻고 MailMessage (이것은 테크놀로지에 특화된) 객체를 생성하여 네트워크를 통해 보낼 수 있습니다.

당신이 이미 알 수 있듯이, 우리 수업은 "네이티브"언어 수업과 이름이 매우 비슷합니다. 문제는 이것이 바로 전자 메일 메시지이므로 다른 의미있는 이름을 찾기가 어렵습니다.

이 문제가 자주 있습니까? 어떻게 관리합니까?

편집 : @mgkrebbs는 정규화 된 이름을 사용하는 것에 대해 언급했습니다. 이것은 우리의 현재 접근 방식이지만, 조금 너무 장황한 IMHO입니다. 가능하면 더 깨끗한 것을 원합니다.

naming coding-standards variables

— JSBach
소스

2

약간의 장황한 경우 항상 자격을 사용하는 것이 실행 가능한 솔루션으로 보입니다. 한 유형에는 OurCompany.EMailMessage를 사용하고 다른 유형에는 SendEmailClass.EMailMessage (또는 기타)를 사용하십시오. 이 방법을 사용하는 데 문제가 있습니까?

— mgkrebbs

예, 그것에 대해 생각했지만 자세한 정보를 얻습니다. "깨끗한"것을 원하지만 제안한 솔루션은 현재의 솔루션입니다. 나는 이것을 설명에 추가 할 것이다

— JSBach

3

이름은 맥락에서옵니다. 일반적으로 네임 스페이스 또는 이와 유사한 것입니다. 따라서 문제가되지 않습니다.

— deadalnix

+1, 나는이 질문을 좋아한다. 나는 약 7 년 전에 강사에게이 질문을 한 적이 있으며 그는 내가 완전한 "...."라고 생각했다.

— NoChance

어떤 언어를 사용하고 있습니까? 대답은 언어마다 다릅니다. 일반적으로 대답은 '네임 스페이스 사용'입니다. 단일 Java 응용 프로그램에서는 6 개의 라이브러리에서 사용하는 것과 동일한 클래스 이름을 사용하는 것이 일반적입니다.

— 케빈 클라인

3

이것은 프로젝트에 사용할 네임 스페이스에 대한 문제입니다.

기본적으로 네임 스페이스는 프로젝트에서 사용하려는 모든 클래스 및 / 또는 모든 클래스에서 제공하는 키워드 모음입니다 (일반적으로 language / compiler / IDE와 함께 제공되는 표준 클래스 포함).

네임 스페이스는 모음이기 때문에 기본적으로 일부 동작은 관련 동작없이 용어의 혼란을 방지하기 위해 적용되며, C #과 같은 일부 언어에서는 일반적으로 고유 한 네임 스페이스를 정의하고 다른 클래스에서도 사용할 수 있습니다.

네임 스페이스를 언어의 기본 키워드와 혼동하지 마십시오. 둘 다 키워드 모음이지만 둘 사이에는 큰 차이가 있습니다. 네임 스페이스는 수정할 수 있지만 언어의 기본 키워드는 일반적으로 수정할 수 없습니다. 프로젝트에서 사용한 네임 스페이스와 사용하는 언어의 기본 키워드 사이의 합계는 총 키워드 수를 제공합니다.

주제는 인터넷에서 심하게 논의되어 있습니다. "namespace [your language]"라는 용어를 사용하여 기본적인 검색을 제안 할 수 있습니다. 언어에 따라 다른 접근 방식을 사용할 수 있기 때문에 귀하의 질문에 직접 대답하지 않습니다.

— 마이크로
소스

3

내 이전 개발 팀은 각 사용자 정의 클래스에서 응용 프로그램의 약어를 추가하는 데 사용합니다. 예를 들어 ABCEmail 클래스 가있었습니다 .

네임 스페이스에 의존하는 것보다 간단하지만 네임 스페이스 사용에 대한 보완 솔루션이 될 수 있다고 생각합니다.

마지막으로, 새 객체를 생성하고 있으므로 기본 객체가 사용자의 요구에 응답하지 않으므로 이메일 파일 이름이 CustomizedEmail , AdvancedEmail ... etc 일 수 있습니다 .

— 아민
소스

1

최종 요점에 동의했지만 왜 것 OAEmail보다 낫 OurApplication.Email습니까? OAEMail에 미치는 영향이 모든 변환이 발생하고 두 클래스가 같은 소스 파일에 사용되는 경우 네임 스페이스 표기에만 영향이있는 동안, 소프트웨어의 일부를.

— Steven Jeuris

1

귀하의 언어가 네임 스페이스를 지원하지 않을 때 접두사가 좋은 생각이라고 생각합니다. 그러나 언어가 네임 스페이스에서 어떤 형태를 지원한다면 그것을 사용하십시오 (이것은 네임 스페이스가 해결하도록 설계된 문제입니다!). '

— Martin York

@Steven Jeuris : 클래스 이름은 일단 생성되면 선택해야합니다. 그 후, 나는 그것이 불필요한 모든 영향 때문에 그것을 바꾸는 것이 나쁜 습관이라고 생각합니다.

— 아민

@Loki Astari : 사용중인 IDE를 모르지만 주어진 클래스를 검색하거나 열 때 다른 클래스 이름을 다루기가 더 쉽다는 것을 알았습니다. 사용자 정의 된 "이메일"버전을 가진 프로젝트를 보았고 파일을 열 때마다 여러 네임 스페이스를 찾아야했습니다. 요점은 여전히 유효합니다 패키지 조직에 따라 몇 개의 사용자 정의 클래스가 작성 될지 생각합니다.

— 아민

1

@ Amine : 실제로 네임 스페이스 와 논쟁하고 있다는 것을 몰랐습니다 . 캡슐화, 모호함 제거, 중복성 감소 등 ... Ps : 네임 스페이스에 대한 더 많은 이점을 보려면 네임 스페이스에 대해 더 많이 읽으십시오. 계층. 나에게 당신의 의견에 관해서 : 지속적인 리팩토링은 소프트웨어 개발의 일부입니다. 더 적합한 이름, 큰 영향 여부를 생각할 수 있으면 이름을 바꾸는 것이 좋습니다. 그러나 먼저 동료와 논의하는 것이 가장 좋습니다.

— Steven Jeuris

3

어떤 언어를 사용하고 있습니까? 대답은 언어마다 다릅니다. 일반적으로 대답은 '네임 스페이스 사용'입니다. 나는 외부 네임 스페이스와의 충돌을 피하기 위해 타입 이름을 거의 엉망으로 만들지 않을 것입니다.

단일 Java 응용 프로그램에서는 6 개의 네임 스페이스에 동일한 클래스 이름 (예 : "날짜")이 정의되어있는 것이 일반적입니다. 한 클래스가 두 개의 개별 Date 클래스를 사용해야하는 경우 Java는 유형 별명을 지원하지 않으므로 Date 클래스 중 하나는 표시되는 모든 위치에서 정규화되어야합니다. C ++에서는 인생이 더 쉽다. typedef로 그중 하나의 이름을 바꿀 수 있습니다.

— 케빈 클라인
소스

비슷한 대답을 게시하려고했지만 C ++ 별칭 예제 대신 alias 지시문을 사용하여 C #을 언급하려고했습니다 .

— Steven Jeuris

@Steven : C ++ 대신 C #을 언급하려고했지만 C #으로 프로그래밍한지 몇 년이 지났지 만 확실하지 않았습니다.

— 케빈 클라인

2

이 문제가 자주 있습니까? 어떻게 관리합니까?

실제로 사용하는 언어에 따라 다릅니다. c ++ 및 java에서는 네임 스페이스를 사용하여이 문제를 해결합니다. 나는 C ++을 사용하고 있으며 같은 이름의 다른 클래스를 얻었습니다. 그것들은 다른 네임 스페이스에 있기 때문에 문제가되지 않습니다.

다른 언어로는 다른 이름을 제공하는 방법이 없습니다.

— Јовић
소스

컴퓨터의 경우 문제는 아니지만 개발자에게는 EmailMessage 및 MailMessage가 있기 때문에 문제가 될 수 있습니다.

— JSBach

@Oscar 분명히. 컴퓨터의 경우 xyz123에도 여전히 동일하게 작동합니다. 나는 다른 방법으로 자세한 것을 보지 못합니다 (당신은 의견에서 그것을 피하려고한다고 말했습니다).

— BЈовић

2

귀하의 질문은 매우 좋습니다. 메소드 접두사 U (또는 u) 또는 cls (클래스의 줄임말)를 접두어로 사용하면 어떻습니까? 예를 들어:

clsEMailMEssage 또는 uEMailMEssage

이것은 많은 타이핑이 필요하지 않으며 타입이 'yours'라고 즉시 알 수 있습니다.

편집 - 처음 2 개의 의견에 대한 답변 :

나는 헝가리의 모든 표기법이 똑같지는 않다는 사실에 독자의 관심을 끌고 싶다. 우리는 System Hungarian 과 Apps Hungarian을 구별해야합니다. 위의 제안은 유해하지 않은 Apps Hungarian 유형을 따르는 것으로 가정합니다.

ID를 명명 할 때 intID와 같은 시스템 헝가리어 표기법과 관련된 피해는 위 제안에서 나타나지 않습니다.

이에 대한 자세한 내용은 다음을 참조하십시오. 잘못된 코드를 잘못 보이게 만들기-Joel On Software

— 기회 없음
소스

3

누군가 헝가리어 표기법을 추천 할 때마다 하나님은 고양이를 죽입니다.

— Konamiman

2

BIgHUmpCAmelCAsing도 도움이되지 않습니다.

— Steven Jeuris

위의 의견에 감사드립니다. Pls는 내가 편집 한 것을 본다. 비록 우리 중 일부는 새끼 고양이를 죽이기를 원하는 사람들이 그들의 마음을 바꾸지 않을 것이라는 것을 알고있다. :)

— NoChance

나는 당신이 몇 가지 유효한 추론을 추가 했으므로 다운 투표를 제거했습니다. 그러나이 시나리오에서는 Apps Hungarian이 네임 스페이스보다 더 적합하다는 데 동의하지 않습니다. 언어가 별칭을 지원할 때 훨씬 적합한 솔루션입니다. kevin cline 's answer을 참조하십시오 .

— Steven Jeuris

@Steven Jeuris, 귀하의 의견에 감사드립니다. 네임 스페이스는 입력하는 데 시간이 오래 걸리는 것을 제외하고는 완벽합니다. 제공 한 링크를 확인하겠습니다.

— NoChance