왜 디자인 패턴에 많은 클래스가 필요한가?

나는 선배들 사이에서 주니어 개발자이며 그들의 생각과 추론을 이해하는 데 많은 어려움을 겪고 있습니다.

나는 읽고있다 도메인 기반 디자인 (DDD)를 우리는 너무 많은 클래스를 생성해야하는 이유 이해할 수 없습니다. 소프트웨어 설계 방식을 따르면 20-30 개의 클래스로 끝나고 최대 2 개의 파일과 3-4 개의 함수로 대체 될 수 있습니다. 예, 이것은 지저분 할 수 있지만 훨씬 유지 관리가 쉽고 읽기 쉽습니다.

어떤 종류의 일을보고 싶을 때마다 EntityTransformationServiceImpl많은 클래스, 인터페이스, 함수 호출, 생성자, 생성 등을 따라야합니다.

간단한 수학 :

• 60 줄의 더미 코드와 10 개의 클래스 X 10 (우리는 완전히 다른 논리를 가지고 있다고합시다) = 600 줄의 지저분한 코드와 100 개의 클래스 + 랩과 관리를 위해 더 많은 것; 의존성 주입을 추가하는 것을 잊지 마십시오.
• 600 줄의 지저분한 코드 읽기 = 하루
• 100 수업 = 일주일, 여전히 어떤 수업을하는지 잊어 버리십시오.

누구나 유지 관리가 쉽다고 말하고 있지만 무엇을 위해서입니까? 새로운 기능을 추가 할 때마다 팩토리, 엔터티, 서비스 및 값으로 5 개의 클래스를 추가합니다. 이런 종류의 코드는 지저분한 코드보다 훨씬 느리게 움직이는 것처럼 느껴집니다.

한 달에 50K LOC 지저분한 코드를 작성하면 DDD에는 많은 리뷰와 변경이 필요합니다 (두 경우 모두 테스트는 신경 쓰지 않습니다). 하나의 간단한 추가는 더 이상 일주일이 걸릴 수 있습니다.

1 년 안에 많은 지저분한 코드를 작성하고 여러 번 다시 작성할 수 있지만 DDD 스타일을 사용하면 지저분한 코드와 경쟁 할 수있는 기능이 충분하지 않습니다.

설명 해주십시오. 이 DDD 스타일과 많은 패턴이 필요한 이유는 무엇입니까?

UPD 1 : 많은 훌륭한 답변을 받았습니다. 어딘가에 의견을 추가하거나 읽기 목록 링크로 답변을 편집하십시오 (시작, DDD, 디자인 패턴, UML, 코드 완성, 리팩토링, Pragmatic 등). .. 물론 많은 좋은 책들), 물론 순서대로, 그래서 나는 또한 당신들 중 일부처럼 이해를 시작하고 상급자가 될 수 있습니다.

이것은 최적화 문제입니다

훌륭한 엔지니어는 최적화 문제 가 목표 없이는 의미가 없음을 이해합니다 . 당신은 단지 최적화 할 수 없으며 무언가 를 위해 최적화 해야 합니다. 예를 들어, 컴파일러 옵션에는 속도 최적화 및 코드 크기 최적화가 포함됩니다. 이것들은 때때로 반대되는 목표입니다.

아내에게 책상이 추가에 최적화되어 있다고 말하고 싶습니다. 그것은 단지 더미 일이며, 물건을 추가하는 것은 매우 쉽습니다. 아내는 내가 검색에 최적화 된 경우 선호합니다. 즉, 물건을 조금 정리해서 물건을 찾을 수 있습니다. 이것은 물론 추가하기 어렵게 만듭니다.

소프트웨어도 마찬가지입니다. 제품 생성을 위해 최적화 할 수 있습니다 . 구성에 대한 걱정없이 최대한 빠른 속도로 많은 단일 코드 를 생성 할 수 있습니다 . 이미 알고 있듯이 이것은 매우 빠를 수 있습니다. 대안은 유지 보수를 위해 최적화하는 것입니다. 터치를보다 어렵게 만들지 만 수정을 더 쉽고 덜 위험하게 만듭니다. 이것이 구조화 된 코드의 목적입니다.

성공적인 소프트웨어 제품은 한 번만 만들어지고 여러 번 수정 될 것을 제안합니다. 숙련 된 엔지니어는 구조화되지 않은 코드 기반이 자체의 수명을 차지하고 제품이되어 크기와 복잡성이 커지는 것을 보았습니다. 코드가 구조화 된 경우 위험이 포함될 수 있습니다. 그래서 우리는이 모든 문제를 해결해야합니다.

복잡성은 요소가 아닌 관계에서 비롯됩니다

분석에서 수량, 코드 수, 클래스 수 등을보고 있음을 알 수 있습니다. 이러한 유형은 흥미롭지 만 실제로는 요소 사이의 관계에서 발생하며 조합 적으로 폭발합니다. 예를 들어, 10 개의 기능이 있고 어떤 기능에 의존하는지 전혀 모른다면 걱정할만한 90 가지 관계 (종속성)가 있습니다. 10 가지 기능 각각은 9 개의 다른 기능과 9 x 10에 의존 할 수 있습니다. = 90. 어떤 함수가 어떤 변수 나 데이터가 전달되는 방식을 수정하는지 모를 수 있으므로 코더는 특정 문제를 해결할 때 걱정할 것이 많습니다. 반대로, 30 개의 클래스가 있지만 영리하게 배열 된 경우, 스택으로 계층화되거나 배열 된 경우 29 개 정도의 관계 만 가질 수 있습니다.

이것이 팀의 처리량에 어떤 영향을 줍니까? 의존성이 적고, 문제는 훨씬 다루기 쉽다. 코더는 변경을 할 때마다 머리에 커다란 물건을 저글링 할 필요가 없습니다. 따라서 종속성을 최소화하면 문제를 유능하게 추론 할 수있는 능력이 크게 향상 될 수 있습니다. 그렇기 때문에 우리는 사물을 클래스 또는 모듈로 나누고 변수를 가능한 한 엄격하게 범위 지정하고 SOLID 원리를 사용 합니다.

글쎄, 우선, 가독성과 유지성은 종종 보는 사람의 눈에 있습니다.

당신이 읽을 수있는 것은 이웃에게 있지 않을 수 있습니다.

유지 관리 성은 종종 발견 가능성으로 귀결되며 (코드베이스에서 행동이나 개념이 얼마나 쉽게 발견되는지), 발견 가능성은 또 다른 주관적인 것입니다.

DDD

DDD가 개발자 팀을 돕는 방법 중 하나는 코드 개념과 동작을 구성하는 구체적인 (아직 주관적인) 방법을 제안하는 것입니다. 이 규칙을 통해 사물을보다 쉽게 ​​발견 할 수 있으므로 응용 프로그램을 유지 관리하기가 더 쉽습니다.

• 도메인 개념은 엔티티 및 집계로 인코딩됩니다.
• 도메인 동작은 엔티티 또는 도메인 서비스에 있습니다
• 일관성은 루트에 의해 보장됩니다
• 지속성 문제는 리포지토리에서 처리합니다.

이 배열은 객관적 으로 유지하기 쉽지 않습니다 . 그것은, 그러나,있다 잴 모든 사람들이 DDD의 맥락에서 운영하고 이해하면 쉽게 유지합니다.

클래스

클래스는 잘 알려진 규칙 이기 때문에 유지 관리 성, 가독성, 검색 가능성 등을 도와줍니다 .

객체 지향 설정에서 클래스는 일반적으로 밀접하게 관련된 동작을 그룹화하고 신중하게 제어해야하는 상태를 캡슐화하는 데 사용됩니다.

나는 그것이 매우 추상적으로 들린다는 것을 알고 있지만 다음과 같이 생각할 수 있습니다.

클래스를 사용하면 클래스 의 코드 작동 방식 을 알아야 할 필요는 없습니다 . 수업이 무엇을 담당 하는지 알아야 합니다.

클래스를 사용하면 잘 정의 된 구성 요소 간의 상호 작용 측면에서 응용 프로그램에 대해 추론 할 수 있습니다 .

이렇게하면 응용 프로그램 작동 방식을 추론 할 때인지 부담이 줄어 듭니다. 600 줄의 코드가 무엇을 수행 하는지 기억하지 말고 30 개의 구성 요소 가 어떻게 상호 작용 하는지 생각할 수 있습니다 .

또한 30 개의 구성 요소가 응용 프로그램의 3 계층 에 걸쳐 있을 수 있으므로 한 번에 약 10 개의 구성 요소 만 추론해야합니다.

꽤 관리하기 쉬운 것 같습니다.

요약

기본적으로 수석 개발자가하는 일은 다음과 같습니다.

그들은 응용 프로그램을 클래스 에 대해 추론하기 쉬운 것으로 나누고 있습니다.

그런 다음 레이어 에 대해 추론하기 쉽게 구성합니다 .

응용 프로그램이 커질수록 전체적으로 추론하기가 점점 더 어려워진다는 것을 알고 있기 때문에이 작업을 수행하고 있습니다. 계층과 클래스로 분류하면 전체 애플리케이션에 대해 추론 할 필요가 없습니다. 그들은 그것의 작은 부분 집합에 대해서만 추론 할 필요가있다.

왜이 DDD 스타일, 많은 패턴이 필요한가요?

첫째, DDD의 중요한 부분은 패턴 이 아니라 개발 노력을 비즈니스와 연계시키는 것입니다. 그렉 영은 청서의 장들이 잘못된 순서 라고 말했다 .

그러나 당신의 구체적인 질문에 : 당신이 기대하는 것보다 훨씬 더 많은 클래스가있는 경향이 있습니다. 도메인 모델에서 명시 적으로 표현됩니다.

도메인에 두 개의 서로 다른 개념이있는 경우 둔상으로, 메모리 표현에서 동일하게 공유 되더라도 모델에서 고유해야합니다 .

실제로 도메인 전문가가 모델을보고 오류를 발견 할 수 있도록 비즈니스 언어로 모델을 설명하는 도메인 특정 언어를 작성하고 있습니다.

또한 우려를 분리하는 데 약간 더주의를 기울입니다. 그리고 구현 세부 사항에서 일부 기능의 절연 소비자 개념. DL Parnas를 참조하십시오 . 명확한 경계를 통해 전체 솔루션에 영향을 미치지 않으면 서 구현을 변경하거나 확장 할 수 있습니다.

동기 부여 : 비즈니스의 핵심 역량 (경쟁 우위를 이끌어내는 장소를 의미 함)의 일부인 응용 프로그램의 경우 도메인 동작을보다 쉽고 저렴하게 대체 할 수 있기를 원할 것입니다. 실제로, 프로그램의 일부가 빠르게 발전하고 (시간이 지남에 따라 상태가 진화하는 방법), 느리게 변화하고 싶은 다른 부분 (상태가 저장되는 방법)이 있습니다. 여분의 추상화 계층은 실수로 서로 연결되는 것을 방지합니다.

공정성 : 일부는 또한 객체 지향 뇌 손상입니다. Evans가 원래 설명한 패턴은 15 년 이상 전에 참여한 Java 프로젝트를 기반으로합니다. 상태와 행동은 이러한 스타일로 밀접하게 연결되어 있으므로 피하기를 원하는 합병증을 유발할 수 있습니다. Stuart Halloway의 지각과 행동 또는 John Carmack의 인라인 코드 를 참조하십시오 .

어떤 언어로 작업하든 기능적 스타일의 프로그래밍은 이점을 제공합니다. 편리 할 때마다해야하며, 결정이 불편할 때 열심히 생각해야합니다. 카맥, 2012

다른 답변에는 많은 장점이 있지만, 중요한 개념적 실수를 놓치거나 강조하지는 않는다고 생각합니다.

전체 프로그램을 이해하려는 노력을 비교하고 있습니다.

이것은 대부분의 프로그램에서 현실적인 작업이 아닙니다. 간단한 프로그램조차도 너무 많은 코드로 구성되어 있기 때문에 주어진 시간에 헤드에서 모든 프로그램을 관리하는 것은 불가능합니다. 귀하의 유일한 기회는 현재 작업과 관련된 프로그램의 일부 (버그 수정, 새로운 기능 구현)를 찾아서 작업하는 것입니다.

프로그램이 거대한 함수 / 메서드 / 클래스로 구성되어 있다면 이것은 거의 불가능합니다. 이 코드 덩어리가 문제와 관련이 있는지 여부를 결정하기 위해 수백 줄의 코드를 이해해야합니다. 추정치에 따라 일주일 동안 코드를 찾기가 쉬워졌습니다.

패키지 / 네임 스페이스로 이름이 지정되고 구성되어있는 작은 함수 / 메소드 / 클래스가있는 코드베이스와 비교하여 주어진 로직을 어디에서 찾거나 넣을 수 있는지 명확하게합니다. 많은 경우에 올바르게 수행하면 문제를 해결하기 위해 올바른 위치로 또는 최소한 디버거를 시작하여 몇 번의 홉으로 올바른 지점으로 이동할 수있는 곳으로 바로 이동할 수 있습니다.

나는 두 종류의 시스템에서 일했다. 비교할 수있는 작업과 비슷한 시스템 크기에 대한 성능의 차이는 쉽게 2 배가 될 수 있습니다.

이것이 다른 활동에 미치는 영향 :

• 더 작은 단위로 테스트가 훨씬 쉬워집니다
• 두 개발자가 동일한 코드에서 작업 할 가능성이 더 작기 때문에 병합 충돌이 줄어 듭니다.
• 조각을 재사용하고 조각을 찾기가 더 쉽기 때문에 중복이 줄어 듭니다.

코드 테스트보다 코드 테스트가 어렵 기 때문에

개발자의 관점에서 많은 답변을 얻었습니다. 처음으로 코드를 작성하는 것이 더 힘들어지면서 유지 보수를 줄일 수 있다는 것입니다.

그러나 고려해야 할 또 다른 측면이 있습니다. 테스트는 원래 코드로만 세분화 할 수 있습니다.

모놀리스로 모든 것을 쓰면, 쓸 수있는 유일한 효과적인 테스트는 "이 입력을 받았는데 출력이 맞습니까?"입니다. 이것은 발견 된 모든 버그가 "거대한 코드 더미의 어딘가에있는"범위를 가짐을 의미합니다.

물론 개발자가 디버거와 함께 앉아 문제가 시작된 위치를 정확히 찾아 수정 작업을 수행 할 수 있습니다. 이 작업에는 많은 리소스가 필요하며 개발자의 시간을 잘못 사용합니다. 사소한 버그가 있다고 생각하면 개발자가 전체 프로그램을 다시 디버깅해야합니다.

해결책 : 각각 하나의 특정한 잠재적 인 고장을 찾아내는 많은 작은 테스트.

이러한 작은 테스트 (예 : 단위 테스트)는 코드베이스의 특정 영역을 확인하고 제한된 범위 내에서 오류를 찾는 데 도움이됩니다. 이렇게하면 테스트가 실패 할 때 디버깅 속도가 빨라질뿐 아니라 작은 테스트가 모두 실패 할 경우 더 큰 테스트에서 더 쉽게 오류를 찾을 수 있습니다 (즉, 테스트 된 특정 기능이 아닌 경우 상호 작용 상태 여야 함). 그들 사이에).

분명히, 더 작은 테스트를하려면 코드베이스를 더 작은 테스트 가능한 청크로 분할해야합니다. 대규모 상용 코드베이스에서 그렇게하는 방법은 종종 작업중 인 것처럼 보이는 코드를 생성합니다.

부수적으로 말하면, 사람들이 "너무 멀리"물건을 가져 가지 않을 것이라는 말은 아닙니다. 그러나 코드베이스를 작거나 적은 연결 부품으로 분리하는 합법적 인 이유가 있습니다.

왜이 DDD 스타일, 많은 패턴이 필요한가요?

정말하지 않습니다 (대부분의 ...) 우리 중 많은 사람들이 필요 를. 이론가와 경험이 풍부한 숙련 된 프로그래머는 많은 연구와 깊은 경험의 결과로 이론과 방법론에 관한 책을 씁니다. 즉, 그들이 쓰는 모든 것이 일상의 모든 프로그래머에게 적용되는 것은 아닙니다.

주니어 개발자는 관점을 넓히고 특정 문제를 파악하기 위해 언급 한 것과 같은 책을 읽는 것이 좋습니다. 또한 선임 동료가 익숙하지 않은 용어를 사용할 때 당황스럽고 독창적이지 않도록합니다. 무언가가 매우 어려워서 의미가 없거나 유용 해 보이지 않는 경우, 자신을 죽이지 마십시오. 단지 그러한 개념이나 접근 방식이 있다는 것을 머릿속에 정리하십시오.

학업이 아닌 한, 일상적인 개발에서 당신의 직업은 실행 가능하고 유지 보수가 쉬운 솔루션을 찾는 것입니다. 책에서 찾은 아이디어가 그 목표를 달성하는 데 도움이되지 않는다면, 작업이 만족 스럽다고 생각되는 한 지금 걱정하지 마십시오.

읽은 내용 중 일부를 사용할 수 있지만 처음에는 "얻지"않았거나 그렇지 않은 것을 발견 할 수 있습니다.

귀하의 질문이 많은 가정과 함께 많은 근거를 다루고 있으므로 귀하의 질문 주제를 골라 보겠습니다.

디자인 패턴에 많은 클래스가 필요한 이유

우리는하지 않습니다. 디자인 패턴에는 많은 클래스가 있어야한다고 일반적으로 인정되는 규칙이 없습니다.

코드를 넣을 위치와 작업을 다른 코드 단위로 자르는 방법을 결정하기위한 두 가지 주요 안내서가 있습니다.

• 응집력 : 모든 코드 단위 (패키지, 파일, 클래스 또는 메서드)가 함께 속해 있어야 합니다 . 즉, 특정 방법에는 하나의 작업이 있어야하며 잘 수행해야합니다. 모든 수업은 하나의 더 큰 주제 (무엇이든)에 대한 책임이 있어야합니다 . 우리는 높은 응집력을 원합니다.
• 커플 링 : 두 코드 단위는 가능한 한 서로에 거의 의존하지 않아야합니다. 특히 순환 종속성이 없어야합니다. 낮은 커플 링을 원합니다.

그 두 가지가 왜 중요한가?

• 응집력 : 많은 일을하는 방법 (예 : GUI, 논리, DB 액세스 등을 한 번의 긴 코드 혼잡으로 처리하는 구식 CGI 스크립트)은 다루기 어려워집니다. 글을 쓰는 시점에서, 당신의 생각의 기차를 긴 방법으로 넣는 것은 유혹적입니다. 이것은 효과적이고 발표하기 쉽고 그렇게 할 수 있습니다. 문제는 나중에 발생합니다. 몇 개월 후에 자신이 한 일을 잊어 버릴 수 있습니다. 맨 위에있는 코드 줄은 맨 아래 줄에서 몇 화면 떨어져있을 수 있습니다. 모든 세부 사항을 잊어 버리기 쉽습니다. 메소드의 어느 곳에서나 변경하면 복잡한 것의 많은 양의 동작이 중단 될 수 있습니다. 방법의 일부를 리팩토링하거나 재사용하는 것은 상당히 번거로울 것입니다. 등등.
• 커플 링 : 코드 단위를 변경할 때마다 코드에 의존하는 다른 모든 단위가 손상 될 수 있습니다. Java와 같은 엄격한 언어에서는 컴파일 타임 동안 힌트 (예 : 매개 변수, 선언 된 예외 등)가 표시 될 수 있습니다. 그러나 많은 변화가 그러한 변화를 유발하지 않고 (즉, 행동 변화) 다른 더 역동적 인 언어에는 그러한 가능성이 없습니다. 커플 링이 높을수록 어떤 것이 든 변경하기가 더 어려워 져 목표를 달성하기 위해 완전히 다시 작성해야하는 경우 중단 될 수 있습니다.

이 두 가지 측면은 모든 프로그래밍 언어에서 "무엇을 어디에 넣을 것인가"와 모든 패러다임 (OO뿐만 아니라)을 선택할 수있는 기본 "드라이버"입니다. 모든 사람이이를 잘 알고있는 것은 아니며, 소프트웨어에 미치는 영향에 대해 심오하고 자동적 인 느낌을 얻는 데 종종 몇 년이 걸립니다.

물론,이 두 개념은 당신이 실제로 무엇에 대해 아무것도 말하지 않는 수행하십시오 . 어떤 사람들은 너무 많은 것을 잘못하고, 어떤 사람들은 너무 작은 것을 잘못합니다. 일부 언어 (여기에서 Java를 보았을 때)는 언어 자체의 매우 정적이고 비판적인 성격으로 인해 많은 클래스를 선호하는 경향이 있습니다 (이것은 가치 진술이 아니지만 그 자체입니다). 동적 언어 및 표현력이 뛰어난 언어 (예 : Ruby)와 비교할 때 특히 두드러집니다.

또 다른 측면은 일부 사람들은 지금 필요한 코드 만 작성하는 민첩한 접근 방식에 가입하고 필요할 때 심하게 리팩토링한다는 것입니다. 이 스타일의 개발에서는 interface구현 클래스가 하나만있을 때는 생성하지 않습니다 . 당신은 단순히 구체적인 클래스를 구현할 것입니다. 나중에 두 번째 클래스가 필요한 경우 리팩토링합니다.

어떤 사람들은 단순히 그런 식으로 작동하지 않습니다. 보다 일반적으로 사용될 수있는 모든 것에 대한 인터페이스 (또는 일반적으로 추상 기본 클래스)를 작성합니다. 이것은 급격한 폭발로 이어진다.

다시 말하지만 반대 주장이 있으며, 내가 당신이나 어느 쪽을 선호하는지는 중요하지 않습니다. 당신은 소프트웨어 개발자로서 인생에서 긴 스파게티 방법부터 깨달은 방대한 클래스 디자인, 너무 과도하게 설계된 클래스 체계에 이르기까지 모든 극단을 만날 것입니다. 경험이 많을수록 "건축 적"역할로 더 커져서 원하는 방향으로 영향을 미칠 수 있습니다. 당신은 자신을위한 황금의 중간을 발견 할 것입니다, 그리고 당신은 여전히 ​​당신이 무엇을 하든지 많은 사람들이 당신과 동의하지 않을 것입니다.

따라서 열린 마음을 유지하는 것이 여기에서 가장 중요한 부분이며, 나머지 질문으로 판단하여 문제에 대해 많은 고통을 느끼고 있음을 알 수 있습니다.

숙련 된 코더는 다음을 배웠습니다.

• 그 작은 프로그램과 clasess, 특히 성공적인 프로그램이 커지기 시작하기 때문입니다. 단순한 수준에서 작동하는 간단한 패턴은 확장되지 않습니다.
• 모든 추가 / 변경마다 여러 아티팩트를 추가 / 변경해야하는 부담이 될 수 있지만 추가 할 항목을 알고 있으므로 쉽게 수행 할 수 있습니다. 3 분의 타이핑은 3 시간의 영리한 코딩을 능가합니다.
• 오버 헤드가 실제로 좋은 이유를 이해하지 못하기 때문에 많은 작은 클래스가 "지저분하지"않습니다.
• 도메인 지식이 추가되지 않은 경우, '명백한 나'코드는 종종 팀 동료에게 미스테리 한 것입니다.
• 부족의 지식은 프로젝트를 쉽고 빠르게 생산하기 위해 팀 구성원을 추가하는 것을 매우 어렵게 만들 수 있습니다.
• 이름 지정은 컴퓨팅에서 두 가지 어려운 문제 중 하나이며 여전히 많은 클래스와 메소드가 이름을 지정하는 데 많은 도움이되는 경우가 많습니다.

지금까지의 대답은 모든 것이 좋으며, asker가 무언가를 놓쳤다는 합리적인 가정으로 시작하여 asker도 인정합니다. asker가 기본적으로 옳을 수도 있으며, 이러한 상황이 어떻게 발생하는지 논의 할 가치가 있습니다.

경험과 실습은 강력하며, 선배들이 일을 통제 할 수있는 유일한 방법이 많은 복잡한 프로젝트에서 경험을 쌓았다면 EntityTransformationServiceImpl디자인 패턴에 빠르며 편안하며 DDD를 준수합니다. 작은 프로그램에서도 가벼운 접근 방식을 사용하면 훨씬 덜 효과적입니다. 이상하게도 적응해야하며 훌륭한 학습 경험이 될 것입니다.

그러나 적응하면서도 단일 접근 방식을 심도있게 학습 할 수있을뿐만 아니라 어느 곳에서나 작업 할 수있는 시점까지 다재다능한 상태를 유지하고 어떤 툴을 사용하든 전문가가 아니더라도 어떤 툴을 사용할 수 있는지를 아는 것 사이의 균형에서 교훈을 얻어야합니다. 세계에는 두 가지 장점이 있으며 둘 다 필요합니다.

사용에 따라 더 많은 클래스와 기능을 만드는 것은 향후 문제를 해결하는 데 도움이되는 특정 방식으로 문제를 해결하는 훌륭한 방법입니다.

여러 클래스는 기본 작업으로 식별하는 데 도움이되며 언제든지 클래스를 호출 할 수 있습니다.

그러나 얻을 수있는 이름의 클래스와 함수가 많으면 호출하고 관리하기 쉽습니다. 이것을 깨끗한 코드라고합니다.