문제

방금 "InstructionBuilderFactoryMapFactory"라는 클래스를 생성했습니다.이는 한 클래스에 4개의 "패턴 접미사"가 있습니다.그것은 즉시 나에게 다음을 상기시켰다:

http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern

이게 디자인 냄새인가?이 숫자에 제한을 두어야 합니까?

나는 일부 프로그래머들이 다른 것에 대해서도 비슷한 규칙을 가지고 있다는 것을 알고 있습니다(예:C에서는 포인터 간접 참조 수준이 N개를 넘지 않습니다.)

나에게는 모든 수업이 필요한 것 같다.나는 문자열에서 팩토리까지의 (고정된) 맵을 가지고 있습니다. 이것은 제가 항상 하는 일입니다.목록이 점점 길어지고 있으며 빌더(맵에서 얻은 팩토리에서 생성됨...)를 사용하는 클래스의 생성자 밖으로 목록을 이동하고 싶습니다. 그리고 평소와 같이 싱글톤을 피하고 있습니다.

도움이 되었습니까?

해결책

나는 그것을 디자인 냄새로 본다 - 그것은 모든 추상화 수준이 충분한 무게를 당기면 생각하게 할 것이다.

왜 당신이 '습지 builderfactoryMapFactory'의 이름을 지정하고 싶었는지 알 수 없습니까? 다른 종류의 공장이 있습니까? 아니면 맵핑해야 할 다른 종류의 교육 건설물이 있습니까?

이것들은 이와 같은 수업을 만들 때 생각해야 할 질문입니다. 다른 공장 공장을 하나의 공장으로 집계 한 다음 공장을 만드는 별도의 방법을 제공 할 수 있습니다. 공장을 다른 패키지에 넣고 더 간결한 이름을 부여하는 것도 가능합니다. 이 작업을 수행하는 대안적인 방법을 생각하십시오.

다른 팁

좋은 팁은 다음과 같습니다. 클래스 공개 API (및 이름 포함)는 구현이 아닌 의도를 공개해야합니다. 나는 (클라이언트로서) Builder 패턴 또는 공장 패턴을 구현했는지 상관하지 않습니다.

클래스 이름은 나쁘게 보일뿐만 아니라 그것이 무엇을하는지에 대해서도 말하지 않습니다. 이름은 구현 및 내부 구조를 기반으로합니다.

(때로는) 공장을 제외하고는 수업에서 패턴 이름을 거의 사용하지 않습니다.

편집하다:

흥미로운 것을 발견했습니다 기사 코딩 공포에 대한 이름 지정에 대해 확인하십시오.

클래스 이름에 패턴이 많이 있으면 냄새임이 확실하지만 냄새가 확실한 지표는 아닙니다."잠시 멈춰서 디자인을 다시 생각해보라"는 신호다.가만히 앉아서 생각하면 더 명확한 해결책이 분명해지는 경우가 많습니다.때로는 당면한 제약(기술/시간/인력 등)으로 인해 지금은 냄새를 무시해야 함을 의미합니다.

구체적인 예에 ​​관해서는 땅콩 갤러리의 제안이 더 많은 맥락 없이는 좋은 아이디어라고 생각하지 않습니다.

나는 같은 생각을하고있다. 제 경우에는 풍부한 공장은 "테스트 가능성을위한 빌드"에 의해 발생합니다. 예를 들어, 다음과 같은 생성자가 있습니다.

ParserBuilderFactoryImpl(ParserFactory psF) {
...
}

여기에는 파서가 있습니다. 필요한 최고의 수업입니다. 파서는 빌더에서 방법을 호출하여 구축됩니다. 빌더 공장에서 구축 해야하는 건축업자 (각 파서마다 새로운 제품)가 얻어집니다.

자, h..l은 뭐가 parserfactory입니까? 아, 당신이 물어봐서 다행입니다! Parser Builder 구현을 테스트하려면 방법을 호출 한 다음 어떤 종류의 파서가 생성되었는지 확인해야합니다. 빌더가 생성하는 특정 파서 클래스의 배출을 깨뜨리는 유일한 방법은 구문 분석기가 생성되기 직전에 가로 채는 지점을 두는 것입니다. 따라서 파자화된다. 그것은 단위 테스트에서 파서의 생성자에게 전달되는 것을 관찰하는 방법 일뿐입니다.

나는 이것을 해결하는 방법을 잘 모르겠지만, 공장보다는 수업을 통과하는 것이 더 나을 것이라고 생각합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top