커맨드 패턴을 사용하면 항상 사용하지 않는 것보다 훨씬 많은 수의 클래스가 생성됩니다. 우리가 관련 코드 조각을 별도의 클래스로 함께 실행한다는 점을 감안하면 매우 자연 스럽습니다. 그렇지 않으면 6 또는 7 개의 클래스 만 사용하는 작은 프로젝트를 고려하기 위해 10 개 또는 12 개의 명령 서브 클래스로 끝내지 않으면별로 신경 쓰지 않을 것입니다. 일반적인 7 개 수업 프로젝트를 위해 19 개 정도의 수업을 갖는 것은 거의 잘못되었습니다.클래스 폭발로 이어지는 커맨드 패턴
나를 괴롭히는 또 다른 사항은 모든 Command 하위 클래스를 테스트하는 것이 고통 스럽다는 것입니다. 지난 몇 명령을 마치면 느리게 움직이며 더 이상 민첩하지 않게 느껴집니다.
이 말은 친숙한가요? 내가 잘못하고 있니? 이 프로젝트의 후반기에 민첩성을 잃어버린 것 같습니다. 며칠 전부터 계속해서 구현하고 테스트하는 방법을 모르겠습니다.
디자인 패턴은 문제를 일반적인 방법으로 해결하기위한 일반적인 템플릿입니다. 절충안은 당신이보고있는 것과 정확히 일치합니다. 이는 일반적인 접근 방식을 사용자 정의해야하기 때문에 발생합니다. 12 커맨드 클래스는 개인적으로 나에게 많은 것처럼 보이지 않습니다.
명령 패턴을 사용하면 명령이 간단하므로 (테스트 방법이 맞습니까?) 시험하기 쉽습니다. 또한 테스트는 격리 가능해야합니다. 즉, 의존성이 거의 없거나 전혀없는 상태에서 명령을 쉽게 테스트 할 수 있어야합니다. 당신은 당신이 선택한 패턴 (들)를 사용하여 간단하게 특정 복잡한 접근 방식을 봤어야
1) :
당신이보고해야 장점은 두 가지입니다. 즉 빠르게 추악 해지는 무언가가 이제는 더 우아해질 것입니다.
2) 단순화 된 접근 방식과 개별 구성 요소 테스트 용이성 때문에 더 빨리 진행되어야합니다.
컴포지트와 같은 다른 패턴을 사용할 수 있으며 코드를 복제하는 것을 피하기 위해 좋은 OO 디자인을 사용할 수 있습니까?
커맨드 클래스는별로 좋아 보이지 않지만 클래스의 60 % 이상을 차지하면 약간의 냄새가 난다고 동의합니다. 프로젝트가 커맨드 패턴을 사용하기에 충분히 복잡하다면, 몇 가지 클래스가 분리되어 있다고 생각합니다. 그렇지 않다면 명령 패턴이 과도 할 것입니다.
다른 답변은 명령의 복잡성을 줄이기위한 좋은 제안이 있지만 찾을 수있는 단순성을 선호합니다 (대체적으로 bowling game).
커맨드 패턴을 삭제하는 것이 두렵습니다. 그것은 텍스트 입력을 구문 분석하고 regexes와 대조하여 작업을 실행하는 곳입니다. 소량의 작업이지만 의미 있고 일관된 기능을 제공합니다. 패턴을 떨어 뜨리는 것이 장점이라고 생각하십니까? – Mike
커맨드 패턴을 사용하는 것이 좋은 주장이라고 생각합니다! 나머지 클래스를 살펴보고 모두 의미 있고 일관된 기능성을 지니고 있는지 확인해야하지만 올바른 방향으로 진행되는 것처럼 들립니다. –
나는 그것을 고집하고 오늘 프로젝트를 마쳤습니다. 어제부터 생각한 것보다 나은 것으로 드러났습니다. 특히 내가 뒤로 물러나서 120 가지의 자동화 된 테스트를 실행했을 때 더욱 그러했습니다. :) – Mike
코드 복제가 아닙니다. 그들은 별개의 작업을 수행하는 꽤 간단한 실행 메소드입니다. 저를 괴롭혔던 것은 방대한 수의 수업이었습니다 - 단지 약 4 개 또는 5 개의 도메인 클래스 만 갖고있었습니다. – Mike
@mike yeah 12 개의 수업은별로 많지 않습니다. 단순한 것이라면 쉽게 테스트 할 수 있어야합니다. 또한 일단 패턴이 정해지면 익숙해지면 더 빨리 나아질 것이라고 생각합니다. – hvgotcodes
또한 분리하여 테스트하는 것은 의미가 없습니다. 내 아키텍처의 계층에서는 비즈니스 규칙 전체가 적용됩니다. 그것도 꽤 짜증나는 부분입니다. – Mike