답변:
읽기 및 쓰기 구현은 응집력이 높을 가능성이 높습니다. 하나가 바뀌면 다른 하나도 바뀔 것입니다. 높은 응집력은 단일 책임을 강력하게 나타내며 단일 책임 원칙은 이들이 동일한 등급으로 구성되어야 함을 알려줍니다. 이러한 작업의 응집력이 낮 으면이를 분할하면 유지 관리 성이 향상 될 수 있습니다.
그러나 쓰기없이 데이터를 읽거나 읽지 않고 쓰는 소비자가있는 경우 인터페이스 분리 원칙에서 규정 한대로 인터페이스 관점에서 이러한 작업을 분리해야 함을 나타냅니다. 이는 소비자가 의존 할 수있는 두 개의 인터페이스를 정의해야하며 File클래스는 두 인터페이스를 모두 구현 한다는 것을 의미합니다 .
SOLID 원리를 적용하여 객체를 설계 할 때 파일 읽기 및 쓰기를 하나의 책임으로 간주 할 수 있습니다. 영구 데이터 작업
그러나 파일 읽기 및 쓰기를 동일한 방법이나 기능으로 사용해서는 안됩니다.
다른 답변의 대부분은 귀하의 질문에 하나의 중요한 정보가 누락되었다고 간과 한 것 같습니다-읽고 쓰는 문서가 관련되어 있는지 여부와 방법을 알려주지 않았습니다!
응용 프로그램에 "문서 객체"와 같은 것이 있고이를 먼저 PDF 파일에 쓴 다음 나중에 동일한 파일을 유사한 문서 객체로 다시 읽습니까? 또는 반대로 PDF를 문서로 읽어서 수정하고 동일한 문서를 새 PDF에 다시 저장합니까? 그러면 읽고 쓰는 것이 하나의 책임으로 여겨 져야합니다. 응용 프로그램이 "PDF 편집기"구성 요소 또는 "PDF 조작 툴킷"과 같은 것이거나 포함 된 경우가 여기에 해당합니다.
그러나 응용 프로그램의 한 부분이 예를 들어보고 구성 요소에서 일부 PDF 파일을 작성하고 응용 프로그램의 관련되지 않은 다른 부분이 다른 PDF (예 : 검색 엔진의 메일 첨부 파일 평가 기)와 후자의 PDF는 첫 번째 사용 사례와 공통점이 없으며 해당 작업은 다른 책임입니다.
특히 PDF의 경우 두 번째 사용 사례는 다른 종류의 응용 프로그램에서 훨씬 더 많이 본 사례입니다. PDF 작성을 지원하는 훨씬 더 많은 라이브러리 / 구성 요소가 있으며 PDF 읽기도 지원하는 훨씬 적은 수의 라이브러리가 있습니다. PDF 파일을 생성하기 위해 하나의 라이브러리를 사용하고 PDF를 읽기 위해 완전히 다른 라이브러리를 사용하려는 경우 PDF 읽기와 쓰기는 별도의 책임이 있음을 알아야합니다.