저는 문서와 같은 책을 만들기 위해 고안된 소프트웨어를 작업 중입니다. 데코레이터를 사용하여 다양한 기능을 추가하여 구현했습니다. 여기구성 가능한 소프트웨어에 대해 Builder 및 Decorator 패턴을 어떻게 설정합니까?
$this->chapter[i] = new ChapDecorator1(new ChapDecorator2(new Chapter(i)));
도전 장식이 하드 코딩되어있는 초기화 '의 일례이며 sofware의 많은 반복을위한 가능성이있다. 새 프로젝트에 대한 흥미로운 변경 사항은 오래된 항목으로 백 포트되는 경우가 많습니다 (필요한 경우 장식자를 추가하는 것이 필요하기 때문에 현재 장식 자에게는 끔찍한 일이 아닙니다). 그러나 여전히 하위 클래스 코드를 편집해야합니다. 프로그래머가 아무 것도 편집하지 않아도 필요한 컨텐츠를 선택하는 실제 컨텐츠 제작자가 최적의 상황입니다.
이 경우 더 좋은 방법은 Book이 빌더 패턴을 구현하는 객체를 사용하여 챕터 객체를 만들고이를 프로젝트의 올바른 데코레이터로 포장하는 것입니다.
마지막으로 빌더 객체를 구성 순서를 동적으로 올바르게 처리 할 수있는 방법은 무엇입니까? 데코레이터가 래핑 된 순서는 인터페이스 호출이 어떻게 해결되는지 (LIFO) 순서를 내포합니다. 예를 들어 문서 편집 추적은 데코레이터로 구현되지만 변경 사항이 적용되기 전에 명백한 이유로 먼저 상태를 저장해야합니다 (마지막 래퍼 여야 함). 장래의 개발을 위해서, 많은 데코레이터가 있다고 가정하면, 데코레이터가 우선 순위 데이터 멤버 (정수? 그것은 실행 가능한 솔루션처럼 보이지만 많은 수의 우선 순위에 민감한 데코레이터/모듈이 생성되면 구현이 매우 강력하지 않을까 우려됩니다. 충돌하는 우선 순위에는 예를 들어 많은 클래스의 번호를 다시 매기는 것이 필요할 수 있습니다. 어쨌든, 사람들이 그 문제에 관해 생각해 봤으면 좋겠어요.
두 번째 문제는 두 명의 데코레이터가 동일한 기능을 어떤 식 으로든 변경하는 경우입니다. 그 상황이 가능해야합니까? 각 데코레이터가 도메인을 지정하고 충돌을 찾는 데코레이터 목록을 탐색해야합니까?
많은 데코레이터가있을 것이며 일부 프로젝트 편집자는 일부를 선택하지만 다른 것은 선택하지 않을 것이라고 가정합니다. 감사합니다.
감사합니다. 시작이지만 여전히 내 상황에 완벽하지는 않습니다. 중복성과 순서에는 두 가지 문제가 있습니다. 빌더에게는 주로 주문과 관련이 있습니다. 데코레이터가 먼저 해결할 것인가에 대한 질문에 대답 할 수 있습니다. 마지막으로 적용한 다음 내부적으로 작업합니다. 그것은 나에게 순서를 제공하지만 정적 우선 순위 정수를 사용하지 않고 데이터베이스 설정을 기반으로 순서대로 적용하도록하는 방법은 무엇입니까? 이중화는 장식자를 기준으로합니다. 인터페이스 호출이 이루어지면 동일한 기능을 편집하는 두 명의 데코레이터가 허용되어야합니까? – Hath995
죄송합니다. 충분히 명확하게하지 않았다고 생각합니다. 나는 그 질문을 바꿔 말할 것이다. – Hath995