한 파일에 대해 하나의 클래스를 사용했습니다. 예를 들어 car.cs 에는 car 클래스가 있습니다 . 그러나 더 많은 클래스를 프로그래밍함에 따라 동일한 파일에 추가하고 싶습니다. 예를 들어 car.cs 에는 car 클래스 와 door 클래스 등이 있습니다.
내 질문은 Java, C #, PHP 또는 기타 프로그래밍 언어에 적합합니다. 동일한 파일에 여러 클래스를 포함하지 않아야합니까, 아니면 괜찮습니까?
답변:
코드를 파일 당 1 개의 클래스로 유지해야한다고 생각합니다.
나중에 수업을 더 쉽게 찾을 수 있기 때문에 이것을 제안합니다. 또한 소스 제어 시스템에서 더 잘 작동합니다 (파일이 변경되면 특정 클래스가 변경되었음을 알 수 있습니다).
파일 당 두 개 이상의 클래스를 사용하는 것이 옳다고 생각하는 유일한 경우는 내부 클래스를 사용할 때입니다. 그러나 내부 클래스는 다른 클래스 내에 있으므로 동일한 파일에 남아있을 수 있습니다. 내부 클래스 역할은 외부 클래스와 밀접한 관련이 있으므로 동일한 파일에 배치하는 것이 좋습니다.
파일 당 하나의 클래스가 좋은 규칙이지만 몇 가지 예외를 만드는 것이 적절합니다. 예를 들어, 대부분의 클래스에 관련된 컬렉션 유형이있는 프로젝트에서 작업하는 경우 클래스와 컬렉션을 동일한 파일에 보관합니다. 예 :
public class Customer { /* whatever */ }
public class CustomerCollection : List<Customer> { /* whatever */ }
경험상 가장 좋은 규칙은 파일 당 하나의 클래스를 유지하는 것입니다. 단, 작업이 더 어려워지기 시작하는 경우를 제외하고는 예외입니다. Visual Studio의 파일에서 찾기는 매우 효과적이기 때문에 어쨌든 파일 구조를 살펴 보는 데 많은 시간을 할애 할 필요가 없을 것입니다.
아니요, 전적으로 나쁜 습관이라고 생각하지 않습니다. 내가 의미하는 것은 일반적으로 클래스마다 별도의 파일을 갖는 것이 가장 좋지만 한 파일에 여러 클래스를 갖는 것이 더 좋은 예외 사례가 분명히 있다는 것입니다. 이에 대한 좋은 예는 Exception 클래스 그룹입니다. 주어진 그룹에 대해 이러한 클래스가 수십 개있는 경우 각 2 개의 라이너 클래스에 대해 별도의 파일을 갖는 것이 실제로 합리적입니까? 나는 주장하지 않을 것입니다. 이 경우 한 클래스에 예외 그룹을 갖는 것은 훨씬 덜 번거롭고 간단한 IMHO입니다.
IDE 에서 " Navigate to "기능을 제공하고 클래스 내에서 네임 스페이스를 제어 할 수 있기 때문에 동일한 파일 내에 여러 클래스를 갖는 아래의 이점은 저에게 상당히 가치가 있습니다.
부모-자식 클래스
대부분의 경우 기본 클래스 파일 내에 상속 된 클래스 가있는 것이 매우 유용 합니다.
그러면 자식 클래스가 상속하는 속성과 메서드를 쉽게 확인할 수 있으며 파일은 전체 기능에 대한 빠른 개요를 제공합니다.
공개 : 소규모-도우미-DTO 클래스
특정 기능을 위해 여러 개의 평범 하고 작은 클래스 가 필요할 때 모든 참조가있는 파일이 있고 4-8 Liner 클래스를 포함하는 것이 상당히 중복된다는 것을 알았습니다 .....
코드 탐색 은 또한 10 개의 파일 사이를 전환하는 대신 하나의 파일 위로 스크롤하기 만하면 더 쉽습니다. 또한 10 개가 아닌 하나의 참조 만 편집해야 할 때 리팩토링 하기가 더 쉽습니다 .....
전체적으로 파일 당 클래스 1 개의 Iron 규칙을 위반하면 코드를 구성 할 수 있는 추가적인 자유 가 제공 됩니다.
그때 일어나는 일은 실제로 IDE, 언어, 팀 커뮤니케이션 및 조직 기술에 달려 있습니다.
하지만 그 자유를 원한다면 왜 철칙을 위해 희생해야합니까?
내가 항상 따르는 규칙 은 동일한 이름의 파일에 하나의 메인 클래스를 갖는 것입니다. 파일의 기본 클래스와 얼마나 밀접하게 연결되어 있는지에 따라 해당 파일에 도우미 클래스를 포함하거나 포함하지 않을 수 있습니다. 지원 클래스는 독립형입니까, 아니면 자체적으로 유용합니까? 예를 들어, 클래스의 메서드가 일부 객체를 정렬하기 위해 특별한 비교가 필요한 경우 비교 펑터 클래스를 사용하는 메서드와 동일한 파일에 번들로 묶어 두는 것이 조금 귀찮지 않습니다. 나는 그것을 다른 곳에서 사용하기를 기대하지 않을 것이며 그것이 자체적으로 의미가 없습니다.
향후 개발 및 유지 관리 측면에서 나쁠 수 있습니다. Car.cs 클래스가 있으면 Car 클래스가 어디에 있는지 기억하는 것이 훨씬 쉽습니다. Widget.cs가 없으면 어디에서 Widget 클래스를 찾을 수 있습니까? 자동차 위젯인가요? 엔진 위젯입니까? 아, 아마도 베이글 위젯 일 것입니다.
파일 위치를 고려 하는 유일한 경우는 새 클래스를 만들어야 할 때입니다. 그렇지 않으면 파일 구조로 탐색 하지 않습니다 . 나는 "수업으로 가기"또는 "정의로 가기"를 사용합니다.
나는 이것이 다소 훈련 문제라는 것을 알고 있습니다. 프로젝트의 실제 파일 구조에서 벗어나려면 연습이 필요합니다. 그래도 매우 보람이 있습니다.)
같은 파일에 넣는 것이 기분이 좋다면 내 손님이되어주세요. 그래도 자바의 공용 클래스로 그렇게 할 수 없습니다.)
프로그래밍에서 많은 시간이 그렇듯이 상황에 따라 크게 달라집니다.
예를 들어, 문제가되는 클래스의 응집성은 무엇입니까? 그들은 단단히 결합되어 있습니까? 완전히 직각입니까? 기능면에서 관련이 있습니까?
웹 프레임 워크가 범용 위젯을 제공하는 것은 잘못된 것이 아닙니다.
프레임 워크의 사용자는 특정 도메인 공간에 대한 프레임 워크 위젯에서 파생 된 추가 위젯을 포함하도록 more_widgets 파일을 정의하는 데있어 라인을 벗어나지 않습니다.
클래스가 직교하고 서로 관련이없는 경우 단일 파일로 그룹화하는 것은 실제로 인위적입니다. 자동차를 만드는 로봇 공장을 관리하는 애플리케이션을 가정 해 보겠습니다. CarParts 및 RobotParts를 포함하는 부품이라는 파일은 무의미합니다. 유지 보수를위한 예비 부품 주문과 공장에서 제조하는 부품 간에는 별다른 관계가 없을 것입니다. 이러한 결합은 설계중인 시스템에 대한 정보 나 지식을 추가하지 않습니다.
아마도 가장 좋은 경험 법칙은 경험 법칙으로 선택을 제한하지 않는 것입니다. 경험 법칙은 첫 번째 컷 분석을 위해 또는 좋은 선택을 할 수없는 사람들의 선택을 제한하기 위해 만들어집니다. 대부분의 프로그래머는 자신이 좋은 결정을 내릴 수 있다고 믿고 싶어합니다.