HOME

[Design Pattern] GoF 생성 패턴 - 상태 패턴(State Pattern)

상태 패턴(State Pattern) GoF 디자인 패턴 중 행동 패턴에 해당한다. 상태 패턴은 객체가 가지고 있는 내부 상태에 따라 스스로 행동을 변경할 수 있게 하는 패턴이다. 상태를 표현하는 추상 클래스나 인터페이스를 만들고, 상태 객체를 내부에 가지게 된다. 사용법 객체의 행동이 상태에 따라 달라질 수 있고, 객체 상태에 따라 런타임에 행동이 바뀌어야 할 때 상태에 따라 달라지는 분기 처리가 많을 때 구조 행동을 가진 객체 Context는 State의 인스턴스를 유지하고 관리한다. 상태별로 필요한 행동을 캡슐화하여 State추상클래스/인터페이스를 정의한다. Concre...

더보기

[번역] 안드로이드 라이프사이클 모음 - (4) ViewModels, Translucent Activities, Launch Modes

:bulb: 원문 The Android Lifecycle cheat sheet — part IV : ViewModels, Translucent Activities and Launch Modes을 번역한 글입니다. (4) ViewModels, Translucent Activities, Launch Modes 1. ViewModel ViewModel에는 onCleared라는 하나의 콜백만 존재하므로 생명주기가 간단하다. 다만 Activity와 Fragment 사이에서의 차이점은 존재한다. 초기화는 ViewModel을 획득했을 때 일어나는데, 일반적으로 onCreate에서 수행된다. 2. Trans...

더보기

[번역] 안드로이드 라이프사이클 모음 - (3) Fragment

:bulb: 원문 The Android Lifecycle cheat sheet — part III : Fragments을 번역한 글입니다. (3) Fragment 상황 1. Activity와 Fragment의 시작과 종료 Activity의 onCreate는 Fragment의 Lifecycle 이전에 실행됨 onStart나 onResume 같이 병행으로 되어있는 것은 Activity가 먼저 실행될수도, Fragment가 먼저 실행될 수도 있음 EX) Activity의 onStart -> Fragment의 onStart -> Fragment의 onResume -&g...

더보기

SOLID 원칙 - (5) 의존 역전 원칙 (DIP)

(5) 의존 역전 원칙 (DIP) 👴 Depend in the direction of abstraction. High level modules should not depend upon low level details. SOLID의 마지막 원칙인 의존 역전 원칙은 저수준 모듈이 고수준 모듈에 의존해야 한다는 것이다. UML에서 추상화의 방향은 저수준 -▷ 고수준으로 되어있다. Depend in the direction of abstraction이라는 말은 이러한 방향을 따라야 한다는 말인 것 같다. 이렇게 한다면 저수준의 모듈이 변경되더라도 고수준 모듈은 변경될 필요가 적어진다. 그렇다면 고수준과 저수준이란...

더보기

[번역] 안드로이드 라이프사이클 모음 - (2) Multiple Activities

:bulb: 원문 The Android Lifecycle cheat sheet — part II: Multiple activities을 번역한 글입니다. (2) Multiple Activities 여러 컴포넌트의 Lifecycle을 표현할 때 다이어그램을 사용했지만, 각 그룹 사이의 호출 순서는 다를 수 있다. 각 그룹 내에서의 순서에만 주목하면 된다. 또한 custom launch mode나 task에서는 적용되지 않는다. 상황 1. 백스택 - Activity 간 이동 새로운 액티비티가 시작되면, Activity 1은 사용자가 홈 버튼을 눌렀을 때와 비슷한 상황을 겪게 된다. 뒤로가기 버튼이 눌...

더보기

SOLID 원칙 - (4) 인터페이스 분리 원칙 (ISP)

(4) 인터페이스 분리 원칙 (ISP) 👴 Keep interfaces small so that users don’t end up depending on things they don’t need. SOLID의 4번째 원칙인 인터페이스 분리 원칙은 인터페이스는 인터페이스를 사용하는 클라이언트 기준으로 분리해야한다 라는 것이다. 인터페이스를 구체적으로 분리해서 자신과 관련없는 메소드는 구현하지 않아야 한다. ISP를 어기는 경우 인터페이스 분리 원칙을 위반했을 때 발생하는 문제점 중 가장 유명한 예시는 소스 재컴파일 문제이다. 소스 재컴파일 C, C++, Go, Swift, Java는 정적 언어이다....

더보기

[번역] 안드로이드 라이프사이클 모음 - (1) Single Activity

:bulb: 원문 The Android Lifecycle cheat sheet — part I: Single Activities을 번역한 글입니다. 개요 사용자는 앱을 이용하면서 화면을 돌리거나, 알림에 반응하거나, 다른 일을 하게되는데, 이런 이벤트가 발생한 뒤에도 사용자는 앱을 원활하게 사용할 수 있어야 한다. 이러한 UX를 제공하려면 컴포넌트의 Lifecycle을 관리할 줄 알아야 한다. 컴포넌트는 Activity, Fragment, Service나 앱 그자체, 혹은 기본 프로세스일 수 있다. 컴포넌트들은 Lifecycle을 가지고 있고, Lifecycle동안 상태가 변한다. 시스템은 Lifecyc...

더보기

SOLID 원칙 - (3) 리스코프 치환 원칙 (LSP)

(3) 리스코프 치환 원칙 (LSP) 👴 A program that uses an interface must not be confused by an implementation of that interface. 말이 너무 어렵다! 보통은 이렇게 말하는 것 같다. 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다. 리스코프 치환 원칙은 기능 확장과 함수의 명세와 관련된 원칙이다. 또한 리스코프 치환 원칙을 어기면 개방 폐쇄 원칙을 위반할 가능성이 높아진다. SOLID 원칙 - (2) 개방 폐쇄 원칙 (OCP)에서의 예시를 보자. public cla...

더보기