C #의 부분 클래스는 잘못된 디자인입니까?

C #의 부분 클래스는 잘못된 디자인입니까?

---

왜 '부분 클래스'개념이 C # / VB.NET에 존재하는지 궁금합니다. 저는 응용 프로그램을 작업 중이며 우리가 작업중인 개발 플랫폼과 관련된 (실제로 아주 좋은) 책을 읽고 있습니다. 이 책에서 저자는 플랫폼 API에 대한 대규모 코드베이스 / 래퍼를 제공하고 플랫폼 개발에 대한 다양한 주제를 가르치면서 어떻게 개발했는지 설명합니다.

어쨌든 긴 이야기는 짧습니다. 그는 C # (IMO)에서 다중 상속을 가짜로 만드는 방법으로 모든 곳에서 부분 클래스를 사용합니다. 그가 수업을 여러 수업으로 나누지 않고 작곡을 사용하는 이유는 저를 넘어선 것입니다. 그는 자신의 기본 클래스를 구성하기 위해 3 개의 '부분 클래스'파일을 갖게 될 것입니다. 각 파일에는 3 ~ 500 줄의 코드가 있습니다. API에서이 작업을 여러 번 수행합니다.

이것이 정당하다고 생각합니까? 저라면 SRP를 따라 여러 클래스를 만들어서 다른 필수 동작을 처리 한 다음 이러한 클래스의 인스턴스를 구성원으로 포함하는 기본 클래스를 만들었습니다 (예 : 구성). MS는 왜 부분 클래스를 프레임 워크에 넣었습니까? 그들은 분명히 나쁜 습관을 허용했기 때문에 C #의 각 범위 수준에서 모든 코드를 확장 / 축소하는 기능을 제거했습니다 (C ++에서는 허용됨). 부분 클래스는 IMO도 마찬가지입니다. 내 질문은 다음과 같습니다. 부분 클래스를 사용하는 합법적 인 이유가 언제 있는지 설명해 주시겠습니까?

편집 : Web / WinForms에는 다른 선택이 없다는 것을 알고 있습니다. 하지만이 밖에? MS가 코드 생성 클래스를 결합하기 위해 다른 키워드를 넣지 않은 이유는 무엇입니까? 아니면 정말 합법적 인 디자인 시나리오가 있습니까?

나는 이것이 폭언 / 전쟁 스레드라는 것을 의미하지 않습니다. 솔직히 여기서 뭔가 배우고 싶어요. 코드 디자인에서 부분 클래스는 언제 사용해야합니까? 간단한 질문, 닫을 필요 없음

감사

---

부분 클래스를 사용하는 합법적 인 이유가 언제 있는지 설명해 주시겠습니까?

가장 합법적이고 유용한 이유 중 하나는 자동으로 생성 된 코드와 이에 대한 사용자 지정 확장을 분리하도록 장려하는 것입니다. 예를 들어, 어떤 종류의 디자이너로부터 자동으로 생성 된 양식 코드를 사용하는 것이 일반적이지만 일반적으로 고유 한 동작을 여기에 추가하려고합니다. 이렇게하면 자동 코드 부분을 재생성하는 경우 특정 확장이있는 부분을 건드리지 않습니다.

즉, 너무 많은 좋은 것을 가질 수 있습니다. 몇 가지 팁 :

• 을 위해 수업 partial을 만들지 마십시오 partial.

• 부분 클래스를 다른 곳에 두지 마십시오. 수업의 나머지 절반을보기 위해 프로젝트의 전혀 관련이없는 섹션으로 이동해야한다면 아마도 잘못하고있는 것입니다.

• partial클래스의 크기를 가리기위한 기술로 사용하지 마십시오 . 수업 partial이 너무 커서 수업을 나누는 경우 단일 책임 원칙을 다시 확인해야합니다 .

• partial같은 클래스에 대해 세 개 이상의 조각이있는 경우 부분적으로 남용하는 것이 거의 보장됩니다. 2는 합리성의 일반적인 상한이며 일반적으로 손으로 작성한 코드에서 자동으로 생성 된 코드를 분할하는 데 사용됩니다.

어쨌든 긴 이야기는 짧습니다. 그는 C # (IMO)에서 다중 상속을 가짜로 만드는 방법으로 모든 곳에서 부분 클래스를 사용합니다. 그가 수업을 여러 수업으로 나누지 않고 작곡을 사용하는 이유는 나 이상입니다. 그는 자신의 기본 클래스를 구성하기 위해 3 개의 '부분 클래스'파일을 갖게 될 것입니다. 각 파일에는 3 ~ 500 줄의 코드가 있습니다. API에서이 작업을 여러 번 수행합니다.

예, 그것은 분명히 partial!

---

부분 클래스를 사용하는 데에는 두 가지 이유가 있습니다.

1. 코드의 자동 생성 부분을 분리합니다 (예 : WinForms 디자이너 코드 또는 T4 출력).
2. 디자인에 필요한 캡슐화를 달성하면서 중첩 유형 자체 파일을 허용합니다.

업데이트
일부 사람들이 내 두 번째 요점에 대해 확신하지 못하는 것을 볼 수 있으므로 예를 들어 보겠습니다. ListViewItemCollection프레임 워크이다. ListView에서만 사용하기 때문에 아래에 중첩되어 ListView있지만 유지 관리를 훨씬 쉽게하기 위해 부분 클래스를 사용하여 자체 파일을 제공합니다. 나는 이것을 나쁜 디자인이나 partial키워드 의 오용으로 보지 않는다 .

자세한 내용은이 질문이 중복되는 질문을 확인하세요. C #의 부분 클래스

---

부분 클래스의 또 다른 합법적 인 사용은 WCF에서 "모 놀리 식 웹 서비스"혼란을 줄이는 것입니다. 이를 논리적 기능 그룹으로 나누고 싶지만 개별 서비스 인스턴스 / 엔드 포인트 (상태, 리소스 등을 공유하기 때문일 수 있음)를 생성 할 필요는 없습니다.

해결책? 서비스가 여러 인터페이스를 구현하고 자체 부분 클래스에서 각 인터페이스를 구현하도록합니다. 그런 다음 구성의 다른 끝점을 동일한 물리적 구현에 매핑합니다. 프로젝트를 훨씬 더 유지 관리 할 수있게 만들지 만 여전히 물리적 엔드 포인트는 하나뿐입니다.

어떤 경우에는 이러한 유형의 접근 방식을 SRP 때문에 좋지 않은 관행이라고 지적하지만 일반적으로 WCF 서비스 또는 웹 서비스로 작업 할 때는 그렇게 간단하지 않습니다. 내부 설계 요구 사항과 외부 소비 요구 사항의 균형을 맞춰야합니다.

---

덜 일반적인 용도 중 하나는 소스 제어 관점에서 삶을 더 쉽게 만들기 위해 거대한 클래스를 별도의 실제 파일로 분할하는 것입니다. 저는 수천 줄의 코드로 실행되는 엄청나게 비대해진 웹 서비스 클래스와 여러 다른 비즈니스 기능과 관련된 메서드가 포함 된 프로젝트에 방금 참여했습니다.

여러 기능 브랜치에서 병합하는 것은 서로 다른 팀이 동일한 파일에서 관련없는 변경을 동시에 수행하기 때문에 악몽입니다. 심각하게 변경하지 않고는 웹 서비스를 분할 할 수 없지만 클래스를 부분 클래스로 분할하면 동작이 정확하게 유지되고 여러 병합 문제가 제거됩니다.

나는 확실히 위의 디자인 선택을 장려하지는 않지만 우리에게는 좋은 빠른 승리였으며 부분적인 것이 항상 악하지 않다는 것을 보여줍니다 ...

---

나는 과거에 여러 가지 방법으로 부분 클래스를 사용했습니다. 프로그래밍과 특히 "상속보다 구성을 선호"하는 개념에 대해 더 많이 배우면서 수직적 상속과 부분 클래스의 남용에 대한 필요성이 감소한다는 것을 쉽게 알 수 있습니다.

자동 생성 코드 외에 부분 클래스를 잘 사용한다고 생각할 수 없습니다. EF를 사용하고 다른 메타 데이터가 필요한 경우에도 메타 데이터에 부분적 사용을 권장하지 않습니다. 사실 메타 데이터를 추가하기 위해 다른 부분에 속성을 복제하려고하면 컴파일러 오류가 발생합니다.

리팩토링과 SOC (Separation of Concerns)에 대해 더 많이 배울수록 더 작고 집중적 인 클래스가됩니다. 기본적으로 재사용되며 시간이 지남에 따라 방탄이되고 쉽게 테스트됩니다. 거대한 프로그램에 아니오라고 말하십시오. Henry Ford는 1900 년대 초에이 개념을 배웠습니다. 프로그래머들은 100 년 후부터이 개념을 배우기 시작했습니다.

다음과 같은 경우 구성 사용 ...

---

나는 John의 대답에 전적으로 동의합니다 . 하지만 한 걸음 더 나아갈 것입니다.

• 수업을 부분적으로 만들지 마십시오.

"좋은 디자인"이라고 생각할 수있는 부분 클래스의 유일한 사용은 자동으로 생성 된 코드를 사용하는 것입니다. 다른 용도는 거의 확실하게 클래스를 불필요하게 분할합니다. (사실, 중첩 클래스에 대한 Jeff의 두 번째 요점이 유효한 용도 일 수 있음을 알 수 있습니다.)

개인적으로 나는 당신이 읽고있는이 책이 나쁜 디자인처럼 들린다 고 생각한다. 그러나 그가 단지 부분적인 클래스를 사용하고 있기 때문에 한 번에 전체 클래스를 제시하는 것이 아니라 코드의 일부를 한 번에 조금씩 시연 할 수 있다고 생각한다.

---

부분 클래스를 사용하는 합법적 인 이유가 언제 있는지 설명해 주시겠습니까?

최신 버전의 Visual Studio는 부분 클래스를 사용하여 자동 생성 된 디자이너 코드를 사용자 코드에서 분리합니다.

ASP.NET 예제 :

• Page.aspx
• Page.aspx.cs <-코드
• Page.aspx.Designer.cs <-자동 생성 코드를 포함하는 부분 클래스입니다.

WinForms 예 :

• Form1.resx
• Form1.cs <-코드
• Form1.Designer.cs <-자동 생성 코드를 포함하는 부분 클래스

---

I've used partial classes to "physically" separate static data access methods from business class properties and methods in an active record architecture. For example, we had Company and CompanyData partial classes side-by-side. The advantage was that one file was the POCO and the other contained only data access methods. This was a stepping stone to removing data access to repository classes in a legacy application. I think that was a legitimate use, it certainly made the re-factoring process saner.

---

Another good use for partial classes would be when implementing the Abstract factory pattern. Make the root factory object partial and then place the actual factory methods in the same file as the class the factory instantiates.

EDIT: Partial classes also work well for classes that interact with a configuration file. Place the code containing the configuration parameters near the code that actually uses the configuration parameter.

---

Just stumbled across this thread while googling the benefits of partial class. I am in the process of converting a Java EE application into a silverlight based .NET one. I came across the following code in the view layer :

//------------------------------------------------------------------------------
// <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 {

Now, if the partial page itself is autogenerated, what's the use of maintaining it ? Also, the code inside just links various controls to their names. I don't confess to have knowledge of silverlight, but isnt this thing better suited in xaml?

---

Partial class exists in the .Net framework solely to let Visual Studio designers (e.g. the Asp.Net designer and the Windows Forms designer) to generate code / mess with your classes while keeping that generated code in a separate file.

(See .NET Partial Classes vs. Inheritance)

If you do something similar (generate code that needs to coexist with user-written code) then you might also find partial classes useful, but I don't believe that Microsoft ever intended partial classes as a language concept to be useful to anyone other than the Visual Studio team.

Its not so much that using Partial classes is bad design - its just you probably wont find a use for them.

---

I've used a partial class twice in VB.Net, and both times were for the rare occasion that I needed late binding. Simply create a partial class and turn Option Strict Off at the top.

---

Just to add on to the previous answers that mentioned separating generated code from custom code, I've found partial classes useful for extending strongly-typed datasets.

---

There's a lot of discussion out there on this topic, and lots of people saying that 1) it's bad design to use partial classes, 2) that it's used for autogenerated code, and 3) that it shouldn't take the place of inheritance.

I have a situation, though, in which partial classes look like they'll come in very handy: I'm building a series of applications which will eventually be integrated into a suite. They'll all have a main form which will provide some functionality, and several shared components (e.g., a form to display reports). While I could define a base class and inherit from it, that would mean a lot of rework when the time comes to combine all of the applications into the "enterprise" version of the product.

Thus, partial classes are quite useful, because I can quite simply include the various partial classes into the combined version, while still allowing me to build the individual, stand-alone versions of the product. If I were to try to accomplish this using inheritance, I'd end up with each component calling its own version of the common components (e.g., InvoiceReportViewer, PurchasingReportsViewer, etc.) rather than simply calling ReportsViewer and knowing that Visual Studio will have integrated all of the bits for me.

---

Another thing to consider, partial classes forces you to create different file names which contains same class name. For example you have FactoryClass and you are creating partial versions of it like; Factory.designer.cs, Factory.data.cs and all those files has class named FactoryClass.

If you navigate to this question; there is a best practice defined as:

Best practice, however, is to define one class per file and to give the file the same name as the class (or struct, etc.) being defined.

참고URL : https://stackoverflow.com/questions/2477839/are-cs-partial-classes-bad-design