안드로이드 아키텍쳐

패스트캠퍼스의 강의를 요약한 버전...올린다

 

 

아키텍쳐가 왜~~~중요하게 한 번만 말한다

• 안드로이드는 웹처럼 이슈에 대해 바로바로 대응이 안됨..큰 일 터지면 좃대는것..!
• 성공한 앱을 더 빨리 확장시키기위해서(모듈화, 실험 기반 시스템 필요)
• 더 깊은 사용자화 필요..!(유연한 구조가 필요)
• 나중에 바꾸려면 아주아주 많은 시행착오가 필요 → 엄청난 cost
• 모듈화는 가능한 빨리 해야됨…(ㅎㅎ….ㅅ ㅂ)

 

 

 

 

복잡성 제거 ; 좋은 설계를 위한 첫걸음

• 복잡성 → 시스템을 이해 및 수정하기 어렵게하는, 소프트웨어 구조에 관련된 모든것. (단순히 코드 줄 수를 말하는것은 아님).
  • 변경증폭 (작은 변경인데, 다른 많은 부분을 편집해야됨)
  • 인지적 부하 (작은 변경인데 많은 선수지식을 알아야함)
  • 알 수 없는 무지 (작은 변경인데, 알 수 없는 결과가 나온다)
• 복잡성이 발생하는 이유는 멀까???
  • 의존성 (코드가 독립적으로 이해되고, 수정 안 됨) → 줄이기!
  • 불명확함 (중요 코드가 불명확함)
  • 전술적 프로그래밍 (빨리 완성하느라 조져두는것)
• 복잡성을 낮추는 방법 → 추상화!
  • 복잡성을 아래로 끌어내리기 get/adjustSize/readNext의 순서라면, readNext만으로 다 되도록!
  • *주의사항 : 남용하면 정보의 유출로 이어질 수 있음
• 깊은 모듈 : 모오듈이란 자고로 구현후 인터페이스를 제공하는것인데, 깊은 모듈이란 하나의 간단한 요청으로 많은 작업이 완료되는것(file.open 등)
• 범용 인터페이스 : 현재 요구사항을 모두 만족하는것중 가장 심플한 인터페이스. 최대한 많은 상황에서 사용할 수 있어야함
• 추상화 사이의 경계 찾기
  • 정보가 공유되거나 / 함께 있는것이 인페를 더 단순하게 하거나 / 합쳤을때 코드 중복이 줄어든다면 → 합치기
  • 특정 목적의 api가 범용 클래스 안에 있을 때, 다른 종류의 범용 메커니즘이 함께 있을 때 → 나누기

 

 

 

 

SOLID 원칙(그만듣고싶음)

하…일단 복기 시작

 

• S (단일책임) O (개방-폐쇄) L (리스코프 치환) I (인터페이스 분리) D (의존성 역전)
  • 단일책임원칙 S : 각 소프트웨어 모듈은 변경의 이유가 단 하나여야함. == 하나의 모듈은 오직 하나의 액터에 대해서만 책임짐
  • 개방-폐쇄 원칙 O : 확장에 대해서(데이터구조 확장 등)는 열려있고, 변경에 대해서는 닫혀있어야함. 하위 레벨은 상위레벨을 따라가지만, 상위레벨은 반대로 하위레벨을 따라가지 않아야한다.
    • 클래스 단위의 개방/폐쇄 원칙 : 모든 멤버변수는 private, 혹은 protected여야함 / 글로벌 변수는 피해야함 / 추상 클래스는 따로 만들어야함(사용자에게 필요한것만 노출하고, 구현 클래스의 냐용을 감추기위함
    • 모듈 단위의 개방 / 폐쇄 원칙 : 의존 관계의 방향이, 보호하려는 컴포넌트를 향하도록 그려짐.
  • 리스코프 치환 원칙 L : 자식 컴포넌트중 어떤 것을 선택해도( 대체가 일어나도) 똑같이 동작해야함. 절대적인건 아님..!

• 인터페이스 분리 원칙 I : 각 소프트웨어 모듈은 자신이 사용하지 않는 것에 의존하지 않아야함. 추이 종속성을 막기 위함~~!~!~!!~!~!
• 의존성 역전의 원칙 D : 높은 수준의 코드는 낮은 수준의 세부사항 구현에 의존해서는 안되고, 그 반대여야함
• 상속보다는 조합! ( 상속의 예외상황을 신경 쓸 필요 없도록 할 것)
• solid는 중간규모 (클래스들이 모인 모듈)에 대한 원칙임(클래스도 가능)
• solid의 목표 ; 유지보수성 / 가독성 / 낮은 결합도 / 높은 응집도

 

 

 

퍼사드 패턴

• 공통된 인터페이스를 제공하는 패던

 

 

모오바일 클린 아키텍챠

• 실제로 존재한다기보단 … 클린 아키텍쳐를 모바일에 맞춰서 변형하는 방법
• 보통 아래와 같은 그림으로 계층이 구성됨. 각각의 레이어는 모듈화됨

• UI 계층 : UI에 관련된 모든 처리
  • 뷰 : 화면 표시, 사용자 입력만 담당. 뷰가 activity / fragment 만을 의미하지는 않음
  • 프레젠터 (뷰모델) : 뷰와 달리, os의 렌더링 api에 직접적으로 의존하지는 않음. 뷰 관점의 비지니스 로직을 담당..
• 도메인 계층(optional)
  • 유스케이스 : 도메인 관점의 비즈니스 로직
  • 도메인 모델 : 앱의 논리적인 엔티티 데이터
  • 트랜스레이터 : mapper. 데이터 계층의 entity - 도메인의 모델 간 변환 담당
• 데이터 계증
  • 레포지토리~!~!~! : u/c가 필요로하는 데이터 저장 / 수정 등의 기능을 제공. 데이터소스 객체를 막 갈아끼울 수 있음 ( 외부 api, db, mock obj막 왔다갔다한다..대박이지..)
  • 데이터 소스 : 실제 데이터의 입출력이 여기서 시작된다~!~!
  • 엔티티 : 가져온, 날것의 정보(요청 혹은 응답을 위한 json, local db에 저장된 데이터를 나타내는 data class

 

 

 

TRD를 잘~쓰는 방법

• 최소한 두 개 이상의 설계를 제안할 것.
• 가급적 각각의 설계는 극단적으로 다른 방향으로 만들어볼 것.
  • 어떤 인터페이스가 더 심플할까?
  • 어떤 인터페이스가 일반적인 시나리오에 더 적합할까?
  • 어떤 인터페이스가 고수준의 구현을 더 쉽게 해주나?
• 피드백을 최대한 여러 사람에게 받기