어떤 네이밍 안티 패턴이 존재합니까? [닫은]

당신이 그 이름에 도달하는 것을 발견하면, 당신은 이미 무언가를 엉망으로 만들었다는 것을 알고있는 몇몇 이름들이 있습니다.

예를 들면 다음과 같습니다.

XxxManager
이것은 클래스가 클래스의 기능을 설명해야하기 때문에 좋지 않습니다. 수업에서 수행 할 수있는 가장 구체적인 단어가 "관리"인 경우 수업이 너무 큽니다.

다른 이름 지정 안티 패턴이 있습니까?

명확히하기 위해, 나는 "어떤 이름이 나쁜지"묻지 않습니다. 그 질문은 전적으로 주관적이며 대답 할 방법이 없습니다. "시스템의 전반적인 디자인 문제를 나타내는 이름은 무엇입니까?" 즉, Xyz 구성 요소를 호출하려는 경우 구성 요소가 잘못되었음을 나타냅니다. 또한 모든 규칙에 예외가 있습니다. 디자인을 정말로 멈추고 다시 생각해야 할 때 경고 플래그를 찾고 있습니다.

다음 이름 지정 안티 패턴은 .NET, 특히 C #과 관련이 있습니다.

• 불일치 . 모든 필드 이름을 밑줄로 시작하기로 결정한 경우 해당 필드 이름 을 사용하십시오 .
• 모음이없는 Ambiguos 약어 . 과 같은 필드 이름을 심각하게 보았습니다 cxtCtrlMngr. 그것이 무엇을 의미하는지 거의 추측 할 수 없습니다.
• 너무 길고 자세한 변수 이름 입니다. ILoginAttemptRepository훌륭하고 설명 적 ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMapping입니다. 설명 적이지만 확실히 좋지는 않습니다.

내가 자주 접하는 것은 단순히 이름 지정 패턴을 전혀 사용하지 않는 것입니다. 일반적으로 개발자 무지 (네이밍 패턴이 좋은 것임을 나타냄)를 나타내며이 반 패턴은 클래스와 관련된 모든 종류의 메소드를 해당 클래스 자체에 채워서 SRP를 심각하게 위반하는 경향이 있습니다. 클래스에는 속성, CRUD 메서드, 응용 프로그램의 일부에 필요한 고객과 원격으로 관련된 모든 것이 있습니다.

또한 접미사로 "Engine"을 사용하는 것은 "Manager"를 사용하는 것과 거의 같습니다. 매우 모호하고 클래스 XxxEngine는 많은 메소드를 포함하는 VB 스타일 모듈에 해당하는 경향이 있으므로 객체 지향 프로그래밍에 대한 지식이나 아이디어없이 하나의 "사용하기 쉬운"지점에 있습니다.

음, 먼저 간단한 답변 : 타입 헝가리어은 ( http://mindprod.com/jgloss/unmainnaming.html , 또한 훌륭한 다른 생각을 가지고 헝가리어는 악이 아닌 경우에보다 균형 잡힌 볼 수 있습니다. http://www.joelonsoftware.com을 /articles/Wrong.html )

인터페이스 이름 앞에 'I'를 붙이거나 추상 클래스 이름에 'Abstract'를 붙입니다. 이것은 수있는 인터페이스와 추상 클래스를 구별하지 않는 추상 클래스의 개념을, 또는하지 않는 언어에서 면죄 수 -하지만 자바, 예를 들어, 그것은 항상 나쁜 생각입니다.

또한 관리자에 대해서는 귀하의 의견에 동의하지 않습니다. 나는 때때로 그 패턴을 사용하며, 단지 다른 이름을 짓려고 시도하면 이름이 XxxxxManager보다 더 설명 적이 지 않다는 것을 의미합니다. 한두 단어로 깔끔하게 요약 할 수없는 몇 가지 작업 (필수적으로 복잡한 작업은 아님)이 있습니다.

스 필링 :

기울고있는 장애가 있고 철자를 쓸 수 없습니다. 맞춤법 검사기가 없으면 나는 힘이 없습니다. 나는 확인하기 위해 내가 만든 모든 이름을 워드 프로세서에 복사하려고하지만 항상 일부를 그리워합니다. 마지막 프로젝트에서 나는 api의 많은 부분을 썼고 responce라는 단어를 처음 사용할 때 철자 검사를하지 않았으며 아무도 말하지 않았기 때문에 그것이 옳다고 가정했습니다. 우리는 그에 대한 응답으로 적어도 50 개의 기능을 가지고있었습니다. 새로운 사람이 팀에 와서 왜 우리가 응답을 사용하는지 물었습니다.

글쎄, 내 의견이 약간 논란이 될까봐 두렵다. 그러나 시도해보십시오 ...

내가 걱정하는 한 XxxController와 같은 Mike Baranczak에 동의해야합니다 .XxxHandler는 우리가 실제로 자주 사용하는 것입니다. 우리에게 Controller는 트랜잭션 관리, 예기치 않은 오류 처리, 실제 작업 수행을 위해 XxxHandler 호출 등 "캡슐화 된"항목의 진입 점과 같은 것입니다. XxxManager는 컨트롤러와 동의어라고 말할 수 있습니다. 한 경우에는 Manager를 사용하고 다른 경우에는 Controller를 사용하지 않는 것이 중요하다고 생각합니다. 팀에서 일할 때는 일관성을 유지하는 것이 매우 중요합니다.

이와 같은 것들에 대한 더 나은 이름을 찾는 것은 실제로 어렵거나 어쩌면 불가능할 수도 있습니다. 상황을보다 명확하게하려면 Xxx를 잘 선택해야합니다.

내가 개인적으로 싫어하는 것은 get ... 또는 set ...이라는 메소드가 단순한 접근 자 이상일 때입니다. 나는 결정하기를 좋아한다.

밥 삼촌에 따르면 또 다른 것은 내 마음 속에 나온 것입니다. 메소드 이름의 "And"는 많은 일을한다는 표시입니다. 그러나 인생은 항상 흑백이 아닙니다. 예를 들어, 괜찮다고 생각되는 상황이 있습니다. 성능 문제로 인해 (처리하지 않은 이유를 확인하기 위해 이미 데이터가있는 경우) ...

나는 개인적으로 시스템 헝가리 표기법의 큰 팬이기도합니다. 대부분의 경우 IDE에서 소스 코드를 다루고 있습니다. 그러나 종종 편집기 만 사용하거나 브라우저에서 저장소를 찾아 보는 경우가 있습니다. 한 가지 단점은 형식 접두사로 인한 도구 지원입니다 ...

나는 가장 중요한 것은 전제 조건이 아니라고 생각합니다-나에게 적합하지 않은 협약-나는 협약이없는 것보다 낫습니다 ...

아마도 최악의 네이밍 안티 패턴은 다음과 같습니다.

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

[foo, bar] 쌍의 3 요소 목록이 있습니다. 네 번째가 필요한 경우 테이블에 새 열을 추가해야합니다.

다음과 같은 코드로 이어집니다.

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

foo 및 bar 열을 사용하여 별도의 테이블을 작성하고 stuff 테이블에 링크해야합니다.

create table fubar(foo string, bar string, stuff_id long)

두 번째 최악은 다음과 같습니다.

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

여기서는 Address 클래스의 두 인스턴스 대신 6 개의 필드가 있습니다.

이 안티 패턴은 두 세트의 모든 조합을 나열하는 일련의 두 부분으로 구성됩니다 (예 : [foo, bar] x [1,2,3] 또는 [home, perm] x [street, city, state]

tautology 인 클래스 또는 인터페이스 이름 지정 은 링크가 말하는 Java뿐만 아니라 모든 언어에서 나쁜 것입니다.

반복이 명확성을 제공하지 않더라도 동일한 단어를 사용하기 위해 다른 단어를 사용하는 타우 톨 로지 (동적).

나는 자주 같은 일반적인 이름을 가진 소프트웨어 라이브러리가 발생 Library하거나 Common. 최적이 아닌 설계를 나타냅니다. 개발자는 코드 복제를 피하려고 노력하지만 기능을 기반으로 분해 된 설계를 만들지 않습니다.

명명 에서 Microsoft 에서 잘못된 이름에 대해 다음 목록을 제공 할 수 있습니다.

1. 그것들은 의미 론적이지 않습니다. 즉, 그것이하는 일을 강조하는 대신, 사용하는 기술 이나 그 기반이되는 패턴 을 강조하는 이름을 가지고 있습니다 .
2. 그것들은 구문상의 일관성을 따르지 않습니다. 예를 들어, 이름의 일부는 낙타의 경우이며 다른 부분은 파스칼의 경우입니다.
3. 그들은 어려운 약어, 같은 이해 있습니다 ScrollableX 대신 CanScrollHorizontally
4. 그들은 그 환경의 키워드를 망칠 수 있도록 선택되었습니다.