🦊1. 애플리케이션 설계란 ?

🥴1. 애플리케이션 설계란 ?

- 구성 요소들 간의 유기적 관계를 표현하고, 요구사항을 해결하려는 계획 과정등의 원칙을 나타낸다. 

- 애플리케이션은 유지보수가 필수이다. 왜냐하면 안드로이드 플랫폼 버전과 호환되지 않거나 마켓 정책상의 이유로 앱이 제 기능을 하지 안는다면 제 기능을 하지 못한다. 

🥱2. 애플리케이션의 설계 원칙?

- 2000년대 SOLID 5가지 원칙 
- 각 원칙의 머리 글자를 따와 만든 명칭
- 코드의 가독성을 높이고 확장이 쉬운 구조를 만드는 지침

1) 단일 책임 원칙(Single Responsibility Principle)
	- 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화 함을 말한다.
	- 단일 책임 : 어떤 클래스나 모듈 또는 메서드가 단 하나의 기능을 가져야 함을 말한다. 
    	즉, 변경사항이 발생하더라도 그 변경 사항에 대한 책임이 있는 부분만 수정하면 된다.

2)개방 폐쇄 원칙 (Open Closed Principle)

	- 소프트웨어가 확장에 대해서는 열려있어야 하고 수정에 대해서는 닫혀 있어야 한다는 원칙이다.
	- 변경사항이 발생하더라도 다른 코드나 모듈에 영향이 없도록 하는것이다. 새로운 기능을 추가하거나 기존의 기능을 변경하기가 용이해진다.
	- 객체 지향의 핵심적인 원칙

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

	- 치환성  : 클래스 S 가 클래스 T 의 자식 클래스라면 별다른 변경 없이 부모 클래스 T를 자식 클래스 S 로 치환할수 있어야 한다는 원칙. 즉 다운 캐스팅된 인스턴스가 논리적으로 그 역할이 문제가 없어야한다.
	- 객체 지향 프로그래밍 특징에 관한 몇 가지 표준적인 요구사항을 강제한다.
	-하위 클래스에서 메서드 파라미터의 반공변성
	-하위 클래스에서 반환형의 공변성
	-하위 클래스에서 메서드는 상위 클래스 메서드에서 던져진 예외 사항을 제외하고 새로운 예외 사항을 던지면 안됨
	-하위 클래스에서 선행 조건은 강화될 수 없음
	-하위 클래스에서 후행 조건은 약화될 수 없음 
	-하위 형에서 상위 형의 불변 조건은 반드시 유지되어야 한다 

- 다음과 같이 차례로 상속받는 타입이 있다고 가정한다

  A <- B <- C 
  public class A{}
  public class B extends A{}
  public class C extends B{}

- 공변성

   List<?extends B> 란 B를 상속받는 타입으로 이루어진 리스트가 있다면  List<C>를 사용할수 있다는 내용이다. 

- 반공변성
    -List<? extends B>란 리스트가 있을때 List<A>를 사용할수 있다는 점이다. 물론 A 의 부모타입으로도 치환이 가능하다 

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

	-어떠한 클래스가 자신이 이용하지 않는 메서드에 의존하지 않아야 하는원칙
    	-큰덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리함으로써 클래스들이 꼭 필요한 메서드들만 이용할 수 있게 한다. 
    	-역할 인터페이스 : 작은 단위로 메서드 들로 구성된 인터페이스 
    	-fly() 메서드를 인터페이스로 분리하고 날수 있는 새에만 구현함으로 써 펭귄을 사용하지 않는 fly() 메소드를 가지지 않을수 있어 ISP 원칙을 지킬수 있게 되었다. 
    	- 독수리를 클래스로 표현하는 예제

      public abstract class Bird{
          abstract void fly();
          abstract void cry();
      }
      public class Eagle extends Bird{
          @Override
          public void fly(){...}
          @Override
          public void cry(){...}
      }

	- 펭귄을 클래스로 표현하는 예제

      public abstract class Bird{
      	abstract void cry();
  	  }
      public interface Flyable{
          void fly();
      }
      public abstract class FlyableBird extends Bird 					implements Flyable{
          ...
      }
      public class Eagle implements FlyableBird{
          @Override
          public void fly(){...}
          @Override
          public void cry(){...}
      }
      public class Penguin extends Bird{
          @Override
          public void cry(){...}
      }

5)의존 역전 원칙( Dependency Inversion Principle)
 -모듈들을 분리하는 특정 형식을 지칭한다
 -상위 계층이 하위 계층에 의존하는 전통적인 의존관계를 역전함으로써 상위 계층이 하위계층의 구현으로부터 독립되게 할 수 있다. 
 -다음과 같은 원칙을 갖고 있다 
   	5-1) 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 
    	5-2) 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다. 
          	⇒ 상위와 하위 모두가 동일한 추상화에 의존해야 한다. 는 객체 지향적 설계의 대원칙을 제공함. 
 -예시 1) 예전의 폰은 폰마다 전용 충전기가 존재 했다 전용 충전기 외의 다른 충전기는 호환되지 않았는데 이 기기는 전용 충전기에 강한 의존성을 가진다고 할 수 있다. 
 -예시 2) 요즘 안드로이드 폰은 C 타입 단자라면 어느 제조사의 것을 끼워도 호환이 된다. 전용 충전기가 필요가 없으며  어는 제조사의 것을 끼워도 잘 동작한다 이는 C 타입을 추상화 시켜서 기기가 특정 충전기에 의존하던것을 인터페이스를 통해 의존성을 역전시켰다. 

🤩3. 클린 아키텍쳐

- 로버트 C 마틴에 의해 만들어진 철학으로 소프트웨어의 관심사를 계층별로 분리하는 소프트웨어 디자인 철학이다.
- Entities ← Usecases ← Presenters ←UI
- 코드 종속성이 외부로부터 내부로 의존한다.
- 내부 계층의 코드는 외부 계층의 기능을 알수 없다
- 외부 계층에 존재하는 변수, 함수및 클래스는 안쪽 계층에서 다시 등장할 수 없다
- 클린 아키텍쳐를 사용했을때 장점
- 계층을 분리하고 계층간의 의존성을 단방향으로 만들기때문에 코드의 재사용성이 용이해진다.
- 유닛 테스트가 쉬워진다. 

1) Entities
   	- 데이터 구조나 메서드를 포함하는 객체이다. 
	- 네트워크나 데이터 베이스와 관련된 클래스를 작성할때 사용되는 데이터 클래스를 말한다 

2) Use Cases
	- 애플리케이션과 관련된 비즈니스 규칙을 포함하고 시스템의 모든 유스케이스 구현체들을 캡슐화 한다. 
	- 엔터티로부터의 데이터 흐름을 관리하며 유스 케이스의 목적을 달성하기 위해 언테티에 넓고 전사적인 비즈니스 규칙의 사용을 가르친다. 
	- 안드로이드에서는 Model, Repository ,Executor등과 관련된 내용이 이 계층에 속한다
		2-1)Model 
		-데이터 베이스의 질의나 네트워크의 요청의 비즈니스 로직을 수행한다. 
		2-2) Repository
		-내부 DB에 접근하거나 저장 또는 원격 서버의 데이터를 요청하는 역할을 한다. 일반적으로 인터페이스를 구현하여 외부 계층과의 연결을 느슨하게 한다
		2-3) Executor 
		-Repository 나 Model과 관련된 작업이 백그라운드에서 작업을 수행 할 수 있도록 작업 스레드를 관리하고 제공한다.

3) Interface Adapters
	- Use Cases , Entities로부터 얻는 데이터를 가공하는 계층이다. 
	- 비즈니스 로직을 수행하여 원하는 결과값을 얻어 UI에 표현하려고 적당한 형식으로 데이터를 가공해 흔히 말하는 Presenter,View, ViewModel, Controller 와 같은 관심사가 여기에 속한다. 
	- 이 계층의 목적은 비즈니스 로직과 프레임 워크 코드를 자연스럽게 연결하는 것이다 

4) Frameworks 와 Drivers
	- 가장 바깥 계층으로 안드로이드에서는 UI 와 관련된 액티비티, 프래그먼트 ,인텐트 전달, 데이터베이스, 콘텐츠 프로바이더가 포함되며 Retrofit과 같은 네트워크와 관련된 프레임워크 코드가 여기에 속한다. 

😂4. 안드로이드의 특징

- 액티비티, 서비스 ,브로드 캐스트 리시버, 컨텐츠 프로바이더 4대 컴포넌트로 구성되어 있다.
- 여러 프로세스로 실행이 가능하다
- 진입점 이 다양하다
- 안드로이드 컴포넌트는 언제든지 실행이 가능하고 메모리 부족과 같은 시스템 조건으로 인해 의도치 않게 종료 될 수 있다. 이러한 생명주기는 안드로이드 시스템이 제어하기 때문에 데이터 및 상태에 대한 내용은 컴포넌트에 저장하는것은 위험하다.

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

- 가장 중요한 원칙은 관심사 분리다
- 관심사분리란?
	- 클래스 간의 강한 의존성을 느슨하게 하면서 모듈화 시킨다
	- 모듈화 : 다른 모듈로부터 독립적이며 영역에 따라 다른 역할을 한다는 의미 
- 관심사 분리 = 추상화

🤯6. 안드로이드 애플리케이션 설계 패턴

- MVC ,MVP, MVVM 디자인 패턴

🦦7. 디자인 패턴

🚕7-1.MVC 디자인 패턴

 - Model 
 	- 비즈니스 로직과 사용되는 데이터를 다루는 영역으로 데이터 베이스의 entity를 담당하는 클래스를 포함한 sqlite,room,realm등이 될수 있다.
 - View
    	- 사용자에게 표현되는 영역 
    	- Activity,Fragment가 뷰의 역할
 - Controller 
        - Model , View에 의존한다
        - 뷰로부터 입력을 받거나 이벤트 발생할때 모델과 뷰를 변경이 가능하다. 
    	- Activity 와 Fragment는 뷰의 역할을 함과 동시에 컨트롤러 역할을 한다. 

 - MVC 디자인 패턴의 장단점 
	- 구조가 단순하고 직관적이다
  	- 액티비티 프래그먼트가 뷰의 역할과 동시에 컨트롤러가되기 때문에 점진적으로 클래스에 스파게티 코드가 되어 시간이 지남에 따라 유지보수가 어려워 진다는 단점이 있다 
	- 컨트롤러는 뷰와 모델에 의존적이고 뷰는 모델에 의존적이기에 유닛 테스트가 거의 불가능하다. 

🚗7-2.MVP 디자인 패턴

- 기존의 MVC 패턴에서 Controller의 View와 Model과의 의존성을 없애기 위해 presenter 라는 개념을 도입해 유닛테스트가 가능하도록 했다 
- Contract클래스에 View와 Presenter를 정의해 사용된다. 
- View의 역할 : View 인터페이스에 정의된 메서드를 재 정의하여 데이터를 화면에 출력 하며 Presenter에 생명주기 또는 클릭이벤트에 대한 내용을 통지한다. 
- MVP 패턴의 장단점 
	1) 장점-View와 Model간의 의존성이 없으며 비즈니스 로직과 ui를 분리해 유닛 테스트가 수월해 진다. 
	2) 단점
    		-view 와 Presenter 간의 의존성이 높이지고 1:1 관계를 유지하기에 
    Presenter를 재사용할 수 없어 view가 늘어날때마다 presenter도 같이 늘어나 클래스가 많아지게 된다.

🚙7-3. MVVM 디자인 패턴

- 기존의 MVP 패턴은 View와 Presenter 가 강하게 결합되어있는 문제점을 해결하기위해 LiveDate, RxJava 와 같은Obserable 타입을 이용해 Presenter 와 View 사이에서 강하게 연결되었던 점을 끊는데 집중한다. 

- Presenter 대신에 ViewModel을 이용하며 ViewModel은 View에 표현할 데이터를 Obserable 타입으로 관리하며 View 들이 ViewModel에 데이터를 구독 요청하여 화면에 나타내는것이 핵심이다. 

- View Viewmodel 간에 느슨한 연결이 되도록 DataBinding  라이브러리가 필수적으로 사용된다.