모듈화를 달성하기 위해 부분 클래스를 사용하는 것이 일반적입니까?

최근 코드 팀에서 다른 팀이 약 800 개의 메서드를 포함하는``신 클래스 ''를 만들고 135 개의 파일을 부분 클래스로 나누는 상황이 발생했습니다.

나는 다른 팀에게 이것에 대해 물었다. 내 직감은 궤도에서 핵을 피우는 것이었지만, 좋은 설계, 일반적인 관행이며 새로운 개발자가 나머지 지식을 거의 몰라도 기능을 강화할 수 있기 때문에 '모듈화'와 '구현 편의성'을 장려한다고 주장합니다. 시스템의.

이것은 실제로 일반적인 관행입니까 아니면 어떤 식 으로든 좋은 생각입니까? 나는이 짐승을 쓰러 뜨리기 위해 즉각적인 조치를 취하는 경향이있다.

이것은 좋은 생각이 아닙니다.

양식 디자이너를 돕기 위해 부분 클래스가 있습니다. 다른 이유로 (그리고 아마도 의도 된 목적으로 사용하지만 다른 문제임) 그것들을 사용하는 것은 나쁜 생각입니다.

이 방법을 살펴보십시오. 모든 파일의 위치를 ​​아는 한 파일에 800 개의 메소드가있는 신 클래스가 나쁜 것이라면 모든 사람들이 동의한다고 생각합니다. 135 개 파일에 걸쳐 확산, 당신은 어디 하지 않는 모든 것이 아마도 좋은 일이 될 위치를 알아?

따라서 질문은 다음과 같습니다.

이것은 실제로 일반적인 관행입니까 아니면 어떤 식 으로든 좋은 생각입니까?

현재 사용 가능한 답변 중 울려 퍼지는하지 아니가 . 그래서 내가 그것에 대해 차임 할 수있는 다른 것들이 거의 없습니다; 절차 적 코드조차 모듈 식으로 만들 수 있으며 모든 것을 포함하여 부엌 싱크대 는 모듈 식 을 얻는 방법이 아닙니다. 하나의 거대한 계급이 부분적으로 나뉘어지면 모두 하나의 큰 혼란에 빠지게됩니다.

그러나 그 질문은 실종 된 중요한 부분에 대한 청어입니다 . OP는 상황에 대해 다음과 같이 말합니다.

(...) 내 장의 반응이 궤도에서 핵을 공격하는 것이었지만 그들은 주장했다.

(...) 나는이 짐승을 쓰러 뜨리기 위해 즉각적인 조치를 취하는 경향이있다.

당신의 말을 보유!

여기에 비 유적으로 말하는 단안경이 비유적인 차 한잔에 떨어질 것입니다.

나는 비슷한 상황에 처해 있고 당신에게 말해 주겠다. 충동에 빠지지 마십시오 . 물론, 당신은 정의의 핵 망치를 팀에 떨어 뜨릴 수 있지만 그렇게하기 전에 다음과 같은 수수께끼로 자신을 유머하십시오.

팀에 코드가 빨라지고 떼어 내라고하면 어떻게 될까요?

(... 또는 그와 비슷하지만 공격적이지는 않지만, 당신이 그들에게 힘을 쏟기로 결정한 경우에 당신이 무엇을 하든지 불쾌하게 될 것이기 때문에 실제로 중요하지 않습니다)

코드베이스의 현재 상황은 무엇입니까? 작동 되나요? 그런 다음 고객에게 코드가 본질적으로 짜증나게 하는 데 큰 문제가 있습니다 . 이유가 무엇이든 관계없이 대부분의 클라이언트는 코드 구성 방식에 신경 쓰지 않습니다.

또한 신발에 몸을 담그면 어떻게해야합니까? 다음과 같은 가능한 결과로 당신을 즐겁게 해 드리겠습니다.

팀원 # 1 : "이 사람이 지난 몇 년간 우리가 잘못했다고 말하고 있습니다."

팀 구성원 # 2 및 # 3 : "정말 바보 야."

영향력있는 팀원 # 4 : "걱정하지 마십시오. 경영진에게 가서 괴롭힘으로보고하겠습니다."

영향력있는 팀원 # 4 가 어떤 역할을했는지 보셨습니까 ? 그는 경영진에게 가서 회사의 업장을 줄였습니다. 그는 미국-이탈리아 사람일지도 모릅니다. 모든 사람에게 그것에 대해 걱정하지 말라고 말하지만, 나는 그것에 대해 인종 차별적입니다.

불쾌한 팀을 모퉁이에 도장하여 그들이 오랫동안 잘못했다고 인정하게하는 것도 나쁜 생각이며 같은 일로 이어집니다. 당신은 존경과 사무실 정치 카르마를 잃을 것입니다.

"팀에게 교훈을주기"위해 많은 사람들이이 문제를 해결하도록했다고하더라도 분명히 일을하는 상당히 똑똑한 사람들에게이 일을하고 있다는 것을 기억하십시오. 일단 코드가 다시 작성 / 리팩터링 / dealt / 무엇을 했는지 와 문제가 발생 하면 firestarter로서 책임을 져야합니다 .

이와 같은 상황에 대해 적대적인 행동 은 악의적 인 비난 게임 이 될 위험이 있기 때문에 대부분 패배 / 잃어버린 게임입니다. 이것은이 상황에서 차선책입니다. 당신이이기더라도, 당신은 갑자기 다른 누군가가 한 혼란을 넘겨받습니다.

다른 (많은 성숙한) 방법이 있습니다

나는 비슷한 상황에 있었지만 무릎에 화살을 took습니다. 그래서 갑자기 갑자기 경력이 바뀌면서 화살표 가 바뀌면서 Terrence Ryan의 Driving Technical Change 라는 책 이 나왔습니다 . 그것은 사람들이 좋은 아이디어에 행동하지 않는 회의론자의 여러 패턴을 나열합니다. OP의 경우 모두 적용 가능성이 높습니다.

• 정보가없는 사람들-그들은 다른 방법이 있다는 것을 몰랐거나 단순히 이해하지 못했습니다. 주니어 개발자는 일반적으로이 범주에 맞지만 반드시 그런 것은 아닙니다. (솔직히 말하면, 나는 이것보다 더 밝은 주니어 개발자를 만났습니다.)
• The Herd-부분 클래스를 사용하는 것보다 더 나은 기술을 알고 있었지만 허용되는 것을 알지 못했습니다.
• Cynic-그들은 단지 부분 클래스를 갖는 것이 논쟁을 위해 당신의 생각보다 낫다고 주장하고 싶습니다. 군중 앞에 서있는 대신 군중에서 쉽게 할 수 있습니다.
• 불타 버린 사람들-이상한 이유로 새 클래스를 만들고 싶지 않은 경우가 많지만 너무 어렵다고 생각합니다.
• The Crunched-시간이 너무 바빠서 코드를 고칠 수 없습니다.
• 보스-그들은 생각합니다 : "잘 작동하지만 왜 귀찮게?"
• 불합리-좋아, 그들은 완전히 미쳤어.

이 책은 전략 목록 등으로 진행되지만 OP의 경우에는 설득의 문제입니다. 반 패턴에 대한 사실을 강하게 받아들이면 충분하지 않습니다.

코드 품질을 향상시키는 데 관심이 있다면 최소한 문제를 일으키는 팀에게 자신의 혼란을 반복하고 교정 할 수있는 기회를 제공하십시오 . 개인적으로 나는 주요한 질문을 듣고 질문함으로써 그들을 흔들어 그들의 이야기를 들려 주려고 노력합니다.

• 그들의 신 클래스는 정확히 무엇을하고 있습니까?
• 그들이 어떤 문제에 부딪 쳤습니까? 그들은 버그가 있습니까? 그렇게하도록 지시하지 않고 제정신 수정을 제안하십시오.
• 이 신 클래스의 사용자가 API 인 경우 : 전체를 사용하는 것보다 코드를 사용하는 간단한 방법이 있습니까? 더 간단한 예를 제안하고 어떻게 반응하는지보십시오.
• 함수를 작성하지 않고도 다른 기능을 전환 할 수 있습니까?
• 그들은 약간의 훈련이 필요합니까? 경영진에게 패턴을 제공하거나 패턴과 관행에 대해 점심 모임을 갖도록 설득 할 수 있습니까?

... 등등. 앞으로 나아갈 수 있도록 작은 제안을 해주십시오. 시간이 걸리고 사무실 정치 등급의 팔꿈치 그리스 가 필요 하지만 인내와 노력이 미덕입니까?

MSDN Partial Classes and Methods 페이지는 부분 클래스를 사용하는 두 가지 상황을 제안합니다.
1. 거대한 클래스를 여러 개의 개별 파일로 분할합니다.
2. 자동으로 생성 된 소스 코드를 넣을 장소.

2는 Visual Studio에서 많이 사용됩니다 (예 : aspx 파일 및 winforms). 이것은 부분 클래스를 합리적으로 사용하는 것입니다.

1은 팀이하는 일입니다. 나는 부분 클래스를 사용하는 것이 거대한 클래스를 가질 때 모듈화를 달성하기에 완벽하게 합리적인 방법이라고 말하지만, 거대한 클래스를 갖는 것은 그 자체가 불합리합니다. 다시 말해, 거대한 반을 갖는 것은 좋지 않은 생각이지만, 거대한 반을 가지려면 부분 반이 좋은 생각입니다.

다른 사용자가 작업 할 수 있도록 지능적으로 클래스를 별도의 파일로 분할 할 수 있지만 대신 별도의 클래스로 분할 할 수는 없습니까?

결국 그들은 OOP없이 정상적인 절차 적 개발을하고 있습니다. 그들은 모든 메소드, 변수 및 기타를 가진 하나의 전역 네임 스페이스를 가지고 있습니다.

그들이 잘못하고 있다고 설득하거나 지옥에서 나옵니다.

유틸리티 클래스에는 클래스를 만들기 위해 다른 메서드와 합리적으로 결합 할 수없는 메서드가 포함되어 있습니다. 800 개 이상의 방법이 있고 135 개 파일로 분할 된 경우 누군가가 일반적인 방법을 찾은 것 같습니다.

하나의 유틸리티 클래스가 있다고해서 다른 유틸리티 클래스를 가질 수 없다는 의미는 아닙니다.

800 가지와 관련이없는 메서드가 있더라도 솔루션은 하나의 큰 클래스가 아니며 많은 파일이 아닙니다. 해결책은 네임 스페이스, 일부 서브 네임 스페이스 및 많은 작은 클래스입니다. 이것은 조금 더 많은 일입니다 (방법뿐만 아니라 클래스의 이름을 생각해 내야합니다). 그러나이 혼란을 정리할 때가되면 인생을 더 쉽게 만들 수 있으며 그 동안 인텔리전스를 더 쉽게 사용할 수 있습니다 (즉, 방법이 어디에서 사용되는지 쉽게 알 수 있음).

그리고 아닙니다. 이것은 일반적이지 않습니다 (무료 기능의 수보다 많은 파일 수).

나는 이것을 전혀 좋아하지 않는다. 그러나 부분 클래스는 개발 중에 개발자에게 의미가있을 수 있습니다. 특히 많은 메소드가 서로 의존성이 많지 않은 경우이 메소드를 동시에 개발할 수 있기 때문입니다.

또 다른 가능성은 이러한 부분 클래스가 자동으로 생성 된 코어 클래스를 수정하기 위해 구축 된 것입니다. 이 경우 해당 항목을 건드리지 않아야합니다. 그렇지 않으면 다시 생성 할 때 사용자 지정 코드가 채찍질됩니다.

나는 누군가가 약간의 연구없이 이것을 쉽게 유지할 수 있는지 확실하지 않습니다. 이제 당신이 그것을 죽이면, 방법의 수는 줄어들지 않을 것입니다. 나에게있어 방법과 복잡성의 수는 실제 문제입니다. 메소드가 실제로 클래스에 속한다면, 특히 큰 유지 보수에서 1 개의 거대한 파일을 갖는 것이 인생을 더 쉽게 만들지 않을 것입니다. 실제로 와일드 카드 검색과 같은 바보 같은 실수에 대해이 코드를 모두 노출하는 것이 오류가 발생하기 쉽습니다 교체하십시오.

따라서 살인 결정을 조심하고 정당화하십시오. 또한 어떤 테스트가 필요한지 고려하십시오.

135 파일이 실제로 전통적인 클래스와 비슷한 방법으로 메서드를 그룹화한다고 가정하면 실용적인 디자인 관점에서 완벽하게 좋습니다. 파일 당 평균 6 개의 메소드입니다. 프로젝트를 디자인하는 가장 인기 있거나 전통적인 방법은 아닙니다. 변경하려고하면 많은 문제가 발생하고 실제 이익을 얻지 못할 것입니다. 프로젝트가 OO 표준을 준수하게하면 해결되는 한 많은 문제가 발생합니다. 여러 파일이 실제로 의미있는 분리를 제공하지 않으면 완전히 다른 문제입니다.

이미 지적한 답변 외에도 부분 클래스는 클래스 계층 구조를 별도의 레이어 별 파일로 교차 절단하는 기능을 구성하려는 레이어 디자인에 유용 할 수 있습니다. 이를 통해 솔루션 탐색기를 사용하여 계층 별 기능 (파일 구성 별)을 탐색하고 클래스보기를 통해 클래스 별 기능을 탐색 할 수 있습니다. 믹스 인 및 / 또는 특성을 지원하는 언어를 사용하고 싶지만, 부분 클래스는 드물게 사용하는 경우 합리적인 대안이며, 우수한 클래스 계층 구조 디자인을 대체해서는 안됩니다.