수업과 방법을 가능한 작게 유지 하시겠습니까?

며칠 전, 나는 소프트웨어 공학 박사 후보와 이야기하고 있었고 어느 ​​시점에서 그녀는 나에게 말했다.

수업과 방법을 가능한 한 작게 유지하십시오

그리고 이것이 항상 좋은 습관인지 궁금합니다.

예를 들어, 복장이 2 개만있는 수업이 합당합니까? 예를 들어, 일부 방법에서는 작업 할 정수 쌍이 필요합니다. "PairOfIntgers"클래스를 작성해야합니까?

이런 생각이 코드를 너무 많은 조각으로 "파괴"할 수 있습니까?

그 조언에는 진실이 있지만 IMHO는 잘 표현되지 않았으므로 오해하기 쉽고 어리석은 극단에 빠지기 쉽습니다. 여하튼, 이것은 어려운 법이 아니라 경험의 법칙이어야합니다. 그리고 항상 그러한 규칙에서 "합리적인 한도 내에서" 또는 "상식을 사용하는 것을 잊지 마십시오" 라는 문구를 암시해야합니다. :-)

사실 , 클래스와 방법은 항상 축소되지 않고 자연적으로 자라는 경향이 있습니다 . 여기에 버그 수정, 약간의 기능 확장, 저기 특별한 경우를 처리합니다 ... 그리고 한 번 깔끔하고 작은 클래스가 더하기 시작합니다. 시간이 지남에 따라 리팩토링을 통해 이러한 경향에 적극적으로 대처하지 않는 한 코드는 필연적으로 스파게티의 엉망이되는 경향이 있습니다. 리팩토링은 거의 항상 몇 가지 큰 클래스에서 많은 작은 클래스 / 메소드를 생성합니다. 물론 소형화에는 상당한 한계가 있습니다. 리팩토링의 요점은 더 작은 클래스와 메소드를 가지지 않고 코드를 더 깨끗하고 이해하기 쉽게 유지하는 것입니다.. 특정 시점에서 메소드 / 클래스를 작게 만들면 가독성이 높아지기보다는 가독성이 떨어지기 시작합니다. 그 최적으로 향하십시오. 흐릿하고 움직이는 대상 영역이므로 적시에 맞출 필요가 없습니다. 다만코드에 문제가있을 때마다 코드를 약간 향상 시키십시오 .

여기서 강조해야 할 더 중요한 문제는 좋은 추상화를 만드는 것 입니다. 느슨하게 결합되고 응집력 이 높은 작은 클래스 는 좋은 추상화의 산물입니다 .

때로는 클래스에서 두 개의 정수를 캡슐화하는 것이 합리적입니다. 특히이 클래스에 '연결된'메소드를 사용하여 이러한 속성을 조작 할 수있는 방법을 캡슐화하고이를 변경하는 프로그램의 다른 부분으로부터 보호해야합니다.

이 경우 클래스를 생성하는 또 다른 긍정적 인 점은 클래스가 맵 또는 목록과 같은 하위 수준 데이터 구조를 말하는 것보다 훨씬 우수하거나 발전 할 수 있다는 것입니다.

셋째, 좋은 추상화는 가독성을 크게 향상시킬 수 있습니다. SRP를 준수하는 클래스는 일반적으로 그렇지 않은 클래스보다 사람이 이해하기 쉽습니다.

그리고 마지막으로, 당신이 얼마나 좋은 학생 이건간에 OOP와 좋은 추상화를 이해하고 그것들을 언제 사용해야하는지 경험이 필요합니다. 잘못된 코드를 작성하고 유지하기 위해 고통을 겪어야합니다. '좋은 것'과 무엇이 문제가 될지에 대한 지식을 쌓기 위해 다른 사람들이 좋은 코드를 작성하는 것을 볼 필요가 있습니다.

신의 물체 반 패턴 은 아마도 그녀가 암시했던 것입니다. 수업 설명에 "and"가 있으면 두 개의 수업이 있어야한다고 생각하는 경향이 있습니다. 메소드 / 함수에 10 줄 이상의 코드가 있으면이를 분해해야합니다. 해적 코드는 규칙보다 더 많은 지침입니다.

객체 지향 프로그래밍에서 단일 책임 원칙은 모든 객체가 단일 책임을 가져야하며 책임은 전적으로 클래스에 의해 캡슐화되어야한다고 명시합니다. 수업이 너무 커지면 보통 여러 가지 일을합니다. 귀하의 경우 클래스는 완전히 괜찮은 데이터를 보유하는 데이터 클래스 일뿐입니다. 클래스의 이름을 PairOfInteger로 지정해서는 안됩니다. 정수는 무엇을 설명합니까? 시나리오에 따라 Tuple (C #과 같은)도 충분할 수 있습니다. 클래스 대신 스트럿에 대해 생각하고 싶을 수도 있습니다.

수업을 작게 유지하십시오. 그리고 더 작은 방법. 아마 10 줄?!? 현재 클래스를 작게 유지하는 데 도움이되는 흐름 디자인 및 이벤트 기반 구성 요소를 사용하려고합니다. 처음에는 많은 수업을 듣는 것이 걱정되었지만 실제로 작동합니다 !!! http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03 /20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx

가능한 한 단순하지만 단순하지는 않습니다. 그것이 내가 가려고하는 규칙입니다. 때때로, 어떤 것이 일반적인 주제와 관련이 있다면 , 클래스가 말하기 이상의 것을 엄격하게 수행하는 것이 실제로 의미 가 있습니다 . .NET을보십시오; 많은 수의 인터페이스를 구현하는 수많은 클래스가 있으며 각 클래스에는 고유 한 필수 멤버 목록이 있습니다. 방법은 모두 서로 연결되어 추가 리팩토링에 적합하지 않은 여러 중간 단계로 복잡한 작업을 수행하는 경우 다소 길어질 필요가 있습니다. (메소드를 짧게 유지하기위한 리팩토링은 궁극적으로 가독성과 유지 보수성에 관한 것이어야합니다. 긴 메소드가 짧은 메소드보다 더 읽기 쉽고 유지 보수가 가능하다면, 다른 모든 것이 동일하다면, 매일 긴 시간이 걸릴 것입니다.)

제 생각에는 "클래스와 메소드를 가능한 한 작게 만드는 것"만 오도됩니다. 실제 도전은 @c_maker가 지적했듯이 좋은 추상화를 제공하는 것입니다. 예를 들어, 복잡한 숫자 산술 구현을 수행하거나 Unix 시스템에서 사용자 / 그룹 컨텍스트를 참조해야하는 경우 두 숫자를 함께 그룹화하는 예가 좋습니다. 숫자가 청구서 ID 및 해당 청구서에 추가 될 제품 ID를 나타내는 경우에는 거의 이해가되지 않습니다.

그것은 괜찮은 조언이지만 다소 지능적으로 구현되어야합니다. 맹목적으로 그것을 따르지 마십시오.

내 코드를 볼 때 메소드가 너무 큰지 알고 있습니다. 너무 많이하고 있고 읽기가 너무 어렵다면 리팩터링 시간입니다.

다음은 좋은 예입니다. 루프가 있고 해당 메소드에 60 줄의 코드가있을 수 있습니다. 이 경우 해당 방법으로 너무 많은 일을하고 있기 때문에 리팩토링해야 할 때입니다.

그러나 어렵고 빠른 규칙은 아닙니다. 그것은 당신이 수행함으로써 배울 수있는 것입니다. 그리고, 당신과 함께 일하는 다른 개발자들이 항상 동의하지는 않으며 코드 검토 등에서 당신을 불러 낼 수 있습니다.

Bob 아저씨는 분석법을 더 작게 만들 수 없을 때까지 리팩토링 / 분할 / 추출해야한다고 말합니다 . 이것은 일반적으로 각각 3 개 또는 4 개의 선으로 여러 방법을 갖는 것으로 끝납니다. 메서드가 너무 많으면 더 많은 클래스를 만들어야합니다.

메소드 당 SRP 및 한 레벨의 추상화를 따르려고하면이 규칙이 적합합니다. 적어도 그들은 나를 잘 섬 깁니다. "가능한 한 작게"를 목표로하는 것이 보통 목표에 미치지 못하기 때문에 합리적인 작은 방법을 제공합니다.

소규모 수업을 이해하는 것이 항상 더 쉽습니다. "클린 코드"를 읽으십시오.