책 "아키텍처를 알아야 앱 개발이 보인다" #1

본 포스트는 아래 책을 읽고 공부한 것을 정리한 것이다.

#1 안드로이드 애플리케이션 설계 소개

잘 설계된 애플리케이션은 유지 보수비를 줄여주고, 성능, 보안, 안정성 등의 측면에서 많은 이점이 있다.

가장 중요한 점은 설계 및 유지보수에 대해서 지속해서 고민하고 발전시키려는 의지

SOLID 원칙

코드의 가독성을 높이고 확장이 쉬운 구조를 만드는 지침

1. 단일 책임 원칙(Single Responsibility Principle)

어떤 클래스나 모듈 또는 메소드가 단 하나의 기능을 가져야 한다는 뜻

편집 과정에 변경이 일어나면 같은 클래스의 일부로 있는 출력 코드가 망가질 위험이 대단히 높다.

 

2. 개방-폐쇄 원칙(OCP : Open Closed Principle)

소프트웨어가 확장에 대해서는 열려 있어야하고, 수정에 대해서는 닫혀 있어야 한다는 원칙

시스템의 구조를 올바르게 구성하여 변경 사항이 발생하더라도 다른 코드나 모듈에 영향이 없도록 하는 것

객체 지향 프로그래밍 언어에서 반드시 지켜야 할 기본적인 원칙

 

3. 리스코프 치환 법칙(Liskov Substitution Principle)

클래스 S가 클래스 T의 자식 클래스라면 별다른 변경 없이 부모 클래스 T를 자식 클래스 S로 치환할 수 있어야 한다는 원칙 (캐스팅 된 인스턴스가 논리적으로 그 역할이 문제없어야 한다.)

• 하위 클래스에서 메서드 파라미터의 반공변성
• 하위 클래스에서 반환형의 공변성
• 하위 클래스에 메서드는 상위 클래스 메서드에서 던져진 예외 사항을 제외하고 새로운 예외 사항을 던지면 안됨
• 하위 클래스에서 선행 조건은 강화될 수 없음
• 하위 클래스에서 후행 조건은 약화할 수 없음
• 하위형에서 상위형의 불변 조건은 반드시 유지되어야 함.

공변성 : 부모를 상속받는 타입으로 이루어진 리스트가 있다면 자식을 사용할 수 있다는 내용
반공변성 : 부모를 상속받는 타입(자식)으로 이루어진 리스트가 있으면 그 부모의 부모를 사용할 수 있다는 내용
불변성 : 공변성과 반공변성을 허용하지 않는 경우

 

4. 인터페이스 분리 원칙(ISP: Interface Segregation Principle)

어떠한 클래스가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙

큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리함으로써 클래스들이 꼭 필요한 메서드들만 이용할 수 있도록 함.

 

5. 의존 역전 원칙(Dependency Inversion Principle)

• 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야한다.
• 추상화는 세부 사항에 의존해서는 안된다. 세부 사항이 추상화에 의존해야한다.

이 원칙은 '상위와 하위 객체 모두가 동일한 추상화에 의존해야 한다.'는 객체 지향적 설계의 대원칙을 제공함.

 

---

 

클린 아키텍쳐

소프트웨어 관심사를 계층별로 분리하는 소프트웨어 디자인 철학

코드 종속성이 외부로부터 내부로 의존한다는 것, 내부 계층의 코드는 외부 계층의 기능을 알 수 없음

내부로 갈 수록 추상적이고 외부로 갈수록 구체적인 영역

-> 코드의 재사용성 용이, 유닛 테스트가 쉬워짐.

Entities

데이터의 구조나 메서드를 포함하는 객체

가장 일반적이고 상위 수준의 규칙들을 캡슐화, 외부에서 무언가 변경되었을 때 가장 최소한의 변경 사항을 가져야함.

ex) POJO (순수한 자바 객체) https://ko.wikipedia.org/wiki/Plain_Old_Java_Object

UseCase

시스템의 모든 유스 케이스 구현체들을 캡슐화

ex) Model, Repository, Executor

• Model : 데이터베이스의 질의나 네트워크 요청 등의 비즈니스 로직을 수행
• Repository: 내부 DB에 접근하거나 저장 또는 원격 서버의 데이터를 요청하는 역할. 일반적으로 인터페이스이며 인터페이스를 구현하여 외부 계층의 연결을 느슨하게 한다.
• Executor: Repository나 Model과 관련된 작업이 백그라운드에서 작업을 수행할 수 있도록 작업 스레드를 관리하고 제공한다.

Interface Adapters

유스 케이스나 엔티티로부터 얻은 데이터를 가공하는 계층

UI와 비즈니스 로직을 연결하는 계층

ex) 디자인 패턴의 Presenter, View, ViewModel, Controller

Frameworks와 Drivers

가장 바깥쪽 계층

ex)
UI 관련 : 액티비티, 프래그먼트, 인텐트 전달
데이터 접근&저장 : DB, 콘텐츠 프로바이더
네트워크 : Retrofit

안드로이드의 특징

안드로이드 컴포넌트는 언제든지 실행되고 종료될수 있음

컴포넌트의 생명주기는 개발자가 직접 제어하는 것이 아닌 안드로이드 시스템이 제어하기 때문에 데이터 및 상태에 대한 내용을 컴포넌트에 저장하는 것은 위험함.

안드로이드 애플리케이션 설계 원칙

액티비티와 프래그먼트의 클래스 의존성은 최소화하는 것이 좋다.

가장 중요한 원칙 : 관심사 분리

권장하는 애플리케이션 설계

ViewModel을 사용하는 앱의 Workflow

MVC 디자인 패턴

애플리케이션 구조를 모델(Model). 뷰(View), 컨트롤러(Controller) 세 가지 주요 측면으로 관심사를 분리

• 모델 : 애플리케이션의 비즈니스 로직과 사용되는 데이터를 다루는 영역
  일반적으로 DBMS에 의해 관리되고 몇몇 함수를 통해 데이터를 제공하거나 입력, 수정 등을 하는 역할을 함
  ex) POJO클래스, SQLite, Room, Realm
• 뷰 : 사용자에게 표현되는 영역
  ex) Activity, Fragment
• 컨트롤러 : 뷰로부터 입력을 받거나 특정 이벤트가 발생할 때 모델 또는 뷰를 변경할 수 있음

장점 :  구조가 단순, 직관적
규모가 작은 애플리케이션에 MVC 디자인 패턴 적용시 개발 기간 단축

단점 : 액티비티 or 프래그먼트가 뷰와 컨트롤러의 역할을 겸하는 구조라 고드량이 점진적으로 증가함
스파게티 코드가 되기 쉬움, 결합도가 높아 유닛 테스트가 거의 불가능

MVP 디자인 패턴

MVC에서 Ui와 비즈니스 로직을 분리함. Controller 대신 Presenter

• View : 인터페이스에 정의된 메서드를 재정의하여 데이터를 화면에 나타냄
  구현은 Activity 또는 Fragment에서
• Presenter : 생명 주기 or 클릭 이벤트에 대한 내용 통지

장점 : 유닛 테스트가 수월해짐

단점 : View와 Presenter 간의 의존성이 높고 Presenter를 재사용할 수 없음
기능이 추가될수록 Presenter가 거대해짐

MVVM 디자인 패턴

데이터 바인딩 및 LiveData 또는 RxJava와 같은 Observable 타입을 이용하여
MVP 패턴에서 Presenter와 View 사이에서 강하게 연결되었던 점을 끊음

Presenter대신 ViewModel 사용

ViewModel : View에 표현할 데이터를 Observable 타입으로 관리하며,
View들이 ViewModel에 데이터를 구독 요청하여 화면에 나타내는 것이 핵심
View와 관련된 코드를 참조하지 않음, ViewModel과 View는 1 : N 관계