나는이 규칙을 따르지만 일부 동료들은 이에 동의하지 않고 수업이 더 작 으면 다른 수업과 같은 파일에 남을 수 있다고 주장합니다.
내가 항상 듣는 또 다른 주장은 "마이크로 소프트도 그렇게하지 않는 이유는 무엇입니까?"
이것에 대한 일반적인 합의는 무엇입니까? 이것을 피해야하는 경우가 있습니까?
1
별도의 파일
나는이 규칙을 따르지만 일부 동료들은 이에 동의하지 않고 수업이 더 작 으면 다른 수업과 같은 파일에 남을 수 있다고 주장합니다.
내가 항상 듣는 또 다른 주장은 "마이크로 소프트도 그렇게하지 않는 이유는 무엇입니까?"
이것에 대한 일반적인 합의는 무엇입니까? 이것을 피해야하는 경우가 있습니까?
답변:
파일 당 하나의 클래스는 또한 파일의 차이점을 보지 않고 각 체크인이 무엇을 변경하는지에 대한 더 나은 아이디어를 제공합니다.
나는 사람들이 절대적으로 생각하고 당신이 이것과 같은 주관적이고 엄청나게 까다로운 것을 사용해서는 안된다고 말할 때 그것을 싫어합니다. 결론 : 파일 당 하나 이상의 클래스를 갖는 것이 의미가 있다면 완전히 좋습니다. 이해하기 쉬운 의미는 다음과 같습니다.
파일 당 여러 클래스를 원하는 이유에 대한 좋은 예 :
수십 개의 사용자 정의 예외 클래스가 있는데 각 클래스는 4 라이너이며, 각각에 대해 별도의 파일을 가질 수 있거나 예외를 그룹화하고 그룹 당 파일을 가질 수 있습니다. 나에게 가장 합리적인 / 실용적인 접근 방식은 그룹화하는 것입니다. 시간 / 코딩이 더 효율적이기 때문에 파일이 몇 개뿐입니다 (마우스 오른쪽 버튼을 클릭 할 필요가 없습니다-> 클래스 추가, 이름 바꾸기, 50 번) 따라서 솔루션의 혼란을 줄이고 성능을 향상시킵니다.
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
return (rule.Overhead(useCase)
< My.PersonalThresholds.ConformismVsPracticality);
}
나는 그들이 밀접하게 결합되어 있고 그 중 적어도 하나가 매우 작은 경우 파일에서 둘 이상의 클래스를 그룹화합니다.
일반적인 '모범 사례'는 수업 당 하나의 파일을 갖는 것입니다.
가상의 주장을 넘어서 Visual Studio IDE를 사용하는 Windows .NET에 집중하고 소프트웨어 프로젝트를 늘리는 것 외에도 파일 당 하나의 클래스를 갖는 것이이 맥락에서 의미가 있습니다.
일반적으로 시각적 참조의 경우 파일 당 하나의 클래스를 능가하지 않습니다. 정말.
나는 Microsoft가 똑같이하지 않는지 알지 못하지만 하나의 클래스를 여러 파일 로 나누기 위해 partial키워드 를 만들었습니다 (더 심각합니다). 자동 생성 된 디자이너 코드를 동일한 클래스 의 사용자 정의 코드에서 분리하는 데 종종 사용됩니다 (그러나 때로는 다른 개발자가 다른 파일을 통해 동시에 클래스에서 작업 할 수 있도록하는 데 사용됨). 따라서 Microsoft는 여러 파일의 이점을보고 있으며 .NET을 사용하면 누구나 여러 파일 구성을 염두에두고 있습니다.
중첩 클래스의 경우 하나의 파일 또는 적어도 클래스의 첫 번째 부분을 사용하는 것 외에는 선택의 여지가 없습니다. 이 경우 하나의 파일이 필요하고 훌륭합니다.
class BicycleWheel {
class WheelSpoke {
}
}
그렇지 않으면 왜 하나의 파일에 여러 클래스를 유지합니까? "작기 때문에" 또는 서로 연관되어 있다는 주장 은 결국 많은 수업이 다른 수업과 관련되기 때문에 많은 물을 보유하지 않습니다 . 궁극적으로 특히 소프트웨어가 계속 성장함 에 따라 객체 사용을 기반으로 파일 내 오브젝트 구성을 쉽게 유추 할 수 없습니다 .
또한 네임 스페이스에 폴더를 사용 하면 클래스 파일 이름 충돌이 발생하지 않습니다. 또한 Visual Studio와 같은 개발 환경에 있지 않을 때 파일 시스템에서 파일 이름으로 클래스 를 찾는 것이 편리합니다 (예 : 메모장 또는 빠른 / 가벼운 것을 사용하여 클래스를 빠르게 편집하려는 경우 ).
많은 이유가 있습니다 ...
partial내가 언급 한 키워드에 대한 간접적 인 참조 입니다.
partial msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx 일 수 있습니다. 나는 이것을 호기심에서 찾아 냈습니다.
나도 단일 파일에 하나의 유형이 포함되어야한다고 생각합니다.
이 규칙에는 한 가지 예외가 있습니다. 다음과 같은 일반적인 인수로만 다른 두 클래스가 있습니다.
RelayCommand 과
RelayCommand<T>1.cs for Foo <T>`와 Foo 2.cs for Foo <T, T1>` 과 같은 일반 클래스에 대한 또 다른 규칙이 있습니다.
Foo<T>과 Foo<U>같은 네임 스페이스 내에서. 그러나 네임 스페이스가 다르면 대개 다른 폴더에 있습니다. 따라서 대한 Foo<T>과 Foo<U>는 푸해야 1.cs and for 푸 <U, T>`Foo`2.cs. 그러나 여전히 파일 당 하나의 클래스입니다.
실제로 이것은 개인적인 취향으로 요약됩니다. 모두가 "파일 당 하나의 클래스"라고 말하지만, 우리는 특정 상황에서이를 피해야 할 이유가 있습니다. 나는 약 300 개의 다른 열거 형을 가진 큰 프로젝트를 가지고있었습니다. 열거 형 중 일부가 3 상태 일 때 각 클래스마다 하나씩 300 개의 별도 파일을 가지지 않을 것입니다.
또한 이름이 지정된 파일에 모두없는 경우 특정 클래스를 찾을 수없는 사람들을 위해 전체 솔루션에서 찾기를 사용하지 않는 이유가 있습니까? 찾기를 사용하면 솔루션 탐색기를 통해 시간을 절약 할 수 있습니다.
나는 일반적으로 파일 당 하나의 클래스를 가지고 있지만 일반적으로 파일은 관련 클래스를 포함 할 수 있는지 확인하기 위해 자신과 다른 개발자가 재사용 할 수있는 예외 그룹화와 같은 관련 클래스를 포함해야합니다. 이 경우 사용자는 여러 파일이 아닌 하나의 파일 만 포함하면됩니다.
요점은 다음과 같습니다. 신중함을 사용해야합니다 !!!
더 큰 솔루션에서는 파일 당 하나의 클래스를 갖는 것이 매우 중요하며 파일의 이름은 클래스와 동일합니다. 작업해야하는 코드를 훨씬 쉽게 찾을 수 있습니다.
C # 용 StyleCop 도구에는 하나의 네임 스페이스에 하나 이상의 최상위 클래스가 필요하지 않은 표준 규칙이 있으며 해당 네임 스페이스에 인터페이스, 대리자 및 열거 수가 있습니다.
두 번째 및 그 이후의 클래스가 첫 번째 클래스에서만 사용되는 두 개 이상의 클래스의 경우 소비 클래스에만 보이는 내부 클래스 일 수 있고 있어야합니다.
namespace블록에 해당됩니까?
때때로 파일 당 하나의 클래스 이지만 ...
여러 클래스가 엄격하게 관련되어있는 경우 동일한 소스 파일에있는 둘 이상의 클래스는 각 클래스에 짧은 소스 파일을 전용하는 것보다 IMHO, BETTER 입니다. 소스는 더 읽기 쉽고 컴팩트합니다. #region을 사용하면 동일한 소스를 이전보다 더 체계적으로 구성 할 수 있습니다.
가끔은 있다고도 고려 는 필요한 다른 파일 (사용에서 동일한 클래스를 확산 부분 )는 20000+ 라인 소스 파일을 가지고 있기 때문에하는 것은, 심지어 내가 사용할 수있는 RAM과 편리하지 않다 (그러나 이것은 또 다른 문제이다).
때로는 작은 클래스를 더 큰 클래스로 남겨 두지 만 객체와 컬렉션 클래스 또는 팩토리와 매우 밀접하게 관련되어있는 경우에만 가능합니다.
그래도 한 가지 문제가 있습니다. 결국 작은 클래스는 자체 파일에 있어야 할 시점까지 커집니다. 새 파일로 이동하면 수정 내역에 쉽게 액세스 할 수 없게됩니다.
즉.
very tightly related클래스를 만들고 소량의 화면 공간 만 차지하고 다른 클래스에서 동일한 목적으로 사용하지 않는 한 그대로 둡니다.
정말 문제가 되나요? :)
열거 형과 마찬가지로 실제로 작은 클래스는 다른 클래스와 함께 사용할 수 있습니다. 따라야 할 규칙이 하나 있습니다. 공통점이있는 클래스 만 모으십시오.
내 프로젝트 중 하나에 150 클래스가 들어있는 파일이 있습니다. 파일에는 10000 줄의 코드가 있습니다. 그러나 자동 생성되므로 완전히 허용됩니다 :)
여러 관련 클래스를 하나의 파일 에 넣는 한 가지 이유 는 API를 사용하는 가난한 나쁜 녀석이 수입 신고 상용구를 입력하는 데 반나절을 소비 할 필요가없고 코드를 유지해야하는 나쁜 자식은 절반을 소비 할 필요가 없기 때문입니다 수입 신고 상용구를 스크롤하는 하루. 필자의 경험상, 거의 항상 한 번에 하나씩이 아니라 큰 클래스의 하위 집합을 거의 동시에 사용하는 경우 여러 클래스가 동일한 파일에 속합니다.
나는 이것을한다. 그러나 클래스가 아이-부모 방식으로 관련되고 아이 클래스가 부모에 의해서만 사용되는 경우에만.
나는 보통 파일 당 하나의 클래스를 고수합니다. 그러나 프로젝트 전체에서 사용되는 유사한 구조의 그룹에는 예외를 적용 할 것입니다. 예를 들면 다음과 같습니다.
EventArgs서브 클래스 를 포함하는 EventArgs.cs 는 일반적으로 각각 5-10 줄의 코드이지만 일반적으로 여러 클래스에서 사용됩니다. 또는 EventArgs클래스를 이벤트를 선언하는 클래스와 동일한 파일에 넣을 수 있습니다.enum프로젝트 전체에서 사용되는 을 포함하는 Enums.cs . ( enum한 클래스에서만 사용되는 클래스가있는 경우 일반적 private으로 해당 클래스로 작성합니다.)One case could be:수업은 공동으로 형성 할 때 module / unit같은 몇 가지 기본 클래스 역할을하는 helper classes다른 현명한 아니오 .
ASP.NET MVC 2.0 프로젝트 소스 코드를 살펴보십시오 . 이 규칙을 엄격히 준수합니다
다른 사람이 언급하지 않은 또 다른 요점은 파일 규칙 당 하나의 클래스를 사용하여 개발할 때 해당 특정 클래스가 사용중인 것을 쉽게 볼 수 있다는 것입니다.
예를 들어, 한 클래스는 Linq를 사용하고 다른 클래스는 그렇지 않은 두 개의 클래스가있을 수 있습니다.
이러한 클래스가 동일한 파일에 있으면 코드를 살펴 보지 않고 어떤 클래스가 무엇을 사용하는지 알 수 없습니다. 파일 당 하나의 클래스 인 경우 파일의 상단을보고 해당 클래스에서 사용중인 항목을 정확히 확인하기 만하면됩니다. 새 라이브러리 등으로 마이그레이션하는 경우 도움이됩니다.
지금까지 게시 된 답변에 언급되지 않은 파일 당 하나의 클래스에 대한 또 다른 이유는 파일 당 하나의 클래스가 코드 검토 중에 PR의 영향을보다 쉽게 이해할 수 있기 때문입니다. 또한 병합 충돌을 줄입니다.
누군가 피드백을 위해 PR을 게시하면 변경된 파일 목록을보고 즉시 작업중인 내용과 겹치는 부분을 볼 수 있습니다. 중복에 따라 코드를 더 깊이 보거나 확인을 원할 수도 있습니다. 내 변경 사항에 영향을 미치지 않을 것이라고 확신합니다.
두 사람이 다중 클래스 파일에서 작업하고 둘 다 종속성을 추가 using하면 맨 위 블록에서 병합 충돌이 발생할 가능성이 큽니다 . 클래스를 파일로 분리하면 종속성이 분리되어 각 클래스가 무엇을 사용하고 있는지 확인할 수 있으며 이와 같은 충돌이 발생하지 않습니다.
이 규칙에는 예외가 있지만 (인터페이스 + 구현, 열거 형, ...) 주니어 개발자는 일반적으로 모든 관련없는 클래스를 동일한 파일에 묶을 수있는 반대보다 더 나은 시작 위치입니다.
파일 당 하나의 클래스는 해석이 적용되지 않는 명백한 명확한 규칙입니다.
파일 내 관련 클래스는 개인 취향과 해석에 따라 달라집니다 (여기서 다른 답변에서 사용이 가능한시기에 대해 알 수 있듯이). 따라서 잘못된 규칙입니다.
앞뒤로 매우 흥미롭고 결정적으로 보이지만 내 일반적인 인상은 클래스와 파일 간의 1-1 매핑이 대부분의 의견이지만 개인마다 예외가 있다는 것입니다.
(1) Windows Forms 앱, 웹 앱, 라이브러리 등을 개발하는지에 따라 답변이 달라지는 지 궁금합니다. 또는 (2) Visual Studio 사용 여부. VS를 사용하는 경우 파일 당 하나의 클래스 규칙이 VS 프로젝트 당 하나의 클래스를 의미하는 것으로 보입니다. 다른 스레드의 의견은 VS 솔루션 / 프로젝트가 디렉토리 / 파일 이름 지정 및 구조에 미러링되어야한다는 것 같습니다. 실제로 필자는 프로젝트 이름 = 어셈블리 이름 = (중첩 된) 네임 스페이스 이름을 사용하여 디렉토리 / 파일 이름 지정 및 구조에 미러링 될 수 있다는 인상을 받았습니다. 이것이 올바른 지침 (또는 규칙)이라면, 이러한 모든 직교 조직 메커니즘은 동기화되어 유지 될 것입니다.