클래스 이름에 "Base"사용

Question

상속 트리의 맨 아래에있는 클래스 이름에 'Base'라는 단어를 사용할 수 있습니까?

저는 항상이 사람이 저와 동의하는지 궁금해합니다.

예를 들어, MyClassA 및 MyClassB의 특정 요소를 공통 기본 클래스로 리팩터링하는 경우 두 클래스가 상속하는 MyBaseClass를 만들려고합니다.

하지만 MyBaseClass를 리팩토링해야한다면 어떻게 될까요? MyBaseBaseClass? 이제 그건 바보예요.

나는 Rocky Lhotka가 CSLA 프레임 워크에 신경 쓰지 않는다는 것을 알고 있지만 프로그래밍에서 '확실한'것에 대해서는 항상 불안합니다.

생각하십니까?

이유는 무엇입니까 나는 이것에 대해 걱정하고 있습니다.

두 개의 네임 스페이스 - MySpecificNamespace 및 MyCommonNamespace가 있습니다. MyNamespace는 예상대로 MyCommonNamespace를 사용합니다.

이제 가능한 경우 문제의 컨텍스트를 설명하고 클래스 이름에 컨텍스트를 추가하는 것을 피하기 위해 네임 스페이스를 최대한 활용하려고합니다. 예를 들어 MyCommonNamespace에있는 클래스에서 내린 MyNamespace에 클래스가 있다고 가정합니다.

옵션 이름에 대한

I 수 호출이

MySpecificClass: MyClass 
{ 
} 

하지만 내가 추가 해요 '특정'(문맥) -이 MySpecificNamespace에 이미로 중복됩니다.

옵션 B

MyClass: MyCommonNamespace.MyClass 
{ 
} 

당신은 우리가 바로 여기에 혼동 수있는 방법을 볼 수 있습니까?

옵션 C

내가 생각하는 하나는 비린내 :

MyClass: MyBaseClass 
{ 
} 

Answer 1

나는 아마 가능하면 실제로 그것이 무엇인지 설명하는 식별자에 찬성 피해야한다고 생각합니다!

이 질문은 추상적이기 때문에 대답하기가 어렵습니다. 예를 들어, MyClassA와 MyClassB의베이스 인 "MyClass"를 호출하는 것을 고려해 볼 수 있습니다.

Answer 2

나는이 질문에 위키를 쓰는 것이 가치 있다고 생각한다.

FWIW, 동의합니다. 나는 보통 내 기본 수업에 대해 좀 더 "일반적인"용어를 찾으려고 노력합니다. 그래서 "고객"클래스가 있고 새로운 기본 클래스를 도입해야한다면 "CustomerBase"가 아닌 "Contact"또는 뭔가를 사용합니다.

Answer 3

인용 한 리팩토링 이유와 정확히 일치하는 부분이 "아니오"입니다.

클래스의 이름은 논리적으로 표시 한 이름을 따라야하며, 객체 클래스는 인데 실제로는 자료입니다. 형이상학 FTW :

---

재 : 옵션 B, 나는 그것이 기술적 인 관점에서 존재하는 경우에만 기본 클래스의 이름에 자료 접미사를 추가하는 경향이

namespace MySpecificNamespace 
{ 
    MyClass: MyCommonNamespace.MyClass 
    { 
    } 
} 

Answer 4

에 대한 혼란 아무것도 (이 없습니다 일부 코드를 공유하기 위해), 실제로는 쓸모있는 클래스를 구성하지 않습니다 (그래서 모든 클래스는 추상적입니다). 이들은 매우 드문 경우이지만 Helper 클래스처럼 피해야합니다.

Answer 5

나는 또한 캠프가없는 편입니다. 오늘 Base에 Base를 놓으십시오. 6 개월 내에 누군가가 찾고있는 동안 코드 기반의 MyDerivedClass 클래스를 깨뜨릴 것입니다. OO의 진언에 따라

Answer 6

나도 없음 제안하지만, 돌을 던져 않을 것이다 ...

, 사용자의 이름 지정 시스템이 최적의 코드를 캡슐화하도록되어 기본 오브젝트를 표현한다. 실제로 거기에 선택의 프로그래밍 언어의 실제 구문 구성과 관련된 '메타 언어'가 없어야합니다.

당신의 객체가 정말로 추상적이라면 곧 바뀔 것으로 보지 않습니다. 'Base'를 추가하면 일반적인 가독성이 향상된다는 주장이 있습니다.

대부분의 경우와 마찬가지로 담요의 옳고 그름은 없습니다. 코드베이스의 전체 레이아웃,이 특정 코드가 나타내는 내용 및 사내 스타일에 따라 다릅니다. 일관성있게하려고하십시오.

다른 곳에서는베이스가 사용됩니까?

Answer 7

"Abstract"접두어 어쩌면?

Answer 8

자바에서는 추상 클래스 FooBase에서 인터페이스 Foo의 기본 구현을 제공하는 경향이 있습니다. 나는 이것이 완벽하게 괜찮다고 생각하고 인터페이스에 대한 연결을 매우 명확하고 규칙적으로 만든다.

인터페이스가 없으면 추상 기본 클래스 Foo를 호출합니다.

Answer 9

보통 IFoo는 인터페이스에, AbstractFoo는 골격 구현에 사용됩니다. 이는 .NET과 Java 규칙을 혼합 한 것입니다.

Answer 10

동의합니다. AbstractFoo는 괜찮은 해결책입니다. 나는 형용사를 추가 할 필요가없는 이름을 선택하려고합니다. 나는 Base를 사용하지 않을 것입니다.

Answer 11

부모 클래스와 이름이 같은 클래스는 끝내지 않습니다. Java java.sql.Date는 java.util.Date를 확장합니다. 가져올 정확한 클래스를 지정해야하거나 그렇지 않으면 패키지/네임 스페이스를 포함하여 클래스 이름을 완전히 지정해야하기 때문에 이것은 매우 성가시다.

개인적으로 나는 개인적으로 사물의 이름을 선호합니다. 기본 또는 추상 클래스가 무언가의 부분 구현 만 제공하기 위해 존재하고 그 인터페이스를 나타내지 않는 경우 해당 이름에 Abstract 또는 Base라는 단어를 사용하는 것이 종종 허용됩니다. 그러나 해당 클래스가 인터페이스를 나타내더라도 인터페이스의 이름을 지정해야합니다.

예를 들어 Java에서는 연결 인터페이스 (DB 연결 용)가 있습니다. IConnection이 아니라 Connection이라고합니다. 이처럼 사용

Connection con = getConnectionFromSomewhere(); 

당신이 JDBC 드라이버를 만들고 연결을 구현해야하는 경우 특정 연결의 구현 세부의 하위 계층 인 ConnectionBase 또는 AbstractConnection있을 수 있습니다.

abstract class AbstractConnection implements Connection 

class OracleConnection extends AbstractConnection 

등이있을 수 있습니다. 그러나 코드의 클라이언트는 AbstractConnection을 보거나 OracleConnection을 보지 않으며 Connection 만 볼 수 있습니다.

일반적으로 일반적으로 유용한 클래스의 이름은 표현/작성한 후에 이름을 지정해야하지만 코드 유지 관리/구성을위한 도우미 인 클래스의 이름은 그대로 지정할 수 있습니다.

* ps 나는 I와 인터페이스를 명명하는 것을 싫어합니다. 사람들은 모든 클래스를 C로 명명합니까? 2009 년입니다! IDE는 어떤 유형의 객체인지를 알려줄 수 있습니다. 이상한 경우 인터페이스 나 클래스 인 경우 문제가되는 경우도 있습니다.

Answer 12

"모든 BaseClass는 우리 소유입니다."

나는 단 하나의 예외를 제외하고는 확실한 아니오를 가지고 있습니다. 군사 시설이나 야구 경기장을 관리 할 앱을 작성하는 경우 이동하십시오.