개시하다

#2에서 우리는 청결 구조의 유형 구조를 고려해 보았다.
이번#1 이해가 부족한 부분에서 세 번째로 열거한'응용 프로그램 전체의 관심사'에 대한 처리를 고려해 보자.

애플리케이션 전반에 걸친 관심사

iOS, 안드로이드의 경우 앱 종류에 따라 간과할 수 없는 이벤트가 몇 개 있다.
애플리케이션이 백그라운드/전방으로 돌아가고, 통신할 때 네트워크 연결이 끊기거나 복구됩니다.
UI가 아닌 framework &driver에서 입력했다는 결론이 나왔다.마침 본가의 네 개의 동그란 그림 왼쪽 상단에'Devices'가 있는데 이것은 iOS, 안드로이드 특유의 장치 활동을 감시하고 받아들이는 부분이다.활동을 수락하면 Interface Adapter를 통해 Usecase Interactor로 처리됩니다.
여기서부터 이 결론까지의 비망록.

프로세스 처리

Usecase Interactor 이벤트를 감지하는 framework &driver 층의 학급과 활동에 따라 각각 어떤 (UI 작업 등) framework &driver가 준비되어 있는지 확인합니다.예컨대
이어 "스마트폰의 인터넷 접속이 끊긴 것이 감지되면 애플리케이션은 화면의 특정 영역에서 경고 메시지를 계속 표시한다"고 덧붙였다.
"스마트폰에서 인터넷 연결이 끊긴 상태에서 회복된 것을 감지하면 애플리케이션은 화면의 특정 영역에 표시된 경고 메시지를 삭제합니다."
이런 용례로 규격을 보면...

인터넷 연결 상태를 감시하는 프레임워크 &driver의 실현

인터넷 연결을 차단/복원하는 용례를 담당하는 Usecase Interactor의 설치

화면의 특정 영역에서 경고 메시지를 표시하거나 숨기는 데 사용되는 프레임워크 &driver

의 3명이'사건 감지→화면 업데이트'처리를 했다.
대략적인 인상은 이렇다.

Usecase Interactor를 통한 필요성

위와 같은 사례의 처리 과정을 고려하면'인터넷이 끊겼다->화면에 고정된 경고->복구된->경고 제거'절차는 iOS, 안드로이드 특유의 이벤트 수신 방법만 진행하고 iOS, 안드로이드 특유의 View를 제어하기 때문에 도대체'Usecase Interactor'로 처리해야 하는가?이런 의문이 쏟아졌다.
그러나 이 질문에 대해서는 "Usecase Interactor를 통과해야 한다"고 답했다.
상기 규격례 중 인터넷 연결이 끊긴 사건이 발생했을 때 이뤄지는 처리는 하나뿐이지만, Usecase Interactor를 사용하지 않아 이뤄지면 규격에 따라 여러 처리를 변경하는 데 불편이 발생할 수 있다.
예를 들어 인터랙터 미사용 설치를 실시할 때'스마트폰의 인터넷 연결이 끊겼을 때 화면의 특정 구역에 경고 메시지를 계속 표시하고 프로그램 내부에 xxx(중요한 값)를 저장한다'는 규격이 변경될 때Usecase "경고 메시지에 표시된 화면 업데이트에 Usecase Interactor를 사용하지 않지만 영구화 처리는 Usecase Interactor를 사용합니다."

그러나 이렇게 되면 Usecase Interactor 이외의 부분에서'용례의 상세한 정보(화면 처리와 영구화 처리가 필요)'를 알게 되고 임무 분담은 붕괴될 수 있다.
앞으로 시행별로 책임 범위가 명확해야 한다는 점을 고려해 당시 횡방 활동만 했더라도 Usecase Interactor를 소개해야 한다.

총결산

이번에는 남은 의문점인'앱 전체의 관심사'를 정리했다.#1의 기사에서
아마도 밖→안→바깥 부분은 변화가 없을 것이다. 안→바깥 부분에서 어떻게'전체적인 주지'를 할 것인가.뭐, 단순한 콜백이 아닌 것 같아.
이런 말을 썼지만 곰곰이 생각해 보니 밖→안→밖...
이 항목이 누구의 두뇌 정리에 도움이 된다면 좋겠다.