0
문서 생성기를 구현하려고합니다. 나는 Open-Closed Principle을 따르라고 주장한다.중첩 추상화 및 폐가 원칙
- 여러 문서 유형 (즉, 계약, 위임장)
- 여러 문서 형식이있을 것이다있을 것이다 (즉, XML, JSON, HTML, PDF)
- 각각 다음과 같이 요구 사항은 문서 형식은 문서에 다른 데이터 집합이 있어야합니다 (예 : 클라이언트 세부 정보, 전체 권한)
다음과 같은 개방형 원칙을 선택했기 때문에 switch 문을 사용하지 않는 것이 좋습니다. 즉, 특정 유형의 문서 및 형식 유형에 대한 추상화 및 구현을 소개해야합니다.
m x n 클래스 구현을 제공해야합니까? 여기서 m은 문서 유형의 수이고 n은 문서 형식의 수입니까? 나는 이것이 잘못된 방법이라고 생각한다. 이런 문서 생성기를 올바르게 설계하는 방법에 대한 힌트를 주시겠습니까?
나는 언제나 어떤 원칙을 항상 존중한다고 생각하지 않습니다. O/C 또는 다른 지침에 초점을 맞춰서는 안됩니다. 도메인을 이해하고 이에 기초하여 디자인해야합니다. 가치 객체와 적절한 집계가 핵심입니다. – MikeSW
"적절한 집계"란 무엇을 의미합니까? 몇 가지 예를 들어 주시겠습니까? – Dawid
적절한 집계는 도메인에서 볼 수있는 각 문서 모델을 올바르게 식별해야 함을 의미합니다. 기본적으로 각 문서의 각 세부 사항을 고유 한 제약 조건 및 규칙으로 이해해야합니다. 코드, OOP, SOLID 등과 아무런 관련이 없습니다. 도메인에 대한 생각과 접근 방식, 즉이 특정 주제에 대해 도메인 전문가가되어야한다는 점을 이해해야합니다.도메인 자체의 언어를 사용하여 도메인처럼 생각하십시오. 시력에 클래스, 기능 등. – MikeSW