C #의 열거 형에 자체 파일이 있어야합니까? [닫은]

열거 형을 사용하는 클래스가 있는데 열거 형은 현재 자체 파일에있어 낭비되는 것처럼 보입니다.

열거 형이 사용되는 파일의 네임 스페이스 내에 배치되는 것에 대한 일반적인 의견은 무엇입니까? 아니면 열거 형이 실제로 자체 cs 파일에 있어야합니까?

편집하다

문제의 클래스가 이러한 열거를 사용하지만 외부 호출자도 사용한다고 언급해야합니다. 즉, 다른 클래스가 이러한 열거를 설정할 수 있습니다. 그래서 그들은 수업에 내부적으로 사용되지 않습니다. 그렇지 않으면이 질문은 더 똑똑하지 않을 것입니다.

"더 이상하지 않다"고 말하지 않지만 (추가 파일 비용은 얼마입니까?) 종종 불편합니다. 일반적으로 열거 형과 가장 밀접하게 관련된 클래스가 하나 있으며 동일한 파일에 넣습니다.

이것은 실제로 선호의 문제입니다.

각 열거 형을 자체 파일에 넣는 것을 선호합니다 (소형에 관계없이 각 인터페이스, 클래스 및 구조체에 대해 동일). 다른 솔루션에서 왔거나 해당 유형에 대한 참조가없는 경우 쉽게 찾을 수 있습니다.

각 파일에 단일 유형을 넣으면 확산없이 소스 제어 시스템의 변경 사항을보다 쉽게 ​​식별 할 수 있습니다.

이것은 전적으로 스타일의 문제입니다. 내가하는 경향 Enums.cs은 열거 형 선언이 수집되는 솔루션에서 파일을 호출 하는 것입니다.

그러나 그들은 일반적으로 F12어쨌든 열쇠를 통해 발견됩니다 .

스스로에게 물어볼 질문은 C #에 열거 형에 대해 내가 만든 다른 모든 유형과 다르게 취급해야한다는 것을 나타내는 것이 있습니까?

열거가 공개 인 경우 다른 공개 유형과 같이 취급해야합니다. 비공개 인 경우이를 사용하여 클래스의 중첩 멤버로 선언하십시오. 하나는 열거 형이기 때문에 두 개의 공용 유형을 동일한 파일에 넣을 이유가 없습니다. 그것이 공개적인 유형이라는 사실이 중요합니다. 유형의 맛은 그렇지 않습니다.

각 유형 (클래스, 구조체, 열거 형)을 자체 파일에 넣는 또 다른 이점은 소스 제어입니다. 유형의 전체 기록을 쉽게 얻을 수 있습니다.

나는 네임 스페이스 내부와 클래스 외부에 배치하여 아래와 같이 네임 스페이스의 다른 클래스에 쉽게 액세스 할 수 있도록합니다.

namespace UserManagement
{
    public enum UserStatus { Active, InActive }
    class User
    {
        ...
    }
}

일반적으로 나는 열거 형이 클래스와 동일한 파일에 있고 속성이 될 것입니다. 예를 들어 클래스 가 있으면 Task열거 형 TaskStatus은 동일한 파일에 있습니다.

그러나 더 일반적인 성격의 열거 형이 있으면 다양한 파일에 컨텍스트로 유지합니다.

필요한 액세스 권한에 따라 다릅니다.

열거 형이 단일 클래스에서만 사용되는 경우 다른 곳에서 사용할 필요가 없으므로 해당 클래스 내에서 열거 형을 선언해도 좋습니다.

여러 클래스 또는 공용 API에서 사용되는 열거의 경우 항상 적절한 네임 스페이스의 자체 파일에 정의를 유지합니다. 이 방법을 찾는 것이 훨씬 쉬우 며 전략은 파일 당 하나의 객체 패턴을 따르므로 클래스 및 인터페이스와 함께 사용하는 것이 좋습니다.

나는 그것이 열거 형의 범위에 달려 있다고 생각합니다. 예를 들어 열거 형이 하나의 클래스에만 적용되는 경우 (예 : 마술 상수 시나리오를 피하는 데 사용되는 경우) 클래스와 동일한 파일에 넣습니다.

enum SearchType { Forward, Reverse }

열거 형이 일반적이며 다른 시나리오에 대해 여러 클래스에서 사용할 수 있다면 자체 파일에 넣어 사용하는 경향이 있습니다. 예를 들어 아래는 여러 목적으로 사용될 수 있습니다.

enum Result { Success, Error }

클래스와 구조체와 마찬가지로 형식의 정의를 찾으려면 동일한 이름의 파일에서 찾을 위치를 정확히 아는 것이 좋습니다 . (공식적으로 VS에서는 항상 "정의로 이동"을 사용할 수 있습니다.)

분명히, 그것은 손에서 벗어날 수 있습니다. 내가 일하는 동료는 대리인을 위해 별도의 파일을 만듭니다.

열거 형에 별도의 파일을 사용하는 한 가지 장점은 열거 형을 사용한 원래 클래스를 삭제하고 열거 형을 사용하여 새 클래스를 작성할 수 있다는 것입니다.

열거 형이 원래 클래스와 독립적 인 경우 별도의 파일에 넣으면 나중에 변경하기가 더 쉽습니다.

Visual Studio 용 USysWare File Browser 추가 기능을 사용하는 경우 솔루션에서 특정 이름의 파일을 매우 빠르게 찾을 수 있습니다. 자체 파일이 아닌 거대한 솔루션으로 일부 파일에 묻힌 열거 형을 찾고 있다고 상상해보십시오.

작은 솔루션의 경우 중요하지 않지만 큰 솔루션의 경우 클래스와 열거를 자체 파일에 보관하는 것이 더 중요합니다. 신속하게 찾아서 편집하는 등의 작업을 수행 할 수 있습니다. 열거 형을 자체 파일에 넣는 것이 좋습니다.

그리고 언급했듯이 ... 어쨌든 몇 KB 만 남는 파일은 얼마나 낭비됩니까?

파일을 분리하는 매우 간단한 큰 장점. 개체가 자체 MyObjectName.cs 파일에 있으면 솔루션 탐색기로 이동하여 MyObjectName.cs를 입력하고 정확히 1 개의 파일을 표시 할 수 있습니다. 디버깅을 개선하는 것은 좋습니다.

비슷한 메모의 또 다른 장점은 모든 파일 ( ctrl+ shft+ F)에서 이름을 검색하면 동일한 파일에서 이름에 대한 20 개의 참조를 찾을 수 있으며 찾은 이름은 다른 객체의 일부가됩니다. 찾기 결과 창에서 줄 번호와 파일 이름 만 볼 수 있습니다. 파일을 열고 스크롤하여 찾은 참조가있는 오브젝트를 찾으십시오.

디버깅을 더 쉽게 만드는 것은 무엇이든 좋습니다.

하나의 솔루션에 여러 프로젝트가있는 경우 그런 다음 다른 프로젝트를 만드는 것이 좋습니다 Utilities. 그런 다음 폴더 \Enumerations를 만들고 중첩을 만듭니다 static class. 그런 다음 프로젝트 이름에 해당하는 열거 형을 만들 각 정적 클래스를 지정하십시오. 예를 들어 DatabaseReader 및 DatabaseUsers라는 프로젝트가 있으면 정적 클래스 이름을 다음과 같이 지정할 수 있습니다.

public static class EnumUtility {
    #region --Database Readers Enum
    public static class EnumDBReader {
         public enum Actions { Create, Retrieve, Update, Delete}; 
    }
    #endregion

    #region --Database Users Enum
    public static class EnumDBUsers {
         public enum UserIdentity { user, admin }; 
    }
    #endregion

}

그런 다음 프로젝트별로 전체 솔루션에 사용할 수있는 전체 열거 형이 선언됩니다. region각 관심사를 구분 하려면 # 을 사용하십시오 . 이를 통해 열거 형을 쉽게 찾을 수 있습니다.

각 별도의 열거 형을 포함하는 E라는 하나의 공개 열거 형 파일을 갖고 싶은 경우 E를 사용하여 모든 열거 형에 액세스 할 수 있으며 관리 할 한곳에 있습니다.