C#의 부분 수업은 나쁜 디자인입니까?
왜 C#/VB에 '부분 클래스' 개념이 존재하는지 궁금합니다.NET. 저는 애플리케이션을 개발하고 있으며, 회사에서 구현하고 있는 개발 플랫폼과 관련된 (실제로 매우 좋은) 책을 읽고 있습니다.책에서 저자는 플랫폼 API에 대한 큰 코드 기반/랩퍼를 제공하고 플랫폼 개발에 대한 다양한 주제를 가르치면서 어떻게 개발했는지 설명합니다.
어쨌든 긴 이야기를 하자면, 그는 C#(IMO)에서 다중 상속을 위장하기 위한 방법으로 곳곳에서 부분 수업을 사용합니다.왜 그가 수업을 여러 개로 나누고 작문을 사용하지 않았는지 이해할 수 없습니다.그는 기본 클래스를 구성하기 위해 3개의 '부분 클래스' 파일을 가질 것이고, 각 파일은 3-500줄의 코드로 구성될 것입니다.그리고 이것은 그의 API에서 여러 번 수행됩니다.
당신은 이것이 정당하다고 생각합니까?저였다면 S.R.P.를 따라 여러 클래스를 만들어 서로 다른 필수 동작을 처리한 다음 이러한 클래스의 인스턴스(예: 구성)를 구성원으로 하는 기본 클래스를 만들었을 것입니다.왜 MS는 부분 수업까지 프레임워크에 넣었을까요?그들은 C#(이것은 C++에서 허용됨)의 각 범위 수준에서 모든 코드를 확장/축소하는 기능을 제거했습니다. 왜냐하면 그것은 분명히 나쁜 습관을 허용했기 때문입니다. 부분 클래스는 IMO와 같습니다.제 질문은 다음과 같습니다: 언제 부분 수업을 사용해야 하는 정당한 이유가 있는지 설명해 주시겠습니까?
편집: 웹/WinForms의 경우 다른 선택의 여지가 없다는 것을 알고 있습니다.하지만 이 밖에?왜 MS는 코드가 부여된 클래스를 함께 결합하기 위해 몇 가지 다른 키워드를 넣지 않았습니까?아니면 정말 그럴만한 가치가 있는 합법적인 설계 시나리오가 있습니까?
나는 이것이 호언장담을 하려는 것이 아닙니다.저는 솔직히 여기서 무언가를 배우고 싶습니다.코드 설계에서 부분 클래스는 언제 사용되어야 합니까?간단한 질문이므로 닫을 필요가 없습니다.
감사해요.
언제 부분 수업을 이용해야 하는 정당한 이유가 있는지 설명해 주시겠습니까?
가장 합법적이고 유용한 이유 중 하나는 자동으로 생성된 코드와 해당 코드에 대한 사용자 정의 확장을 분리하도록 권장하는 것입니다.예를 들어, 디자이너가 자동으로 생성한 양식 코드를 가지고 있는 것이 일반적이지만 일반적으로 사용자 고유의 동작을 추가하려고 합니다.이렇게 하면 자동 코드 부분을 재생성할 경우 특정 확장자가 있는 부분은 건드리지 않습니다.
그렇긴 하지만, 좋은 것을 너무 많이 갖는 것은 꽤 가능합니다.몇 가지 팁:
에 참여하지
partial…이 위해partial.부분 수업은 다른 수업 외에는 아무 곳에나 두지 마세요.만약 여러분이 수업의 나머지 절반을 보기 위해 프로젝트의 전혀 관련이 없는 부분으로 점프해야 한다면, 여러분은 아마도 잘못하고 있는 것입니다.
사용하지
partial수업의 규모를 모호하게 하기 위한 기술로서.만약 당신이 당신의 수업을 그만둔다면.partial너무 크기 때문에 단일 책임 원칙을 다시 검토해야 합니다.의 3개 이상이 있는
partial같은 클래스에 대한 파편입니다. 부분적으로 남용하고 있다는 것은 거의 보장됩니다.두 번째는 합리성의 전형적인 상한이며, 일반적으로 손으로 작성된 코드에서 자동으로 생성된 코드를 분할하는 데 사용됩니다.
어쨌든 긴 이야기를 하자면, 그는 C#(IMO)에서 다중 상속을 위장하기 위한 방법으로 곳곳에서 부분 수업을 사용합니다.왜 그가 수업을 여러 개로 나누고 작문을 사용하지 않았는지 저는 이해할 수 없습니다.그는 기본 클래스를 구성하기 위해 3개의 '부분 클래스' 파일을 가질 것이고, 각 파일은 3-500줄의 코드로 구성될 것입니다.그리고 이것은 그의 API에서 여러 번 수행됩니다.
네, 그것은 확실히 명백한 학대입니다.partial!
제가 부분 수업을 이용하는 이유는 두 가지가 있습니다.
- 코드의 자동 생성 부분(예: WinForms 디자이너 코드 또는 T4 출력)을 분리합니다.
- 설계에 필요한 캡슐화를 수행하면서 중첩된 파일을 입력할 수 있습니다.
두 요점에 을 갖지 못하는 이 있다는 을 알 수 . ; 나는일사부람들나대못확요해한다것로, 니습들겠보어예를므있으;ListViewItemCollection틀 안에서그것은 아주 정확하게 아래에 내포되어 있습니다.ListView그것은 오직 에 의해서만 사용되기 때문입니다.ListView유지보수를 훨씬 쉽게 하기 위해 부분 클래스를 사용하여 자체 파일을 제공합니다.저는 이것이 나쁜 디자인이나 오용이라고 생각하지 않습니다.partial키워드
더 많은 토론을 위해, 이 질문이 중복되는 질문을 확인하세요: C#의 부분 수업.
부분 클래스를 합법적으로 사용하는 또 다른 방법은 WCF의 "모놀리식 웹 서비스" 혼란을 줄이는 데 도움이 됩니다.이를 여러 기능의 논리적 그룹으로 나누고 싶지만 개별 서비스 인스턴스/엔드포인트(상태, 리소스 등을 공유하기 때문에)를 여러 개 생성할 필요는 없습니다.
해결책?서비스가 여러 인터페이스를 구현하고 각 인터페이스를 자체 부분 클래스로 구현하도록 합니다.그런 다음 구성의 서로 다른 엔드포인트를 동일한 물리적 구현에 매핑합니다.따라서 프로젝트를 훨씬 더 유지 관리할 수 있지만 물리적 끝점은 하나뿐입니다.
경우에 따라 SRP 때문에 이러한 유형의 접근 방식이 좋지 않다고 지적할 수도 있지만, 일반적으로 WCF 서비스나 웹 서비스를 사용하는 경우에는 그렇게 간단하지 않습니다.내부 설계 요구사항과 외부 소비 요구사항의 균형을 맞춰야 합니다.
일반적으로 사용되지 않는 한 가지 방법은 대용량 클래스를 별도의 물리적 파일로 분할하여 소스 제어 관점에서 보다 쉽게 작업할 수 있도록 하는 것입니다.저는 방금 수천 줄의 코드와 여러 가지 다른 비즈니스 기능과 관련된 방법으로 실행되는 엄청나게 비대해진 웹 서비스 클래스를 포함하는 프로젝트에 참여했습니다.
서로 다른 팀이 동일한 파일에서 관련 없는 동시 변경을 수행하기 때문에 다양한 피쳐 분기에서 병합하는 것은 악몽입니다.심각하게 깨지는 변경을 하지 않고는 웹 서비스를 분할할 수 없지만, 클래스를 부분 클래스로 분할하면 동작이 정확하게 보존되고 병합 문제가 많이 제거됩니다.
저는 디자인 선택으로 위의 것들을 장려하는 것은 아니지만, 그것은 우리에게 좋은 빠른 승리였고, 부분적인 것들이 항상 사악하지 않다는 것을 보여줍니다.
저는 과거에 부분 수업을 다양한 방법으로 사용했습니다.프로그래밍과 특히 "상속보다 호의적인 구성"의 개념에 대해 더 많이 배울수록 수직적인 상속과 부분적인 수업의 남용에 대한 필요성이 감소하는 것을 쉽게 알 수 있습니다.
자동 생성된 코드 외에는 부분 수업을 잘 활용하는 것이 생각나지 않습니다.EF를 사용하고 다른 메타데이터가 필요하더라도 메타데이터에 부분적인 사용은 권장하지 않습니다.실제로 메타데이터를 추가하기 위해 다른 부분에서 속성을 복제하려고 하면 컴파일러 오류가 발생합니다.
리팩터링과 SOC(Separation of Concern)에 대해 더 많이 배울수록 우리의 수업은 더 작고 집중하게 됩니다.기본적으로 재사용되며 시간이 지남에 따라 방탄 처리되고 쉽게 테스트됩니다.거창한 프로그램에 대해서는 그냥 아니라고 말하세요.헨리 포드는 1900년대 초에 이 개념을 배웠습니다. 프로그래머들은 100년 후에 그것을 배우기 시작했습니다.
할 수 있을 때 합성 사용...
저는 존의 대답에 전적으로 동의합니다.하지만 저는 한 걸음 더 나아갈 것입니다.
- 수업을 편파적으로 하지 마세요.
제가 "좋은 디자인"이라고 생각할 수 있는 부분 클래스의 유일한 용도는 자동으로 생성된 코드를 사용하는 것입니다.다른 용도는 거의 틀림없이 불필요하게 수업을 분열시키는 것입니다.(사실, 중첩된 클래스에 대한 Jeff의 두 번째 포인트는 아마도 유효한 용도일 것이라는 것을 알 수 있습니다.)
개인적으로 저는 당신이 읽고 있는 이 책이 나쁜 디자인처럼 들린다고 생각하지만, 그가 전체 수업을 한 번에 발표하는 것이 아니라 한 번에 코드의 일부를 데모할 수 있도록 부분 수업을 사용하는 것일 수도 있다고 생각합니다.
언제 부분 수업을 이용해야 하는 정당한 이유가 있는지 설명해 주시겠습니까?
최신 버전의 Visual Studio에서는 부분 클래스를 사용하여 자동 생성된 디자이너 코드와 사용자 코드를 구분합니다.
ASP.NET 예:
- Page.aspx
- Page.aspx.cs <- 귀하의 코드
- Page.aspx.Designer.cs <- 자동 생성 코드를 포함하는 부분 클래스입니다.
WinForms의 예:
- 양식 1.resx
- Form1.cs <- 귀하의 코드
- Form1.Designer.cs <- 자동 생성 코드를 포함하는 부분 클래스
저는 부분 클래스를 사용하여 정적 데이터 액세스 방법과 비즈니스 클래스 속성 및 활성 레코드 아키텍처의 방법을 "물리적으로" 분리했습니다.예를 들어 Company와 CompanyData 부분 수업을 나란히 진행했습니다.장점은 한 파일은 POCO이고 다른 파일은 데이터 액세스 방법만 포함한다는 것이었습니다.이는 레거시 응용프로그램의 리포지토리 클래스에 대한 데이터 액세스를 제거하기 위한 디딤돌이었습니다.저는 그것이 합법적인 사용이었다고 생각합니다, 그것은 확실히 재요인화 과정을 더 무감각하게 만들었습니다.
부분 클래스에 대한 또 다른 유용한 사용은 추상 팩토리 패턴을 구현할 때입니다.루트 팩토리 개체를 부분적으로 만든 다음 실제 팩토리 메서드를 팩토리 인스턴스화 클래스와 동일한 파일에 배치합니다.
편집: 부분 클래스는 구성 파일과 상호 작용하는 클래스에도 적합합니다.구성 매개 변수가 포함된 코드를 구성 매개 변수를 실제로 사용하는 코드 근처에 배치합니다.
부분 수업의 이점을 검색하다가 우연히 이 스레드를 발견했습니다.자바 EE 애플리케이션을 실버라이트 기반으로 변환하는 중입니다.NET 1번.보기 계층에서 다음 코드를 발견했습니다.
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.225
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
...
public partial class Wwcusts04d : System.Windows.Controls.Page {
자, 만약 부분 페이지 자체가 자동 생성된다면, 그것을 유지하는 것이 무슨 소용이 있습니까?또한 내부의 코드는 다양한 컨트롤을 이름에 연결합니다.은빛에 대한 지식을 가지고 있다고 고백하진 않지만, 이것이 xaml에 더 적합하지 않나요?
부분 클래스가 에 있습니다.Visual Studio 디자이너(예: As)만 허용하는 Net 프레임워크입니다.Netdesigner 및 Windows Forms designer) - 생성된 코드를 별도의 파일에 보관하면서 클래스에 코드/혼란을 생성합니다.
(.NET 부분 클래스 vs. 참조) 상속)
유사한 작업(사용자가 작성한 코드와 공존해야 하는 코드 생성)을 수행하면 부분 클래스도 유용할 수 있지만 Microsoft가 Visual Studio 팀 이외의 다른 사람에게 유용한 언어 개념으로 부분 클래스를 의도한 적은 없다고 생각합니다.
부분 클래스를 사용하는 것은 나쁜 디자인이 아닐 뿐만 아니라 사용법을 찾을 수 없을 것입니다.
저는 VB에서 부분 수업을 두 번 사용했습니다.네트, 그리고 두 번 모두 제가 늦게 바인딩해야 하는 드문 경우를 위한 것이었습니다.부분 클래스를 만들고 맨 위에서 Option Strict Off(옵션 엄격 해제)를 해제하기만 하면 됩니다.
생성된 코드와 사용자 지정 코드를 분리하는 것에 대해 언급한 이전 답변에 추가하기 위해 강력한 유형의 데이터 세트를 확장하는 데 유용한 부분 클래스를 찾았습니다.
이 주제에 대해 많은 논의가 이루어지고 있는데, 많은 사람들이 1) 부분적인 클래스를 사용하는 것은 나쁜 디자인이고, 2) 자동 생성된 코드에 사용되는 것이며, 3) 상속을 대신해서는 안 된다고 말합니다.
하지만 저는 부분 수업이 매우 유용할 것처럼 보이는 상황이 있습니다.저는 최종적으로 제품군에 통합될 일련의 애플리케이션을 구축하고 있습니다.이들은 모두 몇 가지 기능을 제공하는 기본 양식과 몇 가지 공유 구성요소(예: 보고서를 표시하는 양식)를 가지고 있습니다.기본 클래스를 정의하고 이 클래스에서 상속할 수는 있지만, 모든 애플리케이션을 제품의 "엔터프라이즈" 버전으로 결합할 때 많은 재작업이 필요합니다.
따라서 부분 클래스는 매우 유용합니다. 다양한 부분 클래스를 결합 버전에 쉽게 포함할 수 있는 동시에 제품의 개별 독립형 버전을 구축할 수 있기 때문입니다.상속을 사용하여 이 작업을 수행하려는 경우에는 단순히 ReportsViewer에 전화를 걸어 Visual Studio가 모든 비트를 통합한다는 사실을 아는 대신 각 구성 요소가 자체 버전의 공통 구성 요소(예: InvoiceReportViewer, PurchasingReportViewer 등)를 호출하게 됩니다.
부분 클래스는 동일한 클래스 이름을 포함하는 다른 파일 이름을 생성하도록 강제합니다.예를 들어 FactoryClass가 있고 Factory.designer.cs , Factory.data.cs 과 같은 부분 버전을 만들고 있으며 이러한 모든 파일에는 FactoryClass라는 이름의 클래스가 있습니다.
이 질문으로 이동하면 다음과 같이 정의된 모범 사례가 있습니다.
그러나 파일당 하나의 클래스를 정의하고 파일에 정의할 클래스(또는 구조체 등)와 동일한 이름을 지정하는 것이 가장 좋습니다.
언급URL : https://stackoverflow.com/questions/2477839/are-cs-partial-classes-bad-design
'programing' 카테고리의 다른 글
| WPF의 app.config에서 값 목록 모음을 가져오는 방법은 무엇입니까? (0) | 2023.05.11 |
|---|---|
| 최근 커밋에 대해서만 GitHub에서 꺼내기 요청 전송 (0) | 2023.05.11 |
| Xcode 6의 AutoLayout 제약조건을 사용한 애스펙트 핏 거동 에뮬레이션 (0) | 2023.05.11 |
| IntelliJ IDEA에서 예외 스로더 강조 (0) | 2023.05.11 |
| PowerShell 어레이 초기화 (0) | 2023.05.11 |